[Cryptography] RSA equivalent key length/strength

[Peter Fairbrother]

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 
theoretically perfect?

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 
they aren't.



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