Re: [Cfrg] 1024 bit RSA

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 05 November 2016 14:43 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 C6B851294EC for <cfrg@ietfa.amsl.com>; Sat, 5 Nov 2016 07:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.697
X-Spam-Level:
X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 EVPwV0R4sh1w for <cfrg@ietfa.amsl.com>; Sat, 5 Nov 2016 07:43:21 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFEF312945C for <cfrg@irtf.org>; Sat, 5 Nov 2016 07:43:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1478357000; x=1509893000; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=bJpowSC6CIMtwgqpdRhOkUqCZRbHEUL5lr+svWi0frA=; b=Uyjg3AevEnXA9Hzw4zsw6qtlTVVkxu7357oORJHAf3vPk8k75Uhhvs9y +QHE0neJ8wnoBGkxecdlcxemziYZMyF2fVMn6yXOHjA58KXNGa+6eTPXy Ee7Dz7HkPNKif5cCua6NOMA0NE47w5ic8k/AATAhQ6jzB4kedzIuLbn3+ Uyg6DPWH+GAOkJWwDiWoVy/XxMBDqjth7XqC9XtijhhFv/Jp8PnvzQ61O iEIGOAxQ+zprOgg3H00CjianE9HjC1sLZcA8t7GIX5JSMrW2lgEUQ74ED fdK8nqr2c9ggtlqHJJI/hslecvy/KH1h1en2/w9cbyeSoiySEV7nanfYB Q==;
X-IronPort-AV: E=Sophos;i="5.31,597,1473076800"; d="scan'208";a="113688639"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Nov 2016 03:43:15 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.25) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 6 Nov 2016 03:43:15 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sun, 6 Nov 2016 03:43:15 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: =?iso-8859-1?Q?Hanno_B=F6ck?= <hanno@hboeck.de>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] 1024 bit RSA
Thread-Index: AdI2ru4LNTqSoFCyQtexI2PQtTMFhAASx9AAAB4vto8=
Date: Sat, 5 Nov 2016 14:43:15 +0000
Message-ID: <1478356984469.74085@cs.auckland.ac.nz>
References: <005a01d236b0$4b247470$e16d5d50$@x500.eu>, <20161105141754.3d34c2ac@pc1>
In-Reply-To: <20161105141754.3d34c2ac@pc1>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/uW3LwfdPykbqrbAaP4B3tzdoMXY>
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 14:43:25 -0000

Hanno Böck <hanno@hboeck.de> writes:

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

Yup, and in combination with that, what's being protected/what's your threat
model?  The example I've used on a number of occasions is a 512-bit key being
used with a system that turns a ventilator on and off (details fudged slightly
to make the actual item non-recognisable to the company running it :-).  The
system is old (meaning it's a current product but the hardware was designed
in... not sure, late 90s I think, or maybe earlier), it can't handle keys
larger than 512-bit (heck, it struggles with 512-bit keys), and even using a
512-bit key is complete overkill, AFAICT the motivation for it is some sort of
checklist-compliance for the auditors, "yes we use crypto", rather than a need
to protect it from anything (the crypto was a later addition, some time
post-2000).

It's easy enough for people operating in splendid isolation from real life to
say "we should all be using [insert chosen numerology here]-sized keys for
everything all the time", but in practice it depends on a whole pile of
factors, of which "what theoretical strength in bits do we need" is several
steps down the list behind "how much will it cost", "what can the hardware
cope with", "what are we protecting", "what's the risk", and several others.

Peter.