Re: [Cfrg] 1024 bit RSA

Hanno Böck <hanno@hboeck.de> Sat, 05 November 2016 13:18 UTC

Return-Path: <hanno@hboeck.de>
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 C1B7E1294F8 for <cfrg@ietfa.amsl.com>; Sat, 5 Nov 2016 06:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 YeH3Pewd88p6 for <cfrg@ietfa.amsl.com>; Sat, 5 Nov 2016 06:17:58 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C37129961 for <cfrg@irtf.org>; Sat, 5 Nov 2016 06:17:57 -0700 (PDT)
Received: from pc1 ([2001:2012:127:3e00:6167:f9c1:e510:ec40]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sat, 05 Nov 2016 14:17:55 +0100 id 0000000000000054.00000000581DDC04.00004CBC
Date: Sat, 5 Nov 2016 14:17:54 +0100
From: Hanno =?UTF-8?B?QsO2Y2s=?= <hanno@hboeck.de>
To: cfrg@irtf.org
Message-ID: <20161105141754.3d34c2ac@pc1>
In-Reply-To: <005a01d236b0$4b247470$e16d5d50$@x500.eu>
References: <005a01d236b0$4b247470$e16d5d50$@x500.eu>
X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/DdmZ1ZlLGxKS7rUa-JuFemvn61Q>
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:18:02 -0000

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