Re:How is NSA breaking so much crypto? (2015)
by mirimir on Saturday December 17, 2016 @06:54AM
(#13200350)
There's some serious confusion here, I think. Maybe it's local [;)] but here goes ...
> Furthermore if I was someone holding solutions to cherry-picked primes for well-understood algorithms in wide use ...
Well, the article notes:
> For the nerds in the audience, here’s what’s wrong: If a client and server are speaking Diffie-Hellman, they first need to agree on a large prime number with a particular form. There seemed to be no reason why everyone couldn’t just use the same prime, and, in fact, many applications tend to use standardized or hard-coded primes. But there was a very important detail that got lost in translation between the mathematicians and the practitioners: an adversary can perform a single enormous computation to “crack” a particular prime, then easily break any individual connection that uses that prime.
That prime is the "dhparam.pem". It's used in bootstrapping the encrypted connection. And it's my understanding that this is entirely distinct from the issue of "cherry-picked primes for well-understood algorithms in wide use". This vulnerability is simply using "standardized or hard-coded primes". Cipher vulnerabilities are about ...
And that's where my understanding ends. Maybe someone can complete the argument. Or sort me out ;)
> Furthermore if I was someone holding solutions to cherry-picked primes for well-understood algorithms in wide use ...
Well, the article notes:
> For the nerds in the audience, here’s what’s wrong: If a client and server are speaking Diffie-Hellman, they first need to agree on a large prime number with a particular form. There seemed to be no reason why everyone couldn’t just use the same prime, and, in fact, many applications tend to use standardized or hard-coded primes. But there was a very important detail that got lost in translation between the mathematicians and the practitioners: an adversary can perform a single enormous computation to “crack” a particular prime, then easily break any individual connection that uses that prime.
That prime is the "dhparam.pem". It's used in bootstrapping the encrypted connection. And it's my understanding that this is entirely distinct from the issue of "cherry-picked primes for well-understood algorithms in wide use". This vulnerability is simply using "standardized or hard-coded primes". Cipher vulnerabilities are about ...
And that's where my understanding ends. Maybe someone can complete the argument. Or sort me out ;)