[147294] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] RSA equivalent key length/strength

daemon@ATHENA.MIT.EDU (Peter Gutmann)
Wed Sep 25 18:25:02 2013

X-Original-To: cryptography@metzdowd.com
Date: Wed, 25 Sep 2013 23:59:50 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: pgut001@cs.auckland.ac.nz, zenadsl6186@zen.co.uk
In-Reply-To: <5241B278.2080103@zen.co.uk>
Cc: cryptography@metzdowd.com, code@funwithsoftware.org, adam@cypherspace.org,
	paul.hoffman@vpnc.org, perry@piermont.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

Peter Fairbrother <zenadsl6186@zen.co.uk> writes:
>On 24/09/13 05:27, Peter Gutmann wrote:
>> Peter Fairbrother <zenadsl6186@zen.co.uk> writes:
>>> 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.
>>
>> ... and I guess that puts you firmly in the theoretical/impractical camp.
>> Would you care to explain how this is going to work within the TLS protocol?
>
>I'm not sure I understand you.

Something that can "sign a new RSA-2048 sub-certificate" is called a CA.  For 
a browser, it'll have to be a trusted CA.  What I was asking you to explain is 
how the browsers are going to deal with over half a billion (source: Netcraft 
web server survey) new CAs in the ecosystem when "websites sign a new RSA-2048 
sub-certificate".

Peter.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

home help back first fref pref prev next nref lref last post