Isn't the Dual EC implementation in OpenSSL broken anyways?
Dual EC DRBG is a cryptographic PRNG.It has nothing to do with ECDSA as far as I'm aware.
Topic: Did Satoshi foresee that secp256r1 was compromised? (Read 4584 times)
It has nothing to do with ECDSA as far as I'm aware.
Isn't the Dual EC implementation in OpenSSL broken anyways?
http://nakedsecurity.sophos.com/2013/12/22/the-openssl-software-bug-that-saves-you-from-surveillance/
From TFA:
http://nakedsecurity.sophos.com/2013/12/22/the-openssl-software-bug-that-saves-you-from-surveillance/
From TFA:
Quote
With this in mind, experts have been wondering how much software out there in the real world is using the Dual EC DRBG, and potentially vulnerable to cryptographic manipulation as a result.
OpenSSL, for example, one of the most widely-used encryption libraries, implements all four of the SP800-90A algorithms, ironically as part of achieving what is known as FIPS 140-2 certification.
And here is the happy ending.
Despite passing FIPS 140-2 tests many times over the years, the OpenSSL implementation of Dual EC DRBG is buggy.
Not just buggy, but totally broken and busted.
Simply put, it cannot be made to work in real-world software, and the fact that it has taken years for anyone to notice makes it reasonable to assume that no real-world software has ever even bothered to use it.
In the words of the OpenSSL Foundation itself, "We have no plans to fix this bug."
OpenSSL, for example, one of the most widely-used encryption libraries, implements all four of the SP800-90A algorithms, ironically as part of achieving what is known as FIPS 140-2 certification.
And here is the happy ending.
Despite passing FIPS 140-2 tests many times over the years, the OpenSSL implementation of Dual EC DRBG is buggy.
Not just buggy, but totally broken and busted.
Simply put, it cannot be made to work in real-world software, and the fact that it has taken years for anyone to notice makes it reasonable to assume that no real-world software has ever even bothered to use it.
In the words of the OpenSSL Foundation itself, "We have no plans to fix this bug."
yes.
Quote
Oh ok. Do you reckon there is any need to switch bitcoin over to Ed25519 at the moment? Or do you trust the magic numbers in Secp256k1?
Would Ed22519 be allowed to implement without a major fork? or it was pure luck.
or it was satoshi who chose the NIST recommended parameters!
They are equally as likely based on a sound sample of a fart during a phone talk between George W. Bush and Putin, intercepted by NSA and encoded in this number or the phrase "Satoshi Nakamoto's mom" run through a key derivation function... 
or it was pure luck.
or it was satoshi who chose the NIST recommended parameters!
Well, he was working on a system that does at least a partial brute-force attack on secure hashes. Seeing some magic constants whose only protection is that a "random"(?) value is being hashed and the hash is being used instead of the value itself might at least look suspicious enough for someone.
I however also doubt that there was very much of a design choice - maybe he did read through docs and whatnot, but realistically he just wanted something to get the job of signature verification done. Afaik bitcoin uses openssl, so he saw 2 defined curves with the same parameters, maybe he checked at least, which one has better performance characteristics or security, so he would have ended up with the k-curve, or it was pure luck.
I however also doubt that there was very much of a design choice - maybe he did read through docs and whatnot, but realistically he just wanted something to get the job of signature verification done. Afaik bitcoin uses openssl, so he saw 2 defined curves with the same parameters, maybe he checked at least, which one has better performance characteristics or security, so he would have ended up with the k-curve, or it was pure luck.
Ninja math! Hahah.
"I am going to count to three..."
-MarkM-
"I am going to count to three..."
-MarkM-
If we are to believe the Snowden documents then we must "assume the existence of profound math which is unknown to the public"
You missed my point. I wasn't expressing any opinion on that fact. I was saying that if it is true the mystery math could apply equally (or more so) to other arbitrary choices that otherwise look good. That generally "Foo could have ninja math" is a concerning risk but it's not generally one that tells us which of two otherwise very similar things is better. (It might, however, suggest a stronger preference for symmetric cryptography, as that rests on math which is believed to be fundamentally more sound) If it's possible for any of these ECC systems to be intentionally insecure that would require some profound math which is unknown to the public. If we assume the existence of profound math which is unknown to the public, I do not see a reason to also assume Ed25519 is more secure.
If we are to believe the Snowden documents then we must "assume the existence of profound math which is unknown to the public"
http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=0
from the bullrun briefing sheet:
In recent years there has been an aggressive effort, lead by NSA, to make major improvements in defeating network security and privacy involving multiple sources and methods, all of which are extremely sensitive and fragile. These include: Computer Network Exploitation (CNE); collaboration with other Intelligence Agencies; investment in high-performance computers; and development of advanced mathematical techniques.
I think Satoshi was clearly not an expert cryptographer. His interest in ECC went as far as saying "this does digital signatures and takes less space than RSA". He may or may not have chosen secp256k1 because he saw mention of performance - if he did, then he didn't mention that when I explicitly asked him about it. Alternatively it could have been as simple as finding some example code somewhere on the net that happened to use that curve. He plugged it in, it worked, done.
It appears to me that he was creating a system he knew works in principle with tools he just stumbled upon, his choice of language, database, algorithms, constants, opcodes etc. seem to be arbitrary, sometimes lucky, sometimes poor.
I do no longer wonder of his particular decisions. As if he knew the system works if it has certain features, details are not relevant to bootstrap, and will be sorted out by others after him.
Given Satoshi's desire to stay anonymous, he wouldn't have wanted to out himself as a crypto expert, or any kind of expert - that would really narrow down the search field. His best move is to appear to be "just good enough" at everything and to make any choices informed by high-level expertise look like mere happenstance.
I think Satoshi was clearly not an expert cryptographer. His interest in ECC went as far as saying "this does digital signatures and takes less space than RSA". He may or may not have chosen secp256k1 because he saw mention of performance - if he did, then he didn't mention that when I explicitly asked him about it. Alternatively it could have been as simple as finding some example code somewhere on the net that happened to use that curve. He plugged it in, it worked, done.
As it happens, whatever the reason for selecting that curve, it's worked out pretty well for us all things considered. Of all the issues Bitcoin has, it turns out that ECC isn't one of them.
As it happens, whatever the reason for selecting that curve, it's worked out pretty well for us all things considered. Of all the issues Bitcoin has, it turns out that ECC isn't one of them.
If he was not an expert cryptographer and secp256k1 was less used that r1, how did he end up with it? Random sample code would rather contain an "r" curve.
I think he was quite serious about Bitcoin and took enough time to think through many complex aspects of it (and implement!) that many Bitcoin enthusiasts still don't get. Even if he wasn't an "expert" by your standard, I doubt he plugged in ECC implementation from a random sample code. I think he had reasons for almost every decision he was making.
I think Satoshi was clearly not an expert cryptographer. His interest in ECC went as far as saying "this does digital signatures and takes less space than RSA". He may or may not have chosen secp256k1 because he saw mention of performance - if he did, then he didn't mention that when I explicitly asked him about it. Alternatively it could have been as simple as finding some example code somewhere on the net that happened to use that curve. He plugged it in, it worked, done.
As it happens, whatever the reason for selecting that curve, it's worked out pretty well for us all things considered. Of all the issues Bitcoin has, it turns out that ECC isn't one of them.
As it happens, whatever the reason for selecting that curve, it's worked out pretty well for us all things considered. Of all the issues Bitcoin has, it turns out that ECC isn't one of them.
It's kinda interesting how "trust" could be misleading. Same people who advocated switching to a "more deployed random curve" just 2.5 years ago (https://bitcointalksearch.org/topic/secp256k1-2699) now seriously distrust NIST parameters and prefer Koblitz curves for allowing less freedom in parameter choice.
Even if Satoshi didn't know anything in particular about backdoors in random parameters, he might have chosen a less suspicious curve.
Even if Satoshi didn't know anything in particular about backdoors in random parameters, he might have chosen a less suspicious curve.
The curve we use has fewer (no?) places to hide magic NSA-selected numbers. At the moment the only reason to doubt it would be the general aura of distrust that now surrounds anything NIST does, which is insufficient by itself. The random curves look bad because even though nobody knows what kind of maths would allow them to be undermined, the way the selection process worked is deeply suspicious.
Oh ok. Do you reckon there is any need to switch bitcoin over to Ed25519 at the moment? Or do you trust the magic numbers in Secp256k1?
If it's possible for any of these ECC systems to be intentionally insecure that would require some profound math which is unknown to the public. If we assume the existence of profound math which is unknown to the public, I do not see a reason to also assume Ed25519 is more secure.Including it would be a significant burden (a fast ecc signature validation implementation is not simple code, and would not overlap with our existing code) which would carry its own risks.
It would be kind of genius if the reason Bitcoin does not use secp256r1 was because Satoshi knew about its possible weaknesses.
No need to assume that. Secp256k1 was sort of the obvious choice for Bitcoin because of the performance considerations. (Today you would have chosen Ed25519 instead)Oh ok. Do you reckon there is any need to switch bitcoin over to Ed25519 at the moment? Or do you trust the magic numbers in Secp256k1?
It would be kind of genius if the reason Bitcoin does not use secp256r1 was because Satoshi knew about its possible weaknesses.
No need to assume that. Secp256k1 was sort of the obvious choice for Bitcoin because of the performance considerations. (Today you would have chosen Ed25519 instead) Jump to: