Re: Diffie-Hellman question
Thomas Shaddack wrote: I have a standard implementation of OpenSSL, with Diffie-Hellman prime in the SSL certificate. The DH cipher suite is enabled. Is it safe to keep one prime there forever, or should I rather periodically regenerate it? Why? If yes, what's some sane period to do so: day, week, month? No need. Kinda. The best known discreet logarithm attacks are such that if they succeed in the attack then they can easily apply their solution to anything encrypted with the same prime. A shared prime attracts attacks. Widely used primes can become a big target. These attacks are generally supposed to be beyond capability for the next X zillion years though. Or perhaps for ten years. This might seem garubonsendese in the naive it's safe' or 'it's not safe crypto paradigm. However, that isn't how crypto works. Cryptanalysis (the revealing of plaintext against the wishes of the encryptor) is an economic activity. No-one will bother putting in enough resources to break your 2k-bit modexp-based crypto unless they think it worthwhile. But if your prime is shared with several other people who are sending nuclear secrets, then your prime might become subject to attack. If the adversary has a log of a passively intercepted DHE-RSA-AES256-SHA secured SSL communication, presuming the ephemeral key was correctly generated and disposed of after the transaction, will the eventual physical retrieval of the DH prime (and the rest of the certificate) allow him to decode the captured log? The prime is public - anyone can know it - so it's retrieval won't affect anything. The question I think you are asking is if the secret key is retrieved, will I lose forward security, to which the answer is yes. For long-term forward secrecy you need to change the public key every every day or so. Use a long-term key to sign the daily keys. PGP does this. Once you have deleted the day's public key, you are OK (but see belaw!). The ephemeral keys cannot (or should not) be retrive(able)d. (below!) Or perhaps the question you were asking was if finding DL's mod _this prime_ becomes possible, will I lose forward security?, in which case the answer is yer fukked - as are we all - if one prime gets broken, they all will, sooner or later. -- Peter Fairbrother (Who is right now composing a talk about the uses of modexp in crypto, for those far more knowledgeable than I)
Re: Diffie-Hellman question
Thomas Shaddack writes: I have a standard implementation of OpenSSL, with Diffie-Hellman prime in the SSL certificate. The DH cipher suite is enabled. Is it safe to keep one prime there forever, or should I rather periodically regenerate it? Why? If yes, what's some sane period to do so: day, week, month? If the adversary has a log of a passively intercepted DHE-RSA-AES256-SHA secured SSL communication, presuming the ephemeral key was correctly generated and disposed of after the transaction, will the eventual physical retrieval of the DH prime (and the rest of the certificate) allow him to decode the captured log? The DH prime is not secret, and will not in general allow an adversary to decode the message. Only the private parts of the ephemeral DH keys used by the two sides are secret, and they are destroyed after use. The only theoretical concern is that if the DH prime were small enough, an adversary at some time in the future might be able to break the DH key exchange by calculating discrete logs mod the prime. To within a few orders of magnitude, this is thought to be equally as difficult as breaking an RSA modulus of the same size. If your prime is 2000 bits, then that should be safe for the foreseeable future, unless quantum computers turn out to be practical for breaking moduli of this size. In the unlikely event that it becomes possible to break the DH exchange by attacking the DH prime in this manner, then all key exchanges that were done using that prime would be broken (assuming they were recorded for later analysis and attack). The main work of the break is directed towards the prime itself. Once that is done, there is little additional work to break a key exchange which used that prime. This is the only reason you might want to think about changing DH primes occasionally, so that if some super technology of the future were able to attack even your 2000 bit prime, at least they'd have to run their program a few times rather than just once. But really, that's not much of a security gain, as you're only increasing the attacker's costs by a relatively small factor. And at this point the attack would have to be viewed as extremely speculative anyway. So there's not much reason to change your prime. This is unlike the case with RSA moduli, where you not only have this very hypothetical risk of a future technology breakthrough to allow factoring, but you also have to face the genuine threat that the private key will be exposed or stolen. Once that happens, all past messages encrypted with the key will be revealed. There are good reasons to change RSA moduli regularly for this reason (of course, most people don't do it anyway, because of our poor key management tools). But with DH primes, that is not a concern, as there is no long-term secret to be lost. All you have to worry about is a discrete log breakthrough, and that's not something to lose any sleep over.
Diffie-Hellman question
I have a standard implementation of OpenSSL, with Diffie-Hellman prime in the SSL certificate. The DH cipher suite is enabled. Is it safe to keep one prime there forever, or should I rather periodically regenerate it? Why? If yes, what's some sane period to do so: day, week, month? If the adversary has a log of a passively intercepted DHE-RSA-AES256-SHA secured SSL communication, presuming the ephemeral key was correctly generated and disposed of after the transaction, will the eventual physical retrieval of the DH prime (and the rest of the certificate) allow him to decode the captured log? I am rather inexperienced in this area, don't want to make a mistake, and generation of 2048-bit primes is CPU-hungry enough to not decide to just throw it in without a good reason.
