Just wondering, has that been tagged on GitHub yet?
I tend not to tag the testing versions, though I have done so a couple times in the past. This particular testing release was really to test that the fix works for those reporting problems, before we commit to an official release. So far it is very promising, so we will probably convert this to an official release soon, with a proper signed tag. |
|
|
|
You may want to consider some updates to the online dllinks.txt file at some point...
Will Bitcoin 0.10.0 become available through the secure downloader, now that Armory officially supports it?
Speaking of updates to the dllinks.txt file  (that's the file that would need updating and re-signing for 0.10.0 to become available). Yes it will, the problem is that it's not split up by Armory version, so updating 0.10 in the secure downloader would push it to the all the 0.92.3 users as well, who haven't upgraded. I figured I would remove all the torrent code and push 0.10 all at once, but I'll give it some time for people to upgrade Armory first. |
|
|
|
Good I don't think I like it. There's no way I trust incrementing vs rng. I'd rather get support for usb rng plus mouse movements.
To be clear, it's not "incrementing". It's a hash that changes if the private key or message changes. In other words, there's no way to sign two different messages or with two different private keys using the same k-value with RFC6979. It should be pretty strong, I'm just more sensitive to deviating from NIST/FIPS standards with our recent enterprise focus. |
|
|
|
I wish people would stop referring to "you are at risk if you don't use RFC6979". We have seen in the wild, poorly-supported platforms, with poorly implemented RNGs cause problems for people that reuse addresses. However, Armory only runs on systems with proper RNG capabilities AND using an RNG for ECDSA signing is part of the NIST standard. RFC6979 is exactly what it says "Request for Comments". It's not a standard, never been approved by any organization. I recognize that it might be more trustworthy than the javascript RNG or Android RNG (which have both caused problems in the past), but in our environment I'd prefer to use the NIST/FIPS standard RNG version of signing.
For instance, we're working on HSM integration now, and the whole thing is a giant [$15,000!] FIPS-certified hardware and software stack. If we tried to implement RFC6979 we'd be breaking all the crypto certifications of the device. This would mean our HSMs would immediately be unsuitable for any government use. This means it would be unsuitable for a wide variety of environments that depend on FIPS certifications.
This doesn't mean that I don't think RFC6979 is useful. It's that it's a tradeoff between using an approved, standardized process, and using a "proposed" process that addresses shortcomings in some platforms that don't even meet sanity checks for RNG capability. While I think it would be tough to argue that the RFC6979 process was insecure, we don't like modifying such sensitive parts of crypto processes without at least some review by standards bodies (with real cryptographers).
My attitude on all this is: I personally believe (using judgement) that RFC6979 is a good choice, as standardizing it across applications solves issues with platforms using weak RNGs, as any shortcomings it might have are better than having a bad RNG behind the signing. But I'm not going to shove all our users into it (at least without a way to disable it) on platforms that have solid RNGs and can apply the approved signing algorithms. For now, we've made det-signing opt-in, and I think pending further review we'll switch the default to make it opt-out.
conceptually, the Trezor is a mini-HSM, right? from a security standpoint, would you consider it "as secure" as an HSM despite the fact it uses deterministic signing? I think HSMs are frequently overkill in their protection capabilities, but in the enterprise market (monster companies, banks, financial institutions... our target market  ), using FIPS-certified HSMs is a requirement, not a bonus. Trezor is a solid low-cost version of an HSM that doesn't come with any such certifications or protections (such as self-destruction upon tampering), but it doesn't need it for its target market. It's still a very strong HW model (as far as I can tell). I also believe that in the context of multisig wallets, the quorum of devices needed to sign can replace much of need for super-hardcore security of each individual device. However, in the banking & government world, they don't really care. Use an HSM or you're wasting their time. It's what they understand, and "overkill" is much preferable to risking "under-protected." In this context, I believe Trezor will suit the needs of most users and organizations that don't have such requirements. And for them, it's important to have deterministic signing as you need a way to audit the firmware that comes with the Trezor. Without deterministic signing, you have no way to know whether there's a backdoor in the signing algo. Gmaxwell has enumerated some pretty brilliant attacks in the past that can be performed if you compromise the RNG for signing, even if you upload your own seed entropy ... the wallet can be compromised with a few signatures, in a way that only the person that planted the backdoor can detect, and only from watching the blockchain. In the enterprise/gov't world, these devices hold the most important keys in the world and both the hardware and software are heavily scrutinized by NIST, etc. Trezor is not. P.S. - If you couldn't tell, Armory has shifted a lot of focus recently into the "enterprise" market -- banks, financial institutions, etc. This is where we see Armory having the biggest impact -- they don't want to have BitGo or Xapo protecting their funds, they want to do it themselves! See my recent article on more enterprise security concepts: https://bitcoinmagazine.com/19234/key-ceremony-auditable-private-key-security-practices/ |
|
|
|
|
I wish people would stop referring to "you are at risk if you don't use RFC6979". We have seen in the wild, poorly-supported platforms, with poorly implemented RNGs cause problems for people that reuse addresses. However, Armory only runs on systems with proper RNG capabilities AND using an RNG for ECDSA signing is part of the NIST standard. RFC6979 is exactly what it says "Request for Comments". It's not a standard, never been approved by any organization. I recognize that it might be more trustworthy than the javascript RNG or Android RNG (which have both caused problems in the past), but in our environment I'd prefer to use the NIST/FIPS standard RNG version of signing.
For instance, we're working on HSM integration now, and the whole thing is a giant [$15,000!] FIPS-certified hardware and software stack. If we tried to implement RFC6979 we'd be breaking all the crypto certifications of the device. This would mean our HSMs would immediately be unsuitable for any government use. This means it would be unsuitable for a wide variety of environments that depend on FIPS certifications.
This doesn't mean that I don't think RFC6979 is useful. It's that it's a tradeoff between using an approved, standardized process, and using a "proposed" process that addresses shortcomings in some platforms that don't even meet sanity checks for RNG capability. While I think it would be tough to argue that the RFC6979 process was insecure, we don't like modifying such sensitive parts of crypto processes without at least some review by standards bodies (with real cryptographers).
My attitude on all this is: I personally believe (using judgement) that RFC6979 is a good choice, as standardizing it across applications solves issues with platforms using weak RNGs, as any shortcomings it might have are better than having a bad RNG behind the signing. But I'm not going to shove all our users into it (at least without a way to disable it) on platforms that have solid RNGs and can apply the approved signing algorithms. For now, we've made det-signing opt-in, and I think pending further review we'll switch the default to make it opt-out.
|
|
|
|
getting dependency error not satifiable: libstdc++6(>=4.7) in Ubuntu 12.04 32 bit on attempted install of 0.93
Note that 0.93 can't go online in x86. Also, it requires C++11 so you'll need a libstd that is recent enough. You can probably get that package from the LTS backports repo. do we have to install 0.93 on both online and offline pc's?
Only the online machine Ugh, I just realized I bet we broke the 12.04 offline bundle with this release. I bet no one tested that... we really need to widen the testing net better. In the future, we might offer quadruple bounties for the first bug found in each of a bunch of categories. That would include testing the offline bundles, and lots of corner case features... I might need to update the offline bundles and re-release 0.93... |
|
|
|
Great work as always. I particularly appreciate the highly accessible source code (last night, GnuPG's source made me a very sad panda). Any thoughts on BIP0039? I'm not so worried as I've written the functionality I desire myself; I'm just curious. No, we already had someone offering to pay us to implement something equivalent as a plugin and we turned him down I think two things are getting conflated here. There's two parts to BIP39: one is encoding the wallet seed as a set of words (instead of Armory's "EasyType16" paper backups), and the other is the option to encrypt it with a password. I'm not thoroughly opposed to the word list encoding, it the encryption of the seed data will not be supported (which leads users to create, effectively, brainwallets), and seed sentences short enough to be memorized (which leads to actual brainwallets). However, do I like BIP39 for the fact that handwriting the seed data--instead of printing it--becomes much more reliable. Bad handwriting is much easier to overcome when human words are involved. You can have a few indistinguishable characters and it can still be readable. Users have asked us about brainwallets before (and as goatpig said, some have offered us money). We want nothing to do with brainwallets, or encrypted backup data (encrypting it defeats the purpose of having a backup!). However, as a mechanism for helping users reliably write down their seed data, I like it. I just don't know if there's a way to use it without encouraging memorization. For that reason I haven't made BIP39 a priority. |
|
|
|
Armory 0.93.1 is Now Available!Download links below Signed tag "v0.93" in https://github.com/etotheipi/BitcoinArmoryUpgrade with Secure Downloader in existing Armory is preferred (Help->Update Software) The website has not been updated. Sorry! We changed the website a couple months ago and forgot that we don't have the scripts worked out for it yet. Our updates only hit the secure downloader, not the website! Will have a manual update to the website soon. (as a workaround, you can always get the version from the website and use the secure downloader to immediately upgrade) I'm pleased to announce the final release of Armory v0.93. This release is especially relevant to the D&TD forum, as it implements a database mode we call "supernode" which does arbitrary blockchain lookups/slicing (instant importing & sweeping of any arbitrary address/script/wallet). Along with it comes a more-robust Armory daemon (armoryd.py) which can be used remotely via JSON-RPC or modified in-place with your code to power your web service, exchange, etc. Using armoryd.py along with the --supernode flag gives you a full-featured Bitcoin management platform on which to build your service with no external dependencies (such as blockchain.info for arbitrary balance lookup). Your service can now integrate hot wallets, cold wallets, watch-only wallets, message signing, unsigned tx creation, and all multi-signature lockbox features. NOTE: If you already use Armory, always get the latest version from the "Secure Downloader" (Help->Update Software). The links below are only for those who do not yet have a trusted version of Armory (or running a version so old it doesn't have the secure downloader). If you use the download links below, please check the GPG signatures of the last link and confirm hashes! Armory 0.93.1 for Windows XP, Vista, 7, 8+ (64-bit) Armory 0.93.1 for MacOSX 10.7+ (64bit) Armory 0.93.1 for Ubuntu 12.04+ (32bit) Armory 0.93.1 for Ubuntu 12.04+ (64bit) Armory 0.93.1 for RaspberryPi (armhf) Armory 0.93.1 Offline Bundle for Ubuntu 12.04 exact (32bit) Armory 0.93.1 Offline Bundle for Ubuntu 12.04 exact (64bit) Armory 0.93.1 Offline Bundle for RaspberryPi (armhf) Armory 0.93.1: Signed hashes of all installers
CHANGELOG:
VERSION 0.93
Released Feb 21, 2015
- Compatible with Bitcoin Core 0.10 and "headers-first"
The most recent version of Bitcoin Core includes a parallel network
synchronization feature called "headers-first" which is incompatible
with previous versions of Armory. This version is required to use
Bitcoin Core 0.10 and newer. Torrent-based bootstrapping will
be removed in the next version of Armory.
- New Scalable Blockchain Engine
This version of Armory will look very similar to previous versions,
but actually has a completely new, scalable database engine (using
LMDB instead of LevelDB). The engine can now handle wallets with
millions of addresses and transactions!
- Rebuild Required (but much faster!)
The new database engine requires rebuilding and rescanning. You
will be prompted as soon as you start up 0.93 the first time.
However, due to the new blockchain engine, this process is
considerably faster than before. Generally less than 45 min!
NOTE: This is NOT redownloading the blockchain. It is only
rebuilding the local databases that Armory creates for itself.
- Improved Threading and Reliability
With the new backend comes overhauled inter-thread messaging. This
resolves a whole class of reliability issues that Armory has had in
the past, especially with large wallets and transaction histories.
- Address and Wallet Importing in Background
Importing wallets and addresses now induces background scans which
do not disable the interface (previously forced you into offline
mode for the duration of the scan).
- Supernode Mode
Use the "--supernode" flag before creating the databases to create
a supernode database that enables instant address & wallet import.
This is an enabling feature for high-volume, consumer facing apps
and services to be built on Armory, such as exchanges and block-
explorers. NOTE: Running with --supernode will result in an Armory
database approximately double the size of the blockchain!
- Improved armoryd.py
The daemon version of armory, armoryd.py, has been fully updated and
tested with the new database engine. Also includes a new "webshop"
sample application that demonstrates basic usage of armoryd.py to
collect & verify payments, generate unsigned transactions, etc.
- RFC6979 Deteministic Signing (via CLI args)
Armory now has a deterministic signing mode based on RFC6979.
The code passes all test vectors, but disabled by default pending
more rigorous review. It can be enabled using the --detsign
command-line flag.
Thanks to everyone on the Armory team for their hard work in developing, tweaking, testing, and more testing of the code in this release. And especially goatpig, who was instrumental in upgrading the database engine and responding extremely quickly (and effectively) to the variety of issues you would expect to pop up when overhauling such a large part of the code base. He's even got more tricks up his sleeve, for 0.93.1. Stay tuned!
|
|
|
|
Well, now I really screwed up. I updated to 0.92.99.7-testing, old database was deleted, and now armory keeps crashing as soon as it starts building databases, I tried like 6 times  How did you delete the old DB? Within Armory? Or manually deleted the folder? I just realized we probably haven't had much testing of the wipe-old-databases-and-rebuild process. A log file through our support channel would be great. @doug_armory: can you test this in OSX? Based on another report from earlier, this might be OSX-specific. |
|
|
|
Don't see 0.92.99.7-testing, it says last update retrieved 4 months ago, maybe because I have my system set up to run through Tor?
EDIT: I managed to reactivate secure download by tweaking the "privacy setting", but i see 0.92.99.7 only on Windows - I'm a mac user.
Oh, the navigation system for that is a mess, and I've been meaning to rework it. Select an earlier version of OSX than the latest. You should then see it. |
|
|
|
Oops, I just updated to Bitcoin Core 0.10.0 and fired up Armory 0.92.3, it looks stuck on "building databases"... Did I screw up?
Use the secure downloader to grab 0.92.99.7-testing. It's a release candidate and should be officially renamed to 0.93 tomorrow (or latest Monday). You'll wipe the DBs, but the rebuild is super fast! Thank goatpig for that |
|
|
|
|
Actually, I had intended to put this in then forgot. I actually implemented this in another branch and it turned out to be somewhat simple.
However, it looks like we're just going to lock down 0.93 right now and add that suggestion to 0.93.1. Actually 0.93.1 is very close to done and can go into testing as early as next week (assuming we actually release 0.93 this week)
|
|
|
|
|
I know that Counterparty has implemented offline/cold signing for single-signature wallets, compatible with Armory. Not sure about multi-signature lockboxes. It wouldn't surprise me if they did. They seemed pretty excited about Armory interoperability and already integrated Armory's message format.
However, if it's going to work, you are in the wrong dialog. This is not a "Message Signing" operation, that's for something else (and not a widely used operation). You would need to the the "Lockboxes (Multi-Sig)" button on the main window, make sure the 2-of-3 lockbox is loaded into the interface, then select it and click "Review and Sign" at the bottom.
If you don't know what I'm talking about, then I would guess they are not providing sufficient support for Armory lockbox interop.
|
|
|
|
Wow, epic. Thanks for that link, I hadn't seen that yet. Indeed Fanny is quite a piece of malware. To save anyone else reading the effort of finding the section: Fanny: A computer worm that exploited what in 2008 were two zero-day vulnerabilities in Windows to self-replicate each time an infected USB stick was inserted into a targeted computer. The main purpose of Fanny was to conduct reconnaissance on sensitive air-gapped networks. After infecting a computer not connected to the Internet, Fanny collected network information and saved it to a hidden area of the USB drive. If the stick was later plugged in to an Internet-computer, it would upload the data to attacker servers and download any attacker commands. If the stick was later plugged into the air-gapped machine, the downloaded commands would be executed. This process would continue each time the stick was switched between air-gapped and Internet-connected machines.
Luckily (?!?) all this malware seems to be specifically targeted at Windows. In fact, there's no mention of any other OSes, and many of the descriptions of the malware are extremely Windows-specific: GrayFish is the crowning achievement of the Equation Group. The malware platform is so complex that Kaspersky researchers still understand only a fraction of its capabilities and inner workings. Key to the sophistication of GrayFish is its bootkit, which allows it to take extraordinarily granular control of the machines it infects.
"This allows it to control the launching of Windows at each stage," Kaspersky's written report explained. "In fact, after infection, the computer is not run by itself anymore: it is GrayFish that runs it step by step, making the necessary changes on the fly."
That's not to say it couldn't be done on Linux or Mac ... but simply those weren't the target platforms. And this is literally the most advanced malware on the planet, so we can hope that there's a high barrier to entry to replicate this on the other OS (as I write this, I realize there's no guarantee that they haven't already...) |
|
|
|
|
Show Posts
