[Cryptography] RSA equivalent key length/strength
zenadsl6186 at zen.co.uk
Mon Sep 23 13:35:12 EDT 2013
On 23/09/13 09:47, Peter Gutmann wrote:
> Patrick Pelletier <code at funwithsoftware.org> writes:
>> I'm inclined to agree with you, but you might be interested/horrified in the
>> "1024 bits is enough for anyone" debate currently unfolding on the TLS list:
> That's rather misrepresenting the situation. It's a debate between two
> groups, the security practitioners, "we'd like a PFS solution as soon as we
> can, and given currently-deployed infrastructure DH-1024 seems to be the best
> bet", and the theoreticians, "only a theoretically perfect solution is
> acceptable, even if it takes us forever to get it".
> (You can guess from that which side I'm on).
Lessee - a "forward secrecy solution" which either doesn't work now or
won't work soon - so that it probably won't protect traffic made now for
it's useful lifetime - versus - well, who said anything about
To hell with perfect. I won't even use the word when describing forward
secrecy (unless it's an OTP).
If you just want a down-and-dirty 2048-bit FS solution which will work
today, why not just have the websites sign a new RSA-2048
sub-certificate every day? Or every few hours? And delete the secret
key, of course.
Forward secrecy doesn't have to be per-session.
Though frankly, I don't think ubiquitous 1024-bit FS without deployment
of some software/RFC/standard is possible, and if so that deployment
should also include a 2048-bit solution as well. And maybe 3072-bit and
4096-bit solutions too.
And please please please don't call them all the same thing - because
But, the immediate question before the court of TLS now is - "do we
recommend a 1024-bit FS solution?"
And I for one cannot say that you should. In fact I would be horrified
if you did.
-- Peter Fairbrother
More information about the cryptography