Topic: Armory - Discussion Thread - page 23. (Read 521829 times)

In wallets that are encrypted (should be most of them) it sometimes generates all the addresses from the public keys when it doesn't have your password to generate the private keys with it.  In that case, it marks all the private keys to be calculated next time you unlock the wallet, which could be a lot of keys.  But once it is done, or won't need to do it again so each subsequent unlock should be much faster

Not sure if I found a bug or not but it sure seems like something that shouldn't work the way it does. Here's my scenario:

I use an old, offline machine running linux just for the purposes of offline signing for a couple Armory wallets. All was fine and dandy until I forgot the encryption passphrase for one of them. Not to worry though, right? Because I have the paper backup. So with that encrypted wallet for which I couldn't remember the encryption passphrase still in the list, I "recovered" the same wallet using the root key paper backup. It then gave me 3 options: to cancel, merge, or overwrite (with the text for "merge" saying that it would create a new passphrase). I chose the merge option. It then proceeded to "calculate new addresses" which was pretty processor intensive and ran for about 5-7 minutes. I didn't figure this was an issue and that it was a one-time thing so I didn't think much of it. Then I tried to spend from the wallet. I generated the transaction on an online computer, saved the tx file, loaded the tx file for signing on the offline computer, and then it did the same long processing activity (probably about 5 minutes) and it was finally signed. Saved the signed tx file, went to online computer, broadcast, and it went on without a hitch.

I haven't tried again as I don't have any reason to spend / send again but I'm wondering if I will have to deal with the 5-minute processing every time because I have a "merged" wallet with the passphrase changed.

And now that I think about it, what is the difference, on an offline machine, between a "merged" wallet and an "overwritten" wallet with a new encryption? Seems a bit redundant since the addresses, amounts, and transaction history aren't tracked.

no worries.  it's just that devs use a different language sometimes    for instance, i think adding these words to what you said would make it clearer:

"But the signed hashes list is better, since the hash list covers every file in the .tar.gz, not just the .deb."

Yes, that should still work for the regular non-offline-bundle installers.  And it was supposed to work with the debs inside the bundle, but it seems that I make the bundles before I sign the .debs (so the bundle ends up with the non-signed version).  But the whole tar.gz gets signed anyway, so the dpkg-sig signature is redundant, and the fact that I screwed up the redundant sig is what threw you off.  It's better to use the hash anyway, since it covers all the files in the .tar.gz, not just the Armory installer itself.

