Re: [Cfrg] 1024 bit RSA

"Erik Andersen" <era@x500.eu> Sat, 05 November 2016 13:35 UTC

Return-Path: <era@x500.eu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3041296FB for <cfrg@ietfa.amsl.com>; Sat, 5 Nov 2016 06:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.697
X-Spam-Level:
X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.297] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoKl7PyPgNOE for <cfrg@ietfa.amsl.com>; Sat, 5 Nov 2016 06:35:12 -0700 (PDT)
Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222C31296CC for <cfrg@irtf.org>; Sat, 5 Nov 2016 06:35:11 -0700 (PDT)
Received: from Morten ([62.44.134.108]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201611051435089294 for <cfrg@irtf.org>; Sat, 05 Nov 2016 14:35:08 +0100
From: "Erik Andersen" <era@x500.eu>
To: "Cfrg" <cfrg@irtf.org>
References: <005a01d236b0$4b247470$e16d5d50$@x500.eu> <20161105141754.3d34c2ac@pc1>
In-Reply-To: <20161105141754.3d34c2ac@pc1>
Date: Sat, 5 Nov 2016 14:35:07 +0100
Message-ID: <001501d23769$6c8c1820$45a44860$@x500.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFtkR8gQp9sBKHWzUn7gA0cS5CaQQJ73OIKoX/QCFA=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/-ZyLG8cT3xZgJX6F2p7U0eCMlZ0>
Subject: Re: [Cfrg] 1024 bit RSA
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Nov 2016 13:35:14 -0000

My best guess is that some vendor with a major voice in the standard organizations have products that due to a bad design cannot be easily upgraded to a stronger algorithm.

This proves to me that it wrong to leave the IT standardization to vendors.

Erik

-----Oprindelig meddelelse-----
Fra: Cfrg [mailto:cfrg-bounces@irtf.org] På vegne af Hanno Böck
Sendt: 05 November 2016 14:18
Til: cfrg@irtf.org
Emne: Re: [Cfrg] 1024 bit RSA

On Fri, 4 Nov 2016 16:29:54 +0100
"Erik Andersen" <era@x500.eu> wrote:

> I participate in IT smart grid standardization within IEC TC57 WG15. A 
> couple of standards under development still allow 1024 bit RSA keys 
> for so-called backward compatibility. I have so far not been able to 
> change that. My question is now. Is there any information available 
> for how long time or how much effort it takes to break  a 1024 bit RSA 
> key?

Dan Bernstein has made some estimates about the costs of breaking 1024 bit a while ago in a talk:
https://www.youtube.com/watch?v=IuSnY_O8DqQ
He thinks that large botnets may be capable of doing it.

Also to be considered for the attack scenario is that one can break multiple keys at once (batch-nfs by bernstein/lange), which changes the economics of an attack quite a bit:
https://eprint.iacr.org/2014/921


One can probably conclude that attacking 1024 bit rsa is still a very expensive attack. However one should also ask the other question: What is the cost of using a stronger algorithm? I usually tend to have the opinion that we know how to get the basic algorithms right in a way that it's completely infeasible to break them. So let's just use secure algorithms and then use our energy bother about all the other things that can go wrong (next thing up the stack would be "don't use PKCS #1 1.5" and "don't use e=3").

So rather than asking "is rsa 1024 bit secure enough?" I'd ask "is there any significant cost in using rsa 2048?". The performance impact for most applications is almost irrelevant these days.
You cite "backwards compatibility" as a reason, but that's not very specific. Is there a large deployment of devices that only support
1024 bit rsa? If yes then why is that? Are they really old (pre 2003)?
The major warnings against rsa 1024 came in 2003, so if the devices are newer than 2003 and only support rsa 1024 then they have been shipped with substandard crypto (which is quite common, but still bad).
If that's the case then I'd conclude that there is an underlying problem and the call for rsa 1024 is just a symptom of that (and I'd also assume that these devices are probably using other crypto constructions that are scarier than rsa 1024).

--
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg