Show Posts
Thanks to Snowden & Bruce Schneier, we now know the answer. secp256r1 has an NSA backdoor - see http://www.linuxadvocates.com/2013/09/is-openssls-cryptography-broken.html
So - while a backdoor is not really a "honeypot" this is the best answer:-
So - while a backdoor is not really a "honeypot" this is the best answer:-
* NIST has made an intentionally poor suggestion to use secp256r1, so it acts as a honeypot. they have found that Koblitz curves are actually more secure than the random ones.
* Satoshi had information which led him/them to believe that secp256r1 was indeed a honeypot and that secp256k1 was the better choice for real security
* Satoshi had information which led him/them to believe that secp256r1 was indeed a honeypot and that secp256k1 was the better choice for real security
something i find rather disconcerting about bitcoin is a lack of justification/explanation for some of the design decisions, in particular the choice of doing 256-bit ecdsa keypairs over secp256k1 vs secp256r1 (a.k.a. P-256) for wallets...
can anyone provide a justification for using secp256k1 over secp256r1 besides "that's just the way it is" or "so it was written in the great book"?
can anyone provide a justification for using secp256k1 over secp256r1 besides "that's just the way it is" or "so it was written in the great book"?
Since 2007 there is evidence that the supposedly random constants in secp256r1 may have been manipulated by the NSA to provide a backdoor. See http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115. Presumably Satoshi was aware of this. The Koblitz curves cannot have been so "cooked"; see http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters/10273#10273.
I know this is a somewhat old thread, but as this comes up as a top answer when searching for secp256r1 , I feel some of the above points need to be clarified.
Firstly, people are comparing secp256r1 to Dual_EC_DRBG as if they're interchangeable (And some even seem to think that they're the same thing). They're not. They're two completely different algorithms that serve completely different purposes. Dual_EC_DRBG has been suspicious from the second it was published and plenty of people from the security industry have warned against using it. I believe someone recently was able to demonstrate a proof of concept of breaking the encryption when using their own curve parameters. The issue is that the specification gives a default curve that doesn't indicate where those parameters came from - it should be random.
However, secp256r1 has no such proof. There is a theoretical issue with it, though - its curve parameters are taken from a SHA1 hash (unlike Dual_EC_DRBG) of a seed value. It's very, very difficult to reverse a hash like that, which is what the NSA will have to have done in order to "trap" the algorithm. It's still theoretical and relies on them having undisclosed exploits that we're unaware of (unlike Dual_EC_DRBG which doesn't) - certainly a possibility and if you value your privacy, don't use it, but it's not quite as obvious as Dual_EC_DRBG. That doesn't make it "safe" per se, but then again it requires a much bigger leap for the NSA to have compromised. There hasn't been a "leak" (from Snowdon or otherwise) that I am aware of that indicates that secp256r1 is a honeypot, but there has for Dual_EC_DRBG.
By all means, if you're sceptical then don't use secp256r1 but let's not confuse it with a completely different algorithm.