I'd like to make this simpler, but there's just so many OSes, so many signature layers, and a complex web of operations performed to make sure everything is consistent (such as making sure that the installers are signed before making the hashes file, which needs to be signed, before creating the announce digest, that needs to be signed, so the secure downloader gets the right file with a valid signature.  I wish we could just use the secure downloader for everything, but the fact is that people have to somehow verify the first version of Armory that they get, which requires the GPG stuff. 

ok, got it.

but i have to say, this whole section on your website needs to be re-written and clarified if you want to stop getting these questions:

GPG-Verifying Armory Installers

Update: If you already have a verified copy of Armory version 0.91 or higher, you can use the new secure downloader feature to get upgrades and/or installers for other systems.  See the next section for more info.   If you don't have a verified copy of Armory yet, you should follow these instructions to verify the first Armory installer you download via GPG.

Armory is used by some of the most heavily-invested, and most paranoid Bitcoin enthusiasts for maximum privacy and security.  If you are in this category, it is recommended you verify that your Armory installers have not been altered in any way.  Armory Ubuntu/Debian packages (*.deb files) are signed directly using our Offline Signing Key (GPG) (0x98832223).  And each release comes with a signed file containing the SHA256 hashes of each installer.   Unfortunately, it is not easy to verify these signatures unless you have access to a Linux machine.  At the moment, the verification procedure on Windows is very difficult. To verify in Linux, “cd” to the directory containing the installer (usually Downloads), download and import the Armory signing key from the ubuntu key-server, install the signature verification program, and then use it verify the signatures on the *.deb files:

$ cd Downloads   # the directory containing the *.deb
$ gpg --recv-keys --keyserver keyserver.ubuntu.com 98832223
$ sudo apt-get install dpkg-sig
$ dpkg-sig --verify *.deb

If everything goes smoothly, you will see the following output:

$ gpg --recv-keys --keyserver keyserver.ubuntu.com 98832223
gpg: requesting key 98832223 from hkp server keyserver.ubuntu.com
gpg: key 98832223: public key "Alan C. Reiner (Offline Signing Key) <[email protected]>"

$ dpkg-sig --verify *.deb
Processing armory_0.85-beta_amd64.deb...
GOODSIG _gpgbuilder 821F122936BDD565366AC36A4AB16AEA98832223 1353699840

Notice the "98832223" at the end of the "GOODSIG" line. That is the key "Fingerprint" and if it does not match, do not use that installer! To be extra sure, you can check the last 16 characters, which should be "4AB16AEA 98832223".  The last set of digits (1353699840) is simply a timestamp indicating when the signature was made.  This will be different for every new and can safely be ignored.

Got it. Thank you! You are the best!

I'm saying, if you verified the hash, that's all you need to do.  The signed hash and the signed .deb file come from the same secure environment. 

The .deb in the bundle was supposed to be signed, but strictly unnecessary if you check the signed hashes file.  Alternatively, you could skip the signed hashes, and just grab the .deb from the website (not the offline bundle), verify that with dpkg-sig, and then copy it into the bundle. 

But the signed hashes is better, since the hash covers every file in the .tar.gz, not just the .deb.

I know it's confusing, because there's many ways to check the validity of these things.  What I can tell you is that:

(1) If the signed hash is correct, everything in the archive is good
(2) Alternatively, get it from the secure downloader.  You can download any of the releases for any OS from the secure downloader, and it does all this work for you.  Obviously, you need to do the GPG thing the first time you install Armory anywhere (since you need a trusted versino of Armory to use the secure downloader), but after that you can get all packages through the secure downloader, including offline bundles and versions for other OSes.

in regards to a fresh install of offline bundle:

hash is good for *.tar.gz:


but, if not in the extracted Offline Bundle folder, where do i grab the armory_0.92.3_offline_ubuntu_12.04-32.deb against which i can run the dpkg-sig --verify *.deb?

About the git tag... that's coming.  0.92.2-testing got about zero people testing it, so I never did a real release of it until 0.92.3 came along and I decided to skip the 0.92.2 release and focus on that.  Furthermore, my release script failed to create the signed tag, and I decided I would fix it later rather than further delaying the release.

I'll see if I can get the signed tag out today.  Sorry for the delay.

As for the 0.9.3 signatures:

http://pgp.mit.edu/pks/lookup?search=laanwj%40gmail.com&op=index

Wladimir has taken over the Core release signing process.  It used to be Gavin (0x1FC730C1), but this time the SHA256SUMS file is signed by Wladimir's key (0x2346c9a6).  I trust that key because it is signed by Gavin's key (0x1FC730C1) which has been used for every prior release as far back as... 2011?

I have checked the signatures on all Core downloads and have made them part of the Secure Downloader within Armory, so you can download them without having to check the signatures.  If you trust me to check the signatures properly then you can trust the downloads in the Secure Downloader.  This is one of the reasons I made the secure downloader, to transfer some of the burden of checking signatures from you to me!

I have an issue with 0.9.3 because this thread https://bitcointalksearch.org/topic/bitcoin-core-093-has-been-released-799967 seems to have stopped. I haven't bothered to learn how to check the sigs on the bitcoin Core and that thread made me realize that I don't know who signs the bitcoin Core client. I will not touch my Core client until I figure stuff out.

I agree. I am working on getting Armory into Debian and the git tag or a tarball makes my job easier.

Yes, please provide at least a git tag.
A while back I asked for simple tarballs, but at least with the git tag I can get them from GitHub.
You're making it impossible for distribution packagers - and this is why 0.92.2 didn't end up in the Gentoo Overlay.

when can we expect a git update + signed tag?

Armory Version 0.92.3 Released

We have officially released 0.92.3.  It's not on the website yet (that's not automated in our release process yet), but it will be shortly.

This release not only officially brings the Tor/Privacy fix out of testing, it also fixes a rather scary-but-actually-benign bug that we found in the Armory code related to random number generation when signing Bitcoin messages (not transactions, just message signing).  For more details about this, read the full report here:

https://s3.amazonaws.com/bitcoinarmory-media/CVEs/ArmoryCVE-2014-002.pdf

Armory Tech has pretty thoroughly investigated the incident and believes that no action is needed by anyone, even if you have signed thousands of messages.  Armory Technologies itself would be the most vulnerable since we use that feature to sign all of our releases.  We have determined that no exposure has occurred and still consider our offline signing key 100% safe.  Nonetheless, we have fixed the issue in this release.

Before asking lots of questions please read the above PDF which I spent an exceptional amount of time writing.  It is extremely thorough, both in terms of our own analysis and concerns raised by Sergio Del Lerner, whom we contacted to provide an independent third-party opinion.  We also posted this to the our recently-formed Security Working Group and received positive feedback from two members, and no one raised any concerns about the analysis.

On that note, here's the download links for the new version, but as always, we encourage you to use the secure downloader to get the new version if possible  (at this point most people should have 0.91+ and can use the secure downloader).

---

  Armory 0.92.3 for Windows XP, Vista, 7, 8+ (32- and 64-bit)
  Armory 0.92.3 for MacOSX 10.7+ (64bit)
  Armory 0.92.3 for Ubuntu 12.04+ (32bit)
  Armory 0.92.3 for Ubuntu 12.04+ (64bit)
  Armory 0.92.3 for RaspberryPi  (armhf)


  Armory 0.92.3 Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.92.3 Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.92.3 Offline Bundle for RaspberryPi  (armhf)

  Armory 0.92.3: Signed hashes of all installers

---

GOOD NEWS:  The latest Bitcoin Core release relaxed the isStandard() logic, so you should be able to up to 7-of-7 Armory Lockboxes on mainnet.  I haven't actually tested this, but I expect by now that a critical mass of miners have upgraded to Core 0.9.3, so spending 7-of-7 (or smaller) coins should work. 

The only requirement is that you upgrade your own version of Core to 0.9.3 -- which has been updated in the secure downloader as well!

---

Other fixes: 

• URI handling bug fix (Coinbase-generated links were not working with Armory)
• Raspberry Pi install script and offline bundle was hosed.  Some empty debs have been replaced, and the double-click script should work properly now.  Please test it out for me!
• The Ubuntu offline bundles have been upgraded to support 12.04.5 now (since 12.04.3 was difficult to find).

I'll have to double-check the release scripts.  It's possible that it's bundling the .deb before it signs it.  If that's the case, then just grab the correct .deb not from the offline bundle.  It's the same thing, but should be signed.   

On the other hand, if you check the hashes file, that will be accurate.  That lists the hash of the tar.gz with whatever .debs are in there, signed or not.  Even though the .deb itself was not signed, the bundle was created on the same secure machine, hashed, and put in the sha256 file which is signed.

can someone remind me how to check the signature of the offline *.deb installer?

i'm able to check the sha256sum of the initial downloaded *.tar.gz file but can't remember how to check the sig. is it done on the online or offline computer?  

Edit: running the dpkg-sig against the armory*.deb extracted from the *.tar.gz for 0.92.1 is unsuccessful.

I totally agree on that.
So, I try to pay a bitcoin to my landlord.
How do I get his adress? Via his website, or mail, or I noted it down in my Armory adressbook.
All of these can be easily replaced, without noticing, by malware.
Malware might also change stuff so the change adress isn't mine, but his. Not sure about that though.

That is no Armory-specific or even Bitcoin-specific problem. Same problem arises with regular bank account transfer, if I don't know the account details by heart.

The only thing Armory can secure, and does so well, is that you only lose that one transaction. As soon as your landlord kicks your butt, you know something is wrong with your computer. All other coins should still be safe on the offline computer.

Please, someone tell me what I overlooked here?

Ente

I am about getting from Armory the address for receiving bitcoins. It's not neeeded for broadcasting...
As i think you about a sending of bitcoins...

Yeah the bitcoin rpc i dont think ever had deprecation

so latest Bitcoin Core is compatible with ARmory 0.92.1?