Add 0.10 release notes on improvement to signing security.
I dropped mention of libgmp that I had in my first draft because it looks like we'll be able to get that out prior to release.
This commit is contained in:
parent
90f7aa7778
commit
5fdbe67ad9
@ -95,3 +95,32 @@ are done, it always returns an immediate error with code -28 to all calls.
|
||||
This new behaviour can be useful for clients to know that a server is already
|
||||
started and will be available soon (for instance, so that they do not
|
||||
have to start it themselves).
|
||||
|
||||
Improved signing security
|
||||
=========================
|
||||
|
||||
For 0.10 the security of signing against unusual attacks has been
|
||||
improved by making the signatures constant time and deterministic.
|
||||
|
||||
This change is a result of switching signing to use libsecp256k1
|
||||
instead of OpenSSL. Libsecp256k1 is a cryptographic library
|
||||
optimized for the curve Bitcoin uses which was created by Bitcoin
|
||||
Core developer Pieter Wuille.
|
||||
|
||||
There exist attacks[1] against most ECC implementations where an
|
||||
attacker on shared virtual machine hardware could extract a private
|
||||
key if they could cause a target to sign using the same key hundreds
|
||||
of times. While using shared hosts and reusing keys are inadvisable
|
||||
for other reasons, it's a better practice to avoid the exposure.
|
||||
|
||||
OpenSSL has code in their source repository for derandomization
|
||||
and reduction in timing leaks, and we've eagerly wanted to use
|
||||
it for a long time but this functionality has still not made its
|
||||
way into a released version of OpenSSL. Libsecp256k1 achieves
|
||||
significantly stronger protection: As far as we're aware this is
|
||||
the only deployed implementation of constant time signing for
|
||||
the curve Bitcoin uses and we have reason to believe that
|
||||
libsecp256k1 is better tested and more thoroughly reviewed
|
||||
than the implementation in OpenSSL.
|
||||
|
||||
[1] https://eprint.iacr.org/2014/161.pdf
|
||||
|
Loading…
Reference in New Issue
Block a user