[145943] in cryptography@c2.net mail archive
Re: 2048 bits, damn the electrons! [rt@openssl.org: [openssl.org
daemon@ATHENA.MIT.EDU (Samuel Neves)
Thu Sep 30 20:55:50 2010
Date: Fri, 01 Oct 2010 01:52:49 +0100
From: Samuel Neves <sneves@dei.uc.pt>
To: cryptography@metzdowd.com
In-Reply-To: <20100930154118.GA23692@panix.com>
X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt
On 30-09-2010 16:41, Thor Lancelot Simon wrote:
> On Wed, Sep 29, 2010 at 09:22:38PM -0700, Chris Palmer wrote:
>> Thor Lancelot Simon writes:
>>
>>> a significant net loss of security, since the huge increase in
>>> computation required will delay or prevent the deployment of
>>> "SSL everywhere".
>>
>> That would only happen if we (as security experts) allowed web
>> developers to believe that the speed of RSA is the limiting factor
>> for web application performance.
>
> At 1024 bits, it is not. But you are looking at a factor of *9*
> increase in computational cost when you go immediately to 2048 bits.
> At that point, the bottleneck for many applications shifts,
> particularly those which are served by offload engines specifically
> to move the bottleneck so it's not RSA in the first place.
...
> At present, these devices use the highest performance modular-math
> ASICs available and can just about keep up with current web
> applications' transaction rates. Make the modular math an order of
> magnitude slower and suddenly you will find you can't put these
> devices in front of some applications at all.
One solution would be to use 2048-bit 4-prime RSA. It would maintain the
security of RSA-2048, enable the reusing of the modular arithmetic units
of 1024 bit VLSI chips and keep ECM factoring at bay. The added cost
would only be a factor of ~2, instead of ~8.
Best regards,
Samuel Neves
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
