Affected keys include SSH keys [...] and session keys used
> in SSL/TLS connections.
It seems that people are insisting quite a lot on the bad keys, but
what worry me a lot more is that, apparently and very logically, past ssh
connections and any SSL session keys are to be considered compromised.
In other words, if a vulnerable key have been involved, and if someone
was able to intercept and save the encrypted data, he/she can now decipher
It, whether It is passwords, ssh sessions, secure pop/smtp sessions, ssl
tunnels or even database transactions. So you need to change every
passwords at risk (bothersome, but relatively easy), but also consider
that secure/confidential information, including credit card transactions
or whatever, have been disclosed, which is a much bigger problem.
I think that most security knowledgeable people understood that part.
For the others, then It is good that you understand It clearly now.
But what still bother me a bit, is in the case that both host keys are
not vulnerable, but one of the openssl implementation involved was.
For example, I have many host keys that have been generated from
Slackware or OpenBSD, and which are much longer than the default, so
clearly not vulnerable (at least, not vulnerable to this specific bug).
But even in that case, if one of the system involved in a SSL
transaction have a buggy version of openssl, I wonder if the session key
might still be guessed. If the vulnerable host is A, then my
understanding is that an attacker could guess "a" and "g exp(a)", so that
if he can get either "b" or "g exp(b)", he can crack the session key.
In other words, if host A and host B use a flawed openssl
implementation, then the communication can be compromised even if both
host keys are not vulnerable.
Here are my questions:
1. If both host use a flawed openssl, but good host keys, about how much
sessions keys the attacker will have to try? I expect that would be the
square of the number of probable values for "a", but I have no idea of the
number of probable values for a.
2. About how much time would It takes to break one session key, let say
using a small setup with 8 pentium IV at 2GHz just to give an idea. My
uneducated guess is that It could theorically takes significantly less
than a week.
3. If only one of the computer involved have a flawed openssl, but none
have a vulnerable host key, is It still practical to break the session
key? If yes, about how long could It takes?
The Diffie-Hellman algorithm is far in my memory, including the exact
way It is used in setting up an SSL transaction. I think that the
exchanged data are both signed *and* ciphered using RSA or DSA. If I am
right, all the "public" data are exchanged using the public host keys, so
if they are not vulnerable, maybe there is not enough information known to
the attacker easily crack the session key, even if the session key have
obviously been significantly weakened.
And a last question that came to my mind:
4. During the session key creation, do there is still some entropy left
from the clock, or something other than the process id? If you answered
question 1, you can probably easily answer this one.
I still need to change the passwords and host key of every possibly
affected system (mostly done), but I would feel better by knowing exactly
what to expect.
Thank you,
Simon Valiquette
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
