Topic: [ANN] Armory 0.93.1 Official Release - page 5. (Read 16724 times)

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.  

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.

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

What do you mean by deterministic signing?

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)

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.

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 !

Yes

thank you very much!

Great, can I reuse an old blockchain copy?

Thank you for the efforts, keep up the good work !

That offering might be more for business with paid support

I am also curious about this supernode functionality, in depth documentation would be useful

Where can I find more info on supernode?

Thanks for your help. You are right - I did ask that, although it was more of a rhetorical question - I was already assuming that the new version was working ok for a lot of people, otherwise I guess it wouldn't have been released yet!

Anyway, I've got Armory up and running now - I just have to run Bitcoin core/q/d on it's own.

You did ask Does anybody else now have a problem of incompatibility?

Try deleting everything from Bitcoin and armory except wallets. Fully sync Bitcoin before starting armory.

Actually Bitcoind shouldn't be running afaik, armory starts qt not d I think, I run it manually though

You might have an old version running somehow or another program running it for you

Or armory is starting the daemon and you're starting qt which kills the daemon

'Mine's perfect' - that comment doesn't really help me - my wife's is also now running, but we didn't learn much from that either.

I'm running bitcoind independantly - and seem to be getting on better - currently scanning transaction history whereas before Armory 'locked up' almost as soon as bitcoind failed.

Congrats! Just thinking a few years ago you got laid off and began Armory and here we are, the #1 wallet!