Hi People,
I know this may seem off topic, but I thought for those of us who might have Debian users generating key pairs that they put on CentOS systems people should be aware that
everybody who generated a public/private keypair or an SSL cert request on Debian or Ubuntu from 2006 on is vulnerable
Clint Dilks wrote:
Hi People,
I know this may seem off topic, but I thought for those of us who might have Debian users generating key pairs that they put on CentOS systems people should be aware that
everybody who generated a public/private keypair or an SSL cert request on Debian or Ubuntu from 2006 on is vulnerable
I've been following this story too after reading about it on SANS Internet Storm Center:
http://isc.sans.org/diary.html?storyid=4414
I wonder how far reaching this is. One wonders if any of the trusted root CAs have issued vulnerable certs as a result.
On Thu, May 15, 2008 at 12:20 AM, Clint Dilks clintd@scms.waikato.ac.nz wrote:
I know this may seem off topic, but I thought for those of us who might have Debian users generating key pairs that they put on CentOS systems people should be aware that
everybody who generated a public/private keypair or an SSL cert request on Debian or Ubuntu from 2006 on is vulnerable
Yes, it is very important to follow up on this issue as soon as you can (now) to see if any of your keys or those of your users are affected. Additionally, it should be noted that in the case of *DSA* keys, this can even affect users who do have good keys but used them to communicate with a Debian server with the botched OpenSSL. An explanation of this problem is provided here:
http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html
Take care, Daniel
On Thu, May 15, 2008 at 2:19 PM, Daniel de Kok me@danieldk.org wrote:
Yes, it is very important to follow up on this issue as soon as you can (now) to see if any of your keys or those of your users are affected. Additionally, it should be noted that in the case of *DSA* keys, this can even affect users who do have good keys but used them to communicate with a Debian server with the botched OpenSSL.
Jikes, rereading this, this does not seem accurate at all. Let me just quote the advisory:
"Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation."
Take care, Daniel
Daniel de Kok wrote:
"Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation."
Take care, Daniel
SANS have more on this today and will likely continue to update the story as new developments emerge:
To summarise, scripts that allow brute-forcing of keys are already in the wild - expect to see an upturn in activity on port 22 as a result. Further, for SSL secured websites, if the public key is known, no brute-forcing is even necessary.
Ned
On Thu, May 15, 2008 at 5:27 AM, Daniel de Kok me@danieldk.org wrote:
Jikes, rereading this, this does not seem accurate at all. Let me just quote the advisory:
"Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation."
That made perfect sense to me: If all the compromised systems used the same (unrandomized) seed for the values of k, it would not be too difficult for the determined cracker to break keys given enough CPU power and an algorithm that could generate the exact same series of k values (i.e., use the same "random" number generator, all of which are NOT random if you know the seed). All they need is one of the two algorithms in Steinar's note, and goodbye security!
In theory, this same approach could be used to break any SSL keys, but "guessing" the appropriate k value is roughly 2^128 times more difficult (which is the whole point).
mhr
-
Clint Dilks -
Daniel de Kok -
MHR -
Ned Slider