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.
in regards to a fresh install of offline bundle: hash is good for *.tar.gz: cypher@ubuntu:~/Downloads$ sha256sum armory_0.92.3_offline_ubuntu_12.04-32.tar.gz
1702a46db8263411ca0e639943f7e7cf33ad8dea365c9252457b8288b149c057 armory_0.92.3_offline_ubuntu_12.04-32.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? 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. |
|
|
|
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=indexWladimir 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! |
|
|
|
Armory Version 0.92.3 ReleasedWe 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.pdfArmory 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).
|
|
|
|
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'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 you please try the menu option: Wallets->Fix Damaged Wallets->Consistency Check. The behavior looks a bit like a corrupted wallet.
What version of Armory are you using?
|
|
|
|
|
The transaction fee logic implemented by Armory matches that of the Bitcoin Core client itself. If you were to include a fee lower than the fee there, the transaction will be DOA when you try to broadcast it. The Bitcoin network would never see it. Therefore, if you want your transaction to be accepted by the network you really must include that fee.
The fee does not go to Armory or even Bitcoin Core developers. The fees are set and collected by the miners that keep the network secure. We simply must follow those fees, knowing that just about anyone can be a miner and thus there is built-in competition to keep fees low.
In this case, your fee is higher than normal, probably due to your transaction combining lots of inputs, and being very large in size (in terms of bytes, not BTC). This is a defensive mechanism of the network, to make it expensive to fill up the blockchain with lots of data. Unfortunately, most of the time you have no control over this parameter and you simply must follow it. Most of the time it's negligible compared to the tx size, but not always. This is one reason people believe that Bitcoin won't be good for microtransactions, because the cost of those transactions (in terms of fee) exceeds the value of the transactions themselves.
|
|
|
|
I just looked up the fragmented backup feature. It seems to be a variation of Shamir's secret sharing scheme. Very impressive. I'm liking it a lot.
More accurately, it is Shamir's Secret Sharing  And we have integrated some testing tools so you can check that all/lots of different combinations of fragments restore your wallet successfully. Enjoy! |
|
|
|
When I first started using Armory, I was fascinated by the idea of paper wallets, keeping my Bitcoins safe from internet thugs.
However, I made too many physical copies of the paper backup of my wallet, including one that I may have left in a hotel room, and two copies which I may have dropped on several occasions while shopping for groceries.
How can I protect my Bitcoins?
Create a new wallet, make new backups, and send all your coins to it. Then all your old backups are useless. Also, if you want to have both redundancy and security, I recommend exploring the fragmented backup feature. Do 3-of-6, then losing two of them won't compromise your wallet (though at that point you might want to cycle to a new wallet, but at least you won't be at risk). |
|
|
|
I'm using Armory 0.90-beta Should I update my version? I have all my BTC in Armory and I'm afraid to update  We do recommend you update anything before 0.91. And 0.92.1 is a solid release. Ok, so I just download & install the 0.92.1 version and all my wallets will show up again? Do I have to do anything else besides download & install? EDIT: I also have an offline wallet on an offline computer, should I update that version as well? You can update your online computer without touching the offline computer if you install 0.91.2 online. However, all the offline transaction formats changed to accommodate multisig with 0.92+, so if you upgrade your online computer to that, you'll have to do the same offline. |
|
|
|
I'm using Armory 0.90-beta Should I update my version? I have all my BTC in Armory and I'm afraid to update We do recommend you update anything before 0.91. And 0.92.1 is a solid release. |
|
|
|
No need to remove stuff. Just make sure appropriate warnings are in place. I just wanted you to be aware of the risks associated with the changes you made, as it's easy to get impatient and be happy with anything that works We're going to be making sure all those things in the extras directory are updated. You're just a little bit too early to the party. |
|
|
|
|
Please note: while I understand you were simply trying to get stuff to work, I encourage you to get the verification dialog back into the script. Offline signing has a dramatically reduced security profile if you are not manually verifying the transaction details in the secure environment.
For instance, your online computer is compromised. You request a transaction to send 1 BTC to address A. The online computer tells you that's what the transaction is for, but the transaction it saves to the USB is for 100 BTC from your wallet to address B (owned by the attacker). If you blindly sign it, you won't know what happened until it's too late.
This is why the Trezor has a little screen on it to display tx details and have you submit a physical button press. It assumes the transaction came from an untrusted environment and needs to be reviewed in the trusted environment.
Less critical, but still important... I recommend you not hardcode your password into the script. The password on your wallet isn't very useful if there's a plaintext file (the script) sitting on your harddrive with the password. The "getpass" module in the original script allows the terminal to collect your password at signing time and apply it without touching the disk.
Perhaps your use case is wildly different than I am imagining. Maybe you are implementing something that needs to do automatic signing and is protected in other ways, such as a firewalled signing device with an address whitelist with rate-limiting, etc. Just making sure you aware of the various risks associated with removing functionality from the original script.
|
|
|
|
|
Fantastic. Did you end up using the dev branch?
There was a few major architectural changes between when that script was written and the latest version. Mainly, the whole offline interface changed and uses "UnsignedTransaction" objects now instead of "PyTxDistProposal" objects (PyTxDP). This was done to accommodate multi-sig, and now offline transactions are treated as a 1-of-1 multisig transaction. Even though the GUI makes them look different, they actually both use identical code and serializations since 0.92.
|
|
|
|
Good day everyone! First off, this is my first post so hi!  I hope someone can help me, I am seriously stuck. I am basically trying to create a script getting Armory to sign transactions offline. I tried searching the forums, but can't seem to find anything since Armory got updated. cli_sign_txdp.py in the extras folder is outdated and while I did manage to get somewhere with it, I didn't get very far. I found PromoKit.py slightly more helpful but am still stumped. I have some programming knowledge behind me, but this is the first time I've used Python. I don't need to connect to the blockchain or anything to do with networking, just basically get cli_sign_txdp.py working - run the for loop to make sure all input addresses are in the wallet, display inputs and outputs, ask for passphrase then create the signed tx. At this point I'm stuck on the for loop with the error "TypeError: 'PyBtcAddress' object does not support indexing" and I have no idea if I'm even on the right track. Any help, even a nudge in the right direction, would be greatly appreciated! Thanks! Don't have much time to respond at the moment, but check the "dev" branch. I believe CircusPeanut recently updated a bunch of those scripts (rather, I asked him to, and I know he started but I don't know if he finished). Btw, welcome to the forums! |
|
|
|
Wow! You're absolutely right. I have no idea how that got by me. I just tested it against a test vectors and found that the default hash sizes are half what they are supposed to be. I even remember looking up test vectors at the time... but I guess I didn't apply them? I guess the other factor is that that code has never had to interoperate with anything else expecting the same HMACs. Otherwise we would've noticed. Well, we'll have to mark those functions as "special" (and keep using them for the old wallets), then update the parameters properly. The new wallets actually use HMAC from the Crypto++, and already pass all the test vectors. If I had tried doing CKD function with the python HMAC, I would have noticed. From RFC4231: 4.2. Test Case 1
Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b (20 bytes)
Data = 4869205468657265 ("Hi There")
HMAC-SHA-224 = 896fb1128abbdf196832107cd49df33f
47b4b1169912ba4f53684b22
HMAC-SHA-256 = b0344c61d8db38535ca8afceaf0bf12b
881dc200c9833da726e9376c2e32cff7
HMAC-SHA-384 = afd03944d84895626b0825f4ab46907f
15f9dadbe4101ec682aa034c7cebc59c
faea9ea9076ede7f4af152e8b2fa9cb6
HMAC-SHA-512 = 87aa7cdea5ef619d4ff0b4241a1d6cb0
2379f4e2ce4ec2787ad0b30545e17cde
daa833b7d6b8a702038b274eaea3f4e4
be9d914eeb61f1702e696c203a126854
4.3. Test Case 2
Test with a key shorter than the length of the HMAC output.
Key = 4a656665 ("Jefe")
Data = 7768617420646f2079612077616e7420 ("what do ya want ")
666f72206e6f7468696e673f ("for nothing?")
HMAC-SHA-224 = a30e01098bc6dbbf45690f3a7e9e6d0f
8bbea2a39e6148008fd05e44
HMAC-SHA-256 = 5bdcc146bf60754e6a042426089575c7
5a003f089d2739839dec58b964ec3843
HMAC-SHA-384 = af45d2e376484031617f78d2b58a6b1b
9c7ef464f5a01b47e42ec3736322445e
8e2240ca5e69e2c78b3239ecfab21649
HMAC-SHA-512 = 164b7a7bfcf819e2e395fbe73b56e0a3
87bd64222e831fd610270cd7ea250554
9758bf75c05a994a6d034f65f8f0e6fd
caeab1a34d4a6b4b636e070a38bce737
|
|
|
|
I just ran the same calculation using armoryengine and got the chaincode you were expecting: >>> from armoryengine.ALL import *
>>> k = hex_to_binary('C263A3ED1351B0E07D57B788688C3BD8EA0DE54788739093880AAEC2DFF21BCF')
>>> binary_to_hex(hash256(k))
'a7941f148f0537ddb2794c923a9ef15a9eada511f7ee5aad851e86ecb86d3b0a'
>>> binary_to_hex(HMAC256( hash256(k), "Derive Chaincode from Root Key"))
'90ced6c81a642182660c91a0418cdaf1165ae311378a3862723aed81d48a767e'
Usually these kinds of issues are endianness related. For instance, the first line k=hex_to_binary(...) interprets the strings as little-endian. You have to explicitly pass in a second arg with BIGENDIAN if you want to interpret it that way. When I first started learning Bitcoin, a significant amount of time was spent guessing and checking endianness switches for calculations with known outputs. That might be what you have to do here. |
|
|
|
When I got it to work, I was using the online version. Now, when I try with the offline bundle, I also can't verify it. joseph@crunchbang:~/downloads/OfflineBundle$ dpkg-sig --verify armory_0.92.2-testing_ubuntu-64bit.deb
Processing armory_0.92.2-testing_ubuntu-64bit.deb...
Okay, it sounds like my script is putting the armory*.deb file into the offline bundle before signing it. This might be related to the RPi bundle which I also know I fixed, but doesn't seem to have made it into the latest release. Sorry for the inconvenience! For now, download armory*.deb, verify it, and then copy it into the offline bundle directory (overwrite the existing .deb). Or verify using the signed hash file, which does contain the hashes of the bundle tar.gzs. Instructions for that are on the website download page. I'm thinking of changing this whole thing so that there is only regular releases (which seem to be done correctly), and then have a bunch of "offline-setup-packs" that can be installed one time for the offline computer, one for each linux distribution. It would be easier than re-creating every bundle for every release, though it's extra steps for the first-time user -- it's probably worth the tradeoff (especially because I can offer a wider array of offline bundles) |
|
|
|
|
Sorry, forgot to respond. You're actually right: the other .deb files do not have digital signatures, so you shouldnt' expect any output for them. It's the armory*.deb files that have signatures, and my script is supposed to sign them before putting them into the offline bundle.
Therefore, you should only need to run "dpkg-sig --verify armory*.deb" to verify the armory installer is legit. If not, you can always download the armory installer separately and verify it and put it into the bundle (but this shouldn't be necessary unless my bundling script is botched).
|
|
|
|
ECDSA is used for signing and verifying messages. Not for encrypting them.
So, the answer is "not".
You should use another crypto algorithms
sure, ECDSA is for signing and not for encription, but the same keys used for ECDSA could be used for encryption, and it would work like what the OP needs... so, while he must use an algorithm other than ECDSA, the answer would be yes. The private and public keys under ECDSA would not be related under another crypto scheme. If you reinterpret your ECDSA private key as a private key of a different scheme, you'll surely get an unrelated public key. It's not meaningful. What you really want is ECIES (Elliptic Curve IES) |
|
|
|
I am attempting to verify Armory installers. I have had success with this before but am having an issue now.
After I finally enter command: "$ sudo apt-get install dpkg-sig"
...it outputs this:
"Reading package lists... Done
Building dependency tree
Reading state information... Done
dpkg-sig is already the newest version.
The following package was automatically installed and is no longer required:
linux-image-generic
Use 'apt-get autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 18 not upgraded."
...instead of what is usually expected.
Not sure what to do here.
That's the command for installing dpkg-sig. Not running it. Run "dpkg-sig --verify *.deb" |
|
|
|
|
Show Posts
