Re: [Cfrg] Task looming over the CFRG
"Igoe, Kevin M." <kmigoe@nsa.gov> Tue, 06 May 2014 12:32 UTC
Return-Path: <kmigoe@nsa.gov>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FFA1A02E3 for <cfrg@ietfa.amsl.com>; Tue, 6 May 2014 05:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.55
X-Spam-Level:
X-Spam-Status: No, score=-7.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 0x4kb-5ESY3y for <cfrg@ietfa.amsl.com>; Tue, 6 May 2014 05:32:45 -0700 (PDT)
Received: from emvm-gh1-uea08.nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 14ACD1A02E2 for <cfrg@irtf.org>; Tue, 6 May 2014 05:32:44 -0700 (PDT)
X-TM-IMSS-Message-ID: <4d991ea2000e41a7@nsa.gov>
Received: from MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 4d991ea2000e41a7 ; Tue, 6 May 2014 08:31:58 -0400
Received: from MSMR-GH1-UEA08.corp.nsa.gov (10.215.225.3) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 6 May 2014 08:32:38 -0400
Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA08.corp.nsa.gov ([10.215.225.3]) with mapi id 14.01.0289.001; Tue, 6 May 2014 08:32:38 -0400
From: "Igoe, Kevin M." <kmigoe@nsa.gov>
To: 'Michael Hamburg' <mike@shiftleft.org>
Thread-Topic: [Cfrg] Task looming over the CFRG
Thread-Index: Ac9oi6oYPJfN8CicTuuHQj1qX4dIoAAJTMCAAAWvywD///yVgP//P8EQ
Date: Tue, 06 May 2014 12:32:37 +0000
Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CABAA40611@MSMR-GH1-UEA03.corp.nsa.gov>
References: <3C4AAD4B5304AB44A6BA85173B4675CABAA4022F@MSMR-GH1-UEA03.corp.nsa.gov> <E98B42D5-610C-4532-B765-5819A35A456C@shiftleft.org> <3C4AAD4B5304AB44A6BA85173B4675CABAA404E9@MSMR-GH1-UEA03.corp.nsa.gov> <B8586319-F1E6-4CA6-B70E-4D6153DC19A5@shiftleft.org>
In-Reply-To: <B8586319-F1E6-4CA6-B70E-4D6153DC19A5@shiftleft.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.215.227.232]
Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CABAA40611MSMRGH1UEA03cor_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/lyP6VTm2h1asZSCNn7ogNywD5TU
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Task looming over the CFRG
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 12:32:49 -0000
In fact we had wanted to use AES -128 and AES-192, but a quick survey of AES implementations (hardware centric, I believe) showed that there were very few implemented AES-192, whence the decision to go with AES-128 and AES-256 in Suite B, paired with P256 and P384. All of the crypt purists grumbled endlessly about the mismatch betwixt AES-256 and P384. From: Michael Hamburg [mailto:mike@shiftleft.org] Sent: Monday, May 05, 2014 4:56 PM To: Igoe, Kevin M. Cc: cfrg@irtf.org Subject: Re: [Cfrg] Task looming over the CFRG Kevin, Sorry to be ambiguous: the curve I designed has a 448-bit field and a 446-bit prime-order subgroup, so a parallel rho attack should cost just under 2^223 point operations on average. So it sits between the 192 and 256-bit security levels. I'm not particularly invested in getting this curve into TLS, but I'd like to know whether there's a point in submitting it for this purpose, or if it will be rejected for having the "wrong security level". Matching the nominal security level of the asymmetric part to that of the symmetric part sounds obvious on its face, but in fact it is not usually done above the 128-bit level. For example, Suite B doesn't specify a direct matching of nominal security levels: it specifies AES-256 with SHA-384 and ECDSA-NIST-p384 for TOP SECRET communications. Likewise, almost nobody pairs AES-256 with the matching RSA-15k, and even AES-128 is usually paired with the nominally weaker RSA-2048. This actually makes sense. Nobody is going to do a 128-bit exhaust for many decades. Not Google, not the NSA, not the KGB, nobody. With today's most efficient supercomputers, the heat output from 2^128 operations would be far more than enough to boil the oceans dry [1]. So we're talking about defenses against sub-128-bit attacks, and defense in depth against hypothetical advances in cryptography, and quantum resistance for primitives that can resist at all. Stronger curves, ciphers and hashes will stand or fall on their own, not all together as computer power surpasses their nominal security level. Also, nobody uses AES-192. So I don't think it's obvious that matching the AES security levels is a requirement. If the RG thinks it is, or if there's some obscure legal requirement that the levels match, then fine. Just describe why. Cheers, - Mike [1] Lenstra, Kleinjung, Thomé. "Universal security: from bits and mips to pools, lakes - and beyond". https://eprint.iacr.org/2013/635.pdf On May 5, 2014, at 12:49 PM, Igoe, Kevin M. <kmigoe@nsa.gov<mailto:kmigoe@nsa.gov>> wrote: Mike: Being off by a few bits isn't a show stopper. but 32-bits is probably too much. The security levels echo the AES security levels of AES-128, AES-192 and AES-256. Using a 224 bit curve with AES-128 only provides roughly 112-bits of security versus the 128 bits ostensibly provided by AES-128. I just want to ensure that a user who thinks they are getting 128 bits of security gets 128 bits of security. Kevin From: Michael Hamburg [mailto:mike@shiftleft.org] Sent: Monday, May 05, 2014 2:25 PM To: Igoe, Kevin M. Cc: cfrg@irtf.org<mailto:cfrg@irtf.org> Subject: Re: [Cfrg] Task looming over the CFRG Hi Kevin, As the designer of an ECC system which is aimed at 224-ish-bit security, I'm curious: is it a firm requirement that the curves be set at 128, 192 and 256 bits? Or was there consensus in the meeting that the curves should be set at these security levels? Patrick Longa aimed his talk at these security levels, but I don't recall this being stated as a requirement. Cheers, - Mike On May 5, 2014, at 10:58 AM, Igoe, Kevin M. <kmigoe@nsa.gov<mailto:kmigoe@nsa.gov>> wrote: As most the folks who read this list have noticed, a virtual interim meeting of the CFRG was held on Tues 29 April to discuss the way forward for elliptic curve cryptography in the IETF. This was driven by an earnest plea from the TLS WG for firm guidance from the CGRG on the selection of elliptic curves for use in TLS. They need an answer before the Toronto IETF meeting in late July. TLS needs curves for several levels of security (128, 192 and 256), suitable for use in both key agreement and in digital signatures. * The consensus of the attendees was that it would be best for TLS to have a single "mandatory to implement" curve for each of the three security levels. * Though the attendees were reluctant to make a formal commitment, there was clearly a great deal of support for the Montgomery curve curve25519 (FYI, the 25519 refers to the fact that arithmetic is done modulo the prime 2**255 - 19 ). * curve25519 only fills one of the three required security levels. We still need curves of size near 384 bits and 512 bits. * NIST curves: I doubt TLS will be willing to revisit the question of elliptic curves once the CFRG has made their recommendation. Another option to consider is advising TLS to use of the NIST curves in the short term, buying time for the CFRG to do an unrushed exploration of the alternatives, drawing academia and other standards bodies into the discussion. P.S. It has been suggested that the CFRG hold a session at the Crypto conference in Santa Barbara in an effort to draw in more participation from the academic community. No guarantees we can pull this off, but it is worth the attempt. Thoughts? Volunteers? P.P.S. We need to start lining up speakers for the CFRG session at IETF-90 (Toronto). ----------------+-------------------------------------------------- Kevin M. Igoe | "We can't solve problems by using the same kind kmigoe@nsa.gov<mailto:kmigoe@nsa.gov> | of thinking we used when we created them." | - Albert Einstein - ----------------+-------------------------------------------------- _______________________________________________ Cfrg mailing list Cfrg@irtf.org<mailto:Cfrg@irtf.org> http://www.irtf.org/mailman/listinfo/cfrg
- [Cfrg] Task looming over the CFRG Igoe, Kevin M.
- Re: [Cfrg] Task looming over the CFRG Michael Hamburg
- Re: [Cfrg] Task looming over the CFRG Rene Struik
- Re: [Cfrg] Task looming over the CFRG Paul Lambert
- Re: [Cfrg] Task looming over the CFRG Rene Struik
- Re: [Cfrg] Task looming over the CFRG David McGrew
- Re: [Cfrg] Task looming over the CFRG Igoe, Kevin M.
- Re: [Cfrg] Task looming over the CFRG Paul Lambert
- Re: [Cfrg] Task looming over the CFRG Michael Hamburg
- Re: [Cfrg] Task looming over the CFRG Blumenthal, Uri - 0668 - MITLL
- Re: [Cfrg] Task looming over the CFRG Michael Hamburg
- Re: [Cfrg] Task looming over the CFRG Watson Ladd
- Re: [Cfrg] Task looming over the CFRG Johannes Merkle
- Re: [Cfrg] Task looming over the CFRG Igoe, Kevin M.
- Re: [Cfrg] Task looming over the CFRG Johannes Merkle
- Re: [Cfrg] Task looming over the CFRG Paul Lambert
- Re: [Cfrg] Task looming over the CFRG Watson Ladd
- Re: [Cfrg] Task looming over the CFRG Blumenthal, Uri - 0558 - MITLL