[ANN] Armory 0.93.1 Official Release

[AussieHash]

I've successfully installed armory_0.92.3_rpi_bundle.tar.gz on Pi B / Pi B+ / Pi 2 (raspbian wheezy) and BBB (debian wheezy + ubuntu 14.04).

However on ODROID C1 (Ubuntu 14.04, Feb 10th ISO) there is an error
 ImportError: No module names qt4reactor.  

For some reason qt4reactor.py is allocated view = owner only / change = owner only / execute = nobody.

 sudo chmod +755 /usr/lib/armory/qt4reactor.py fixes the problem, and 0.92.3 works.

In order to get armory_0.93_raspbian-armf.tar.gz working (Secure Downloaded and verified within armory), I copied the 0.92.3 offline bundle's Install_DblClick_RunInTerminal.py, ran

 sudo python Install_DblClick_RunInTerminal.py in the same folder as the 0.93 tar.gz and ran once again

 sudo chmod +755 /usr/lib/armory/qt4reactor.py

Success !

[1714822543]

1714822543

[1714822543]

1714822543

[1714822543]

1714822543

[1714822543]

1714822543

[1714822543]

1714822543

[doug_armory]

Big congratulations, really pleased with this project and where it's heading right now.

One small question:  when can we expect more info on the safety of enabling deterministic signing?

Thanks, and good question. The long and short of it is that Alan & I are figuring out the best way forward. My personal opinion is that the code is safe to use. I closely followed the path that Crypto++ uses whenever data is signed. (No small feat considering the ugliness of the Crypto++ codebase.) I use the appropriate test suites from RFC 6979 and from the Trezor codebase, and plan to add the libsecp256k1 test vectors sooner or later. I considered the codebase to be safe enough that I conducted several significant mainnet transactions using det signing. (Gotta eat your own dogfood, right?) Everything worked fine, and I didn't lose any coins.

Of course, personal opinions don't mean squat. There could be some weird thing I missed. So, for now, Alan's going to take a close look once he has a little free time, and we'll decide from there where to go.

[Carlton Banks]

One small question:  when can we expect more info on the safety of enabling deterministic signing?

[...]
Of course, personal opinions don't mean squat. There could be some weird thing I missed. So, for now, Alan's going to take a close look once he has a little free time, and we'll decide from there where to go.

Sounds like a good enough reason to justify the disabling by default, you need at least 10 opinions  . But I I know, you mean opinions from people who make it their business to know cryptography from all the theory based angles who can spot signatures leaking information in some way no-one's thought of, etc. I might wait just a while to use it, but it sounds like a good thing in principle (it makes address re-use safer/safe IIRC)

[bitpop]

Big congratulations, really pleased with this project and where it's heading right now.

One small question:  when can we expect more info on the safety of enabling deterministic signing?

[...]Of course, personal opinions don't mean squat. There could be some weird thing I missed. So, for now, Alan's going to take a close look once he has a little free time, and we'll decide from there where to go.

Sounds like a good enough reason to justify the disabling by default, you need at least 10 opinions  . But I I know, you mean opinions from people who make it their business to know cryptography from all the theory based angles who can spot signatures leaking information in some way no-one's thought of, etc. I might wait just a while to use it, but it sounds like a good thing in principle (it makes address re-use safer/safe IIRC)

What do you mean by deterministic signing?

[Carlton Banks]

What do you mean by deterministic signing?

It takes the random number generator out of the process for generating a signed transaction. Somehow (I do not know the details). It makes it safer, as the signatures can't leak any information (i.e. something to help calculate the private key...) when using weak RNG implementations, plus some other benefits I expect. Also, it's last on the changelog list for 0.93

[bitpop]

What do you mean by deterministic signing?

It takes the random number generator out of the process for generating a signed transaction. Somehow (I do not know the details). It makes it safer, as the signatures can't leak any information (i.e. something to help calculate the private key...) when using weak RNG implementations, plus some other benefits I expect. Also, it's last on the changelog list for 0.93

Oh so instead of random it uses a rolling nonce

Idk, personally I think a bad write can make you reuse an increment and boom you're done. But what do I know.

If it adds a random number, it sounds very good.

[etotheipi]

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.  

[cypherdoc]

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?

[etotheipi]

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/

[bitpop]

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.  

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.

[etotheipi]

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.

[bitpop]

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.

Oh ok that makes sense. What's protecting an identical transaction?

[cypherdoc]

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.

Oh ok that makes sense. What's protecting an identical transaction?

nothing prevents an identical tx.  but only the first will be accepted by the network, so there's no use in duplicating.

edit:  this is also what allows the "auditing" or "determinism" that eto was referring to.

[cypherdoc]

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.

we all want Armory to prosper as it benefits all of our security.

this is a very reasonable approach.

[adam3us]

What do you mean by deterministic signing?

It takes the random number generator out of the process for generating a signed transaction. Somehow (I do not know the details). It makes it safer, as the signatures can't leak any information (i.e. something to help calculate the private key...) when using weak RNG implementations, plus some other benefits I expect. Also, it's last on the changelog list for 0.93

Oh so instead of random it uses a rolling nonce

Idk, personally I think a bad write can make you reuse an increment and boom you're done. But what do I know.

If it adds a random number, it sounds very good.

No thats not how it works.  Deterministic DSA is to use k=H(d,m) as the nonce.  In that way if you sign the same message m=H(transaction), you'll get the same signature.

Adam

[adam3us]

What do you mean by deterministic signing?

It takes the random number generator out of the process for generating a signed transaction. Somehow (I do not know the details). It makes it safer, as the signatures can't leak any information (i.e. something to help calculate the private key...) when using weak RNG implementations, plus some other benefits I expect. Also, it's last on the changelog list for 0.93

Oh so instead of random it uses a rolling nonce

Idk, personally I think a bad write can make you reuse an increment and boom you're done. But what do I know.

If it adds a random number, it sounds very good.

No thats not how it works.  Deterministic DSA is to use k=H(d,m) as the nonce.  In that way if you sign the same message m=H(transaction), you'll get the same signature, so its also stateless.

And this is important because if you reuse k with different messages you reveal a simultaneous equation allowing the private key to be computed.  private key is d, public key is Q=dG, address is a=H(Q),  signature is (s,r) where s=(h(m)+rd)/k, r=[kG].x, n is the order of the curve.

s=(h(m)+rd)/k mod n
s2=(h(m2)+rd)/k mod n

=> sk = h(m)+rd, s2k = h(m2)+rd
=> (s-s2)k = h(m)-h(m2)
=> k=(h(m)-h(m2))/(s-s2).

now we know k and substituting:

sk=h(m)+rd
=> d=(sk-h(m))/r

There are worse attacks where even knowing a bias of a few bits eg http://www.irisa.fr/celtique/zapalowicz/papers/asiacrypt2014.pdf can result in d being recovered over a modest number of signatures, or that the NIST original DSA standard was partly broken due to a small bias in k generation algorithm by Bleichenbacher, see section 2.2 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.122.3190&rep=rep1&type=pdf

Avoiding reuse of k is also tricky because that implies log transactional storage in the RNG state.  What if the RNG is in a VM, and the VM snapshotted and rolled back?  What if the RNG is poorly seeded (eg in a server environment).

The lesson for bitcoin is dont reuse addresses but as there are usability difficulties with that also dont have biases in k, and dont rely on transactional, non-rollbackable storage: hence deterministic DSA.

Adam

[picobit]

Avoiding reuse of k is also tricky because that implies log transactional storage in the RNG state.  What if the RNG is in a VM, and the VM snapshotted and rolled back?  What if the RNG is poorly seeded (eg in a server environment).

Is this a real risk with Armory?  Or does it have a sufficient alternate source of entropy / does not store the RNG state between sessions / does something else smart to prevent this attack vector.

The reason that I ask is that my daily usage wallet is an Armory wallet with the offline computer being a VM (I know, a real offline computer is better, and I use that for the main offline storage).  And I do roll it back after each use, from a (probably mistaken) idea that this increases security marginally by wiping whatever any malware may have stored before it somehow magically breaks out of the VM :-)  Is doing this a huge mistake, and have I been saved by so far not having reused addresses?

[solitude]

Is anyone else getting this error right after "Initializing Bitcoin Engine" completes?



Of course I've done the "Rebuild and Rescan" numerous times to no avail

Any ideas?

[kylerwk]

Just upgrade to Armory 0.93 and Bitcoin Core 0.10.  Things seem to be going well until my system get to the Organizing blocks stage.  Then Armory just gets stuck and won't move on to the next step.  I've tried to rebuild and rescan to no avail.  No errors happen, it just won't move on.

Any other ideas?

Thanks

[solitude]

Just upgrade to Armory 0.93 and Bitcoin Core 0.10.  Things seem to be going well until my system get to the Organizing blocks stage.  Then Armory just gets stuck and won't move on to the next step.  I've tried to rebuild and rescan to no avail.  No errors happen, it just won't move on.

Any other ideas?

Thanks

I have the same issue in the post above.  Glad to know I'm not the only one.