### Re: [Cfrg] considering new topics for CFRG

William Whyte <wwhyte@securityinnovation.com> Tue, 07 January 2014 22:04 UTC

Return-Path: <wwhyte@securityinnovation.com>

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 059BE1AE20D for <cfrg@ietfa.amsl.com>;
Tue, 7 Jan 2014 14:04:21 -0800 (PST)

X-Virus-Scanned: amavisd-new at amsl.com

X-Spam-Flag: NO

X-Spam-Score: 0.023

X-Spam-Level:

X-Spam-Status: No,
score=0.023 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001,
LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=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 PoTie26TdLB7 for
<cfrg@ietfa.amsl.com>; Tue, 7 Jan 2014 14:04:18 -0800 (PST)

Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com
[IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id
EF5131AE20C for <cfrg@irtf.org>; Tue, 7 Jan 2014 14:04:17 -0800 (PST)

Received: by mail-qc0-f178.google.com with SMTP id i17so737292qcy.37 for
<cfrg@irtf.org>; Tue, 07 Jan 2014 14:04:08 -0800 (PST)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com;
s=google;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type; bh=MxWAkh0XillAMMLu2+cHNqAY7gNTLS4tquQ3gMBhwPM=;
b=WsIgAnJLvS0e0vRR4oE+Eh9Kasw1AVanwq8XP4a0ds4SkFB4jdcSnzE6PiKUG91jwg
dHT2qXBMbMR0/EiZ+mtmvn9XnkGEwfKb8+VHA07JtXU2kkUooLa4Z3CoH2JkP1QYHAyK
DPoNg94rN6rVW0+7X0QL1IyZFgs6DIFbEGI2A=

X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;
s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=MxWAkh0XillAMMLu2+cHNqAY7gNTLS4tquQ3gMBhwPM=;
b=MdltqSd7XitRbAYvqooGljgjCnoNIlfkeOMOar/ZmEt47ez9DMdk6/kUyBgFObdQjI
IgxbHZpd6NPxl6XT2JSWGMvwAbux3grGcRqD/77bnYmwUsgotoJfvs4ZYa/LN7c9reo7
wixxUMhTylPHISoWISGpOO650P3BgpNp+HZjvyJHI+jT7sA9HE3IUTzuPsUbYsE98Ep3
vLBE7rfz5xfh665U6dkLbpzyogAqiY6rcYT0IgTpWoFFed2OboLIfafW0P03HAmpvl08
yELoYljJOpVvyff4RAUEOb9dhWuzCHtXxzd108Wr3mC1Gcl3/BUQXL+gECFSOUswecFt ++iQ==

X-Gm-Message-State: ALoCoQmTlF+fyGygaqOqKRkIPgjoB+K5ShkfeLKYgw+zZRQ4guYZ8yiNp1MFf7zeVbDxuyfcSlMB

MIME-Version: 1.0

X-Received: by 10.49.38.37 with SMTP id d5mr201663407qek.17.1389132248834;
Tue, 07 Jan 2014 14:04:08 -0800 (PST)

Received: by 10.96.162.99 with HTTP; Tue, 7 Jan 2014 14:04:08 -0800 (PST)

In-Reply-To: <20140107025045.6111382.97106.8115@certicom.com>

References: <20140107025045.6111382.97106.8115@certicom.com>

Date: Tue, 7 Jan 2014 17:04:08 -0500

Message-ID: <CACz1E9rr96_ze2nppiDiP=LLXwAwQK3_MyxqH+hGFuKbGuNY0g@mail.gmail.com>

From: William Whyte <wwhyte@securityinnovation.com>

To: Dan Brown <dbrown@certicom.com>

Content-Type: multipart/alternative; boundary=047d7bb043b03d1ba204ef688e1d

Cc: Sean Turner <turners@ieca.com>, David McGrew <mcgrew@cisco.com>,
"cfrg@irtf.org" <cfrg@irtf.org>

Subject: Re: [Cfrg] considering new topics for 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, 07 Jan 2014 22:04:21 -0000

Hi all, (sorry for top-posting, hard to avoid with gmail web interface) Dan Bernstein posted the following on the cryptography@randombits list (edited): >>Of course, the idea of using multiple cryptographic algorithms ... has very little use, for several obvious reasons: * We have enough problems even getting _one_ algorithm deployed. * For applications with larger cost limits, we obtain much more security by pumping up the key size, rounds, etc. of a single algorithm rather than by combining algorithms. << I'm not sure if this was in response to Dan Brown's suggestion of combining symmetric key algorithms or mine of combining public key algorithms. On combining symmetric key algorithms, I think I agree that there's unlikely to be significant value. Symmetric algorithms are less likely to fail catastrophically, and more importantly, your choice of symmetric algorithm isn't locked in beforehand through your choice of certificate. (The fact that AES has an algebraic structure gives me some cause for concern that a catastrophic attack might be possible, but it's a very remote concern). In case the comment was meant to be about combining public key systems, I don't agree. "We have problems getting one algorithm deployed": This is an argument for architecting the system now to support flexbility. The worst time to start deploying post-quantum crypto is when you need it; we should be thinking now about making that transition as easy as possible, and a framework that supports multiple algorithms is a framework that makes that transition easy. "For applications with larger cost limits, we obtain much more security by pumping up the key size, rounds, etc. ": This is true for symmetric crypto, with a tip of the hat to AES's structure, but for public key crypto we gain much more security against unforeseen advances in mathematics by combining algorithms. BTW, Dan Bernstein is having trouble posting to CFRG. I asked his permission before posting this extract and hope it represents his views fairly. The rest of his cryptography@randombits mail noted that Certicom has patents such as US7797539 on combining algorithms. I hadn't realised these patents on such an obvious technique existed and hope that their existence doesn't prove a barrier to moving ahead with this work. Cheers, William On Mon, Jan 6, 2014 at 9:50 PM, Dan Brown <dbrown@certicom.com> wrote: > Hi William, > > I agree with your multiple PK algs suggestion, for parties who can afford > it. > > What about sym key algs? Maybe too costly for now? > > By the way, this kind of idea goes back at least as far as 1999 from > Johnson and Vanstone under the name of resilient cryptographic schemes. > > Best regards, > > Dan > > From: William Whyte > Sent: Monday, January 6, 2014 5:45 PM > To: David McGrew > Cc: Sean Turner; cfrg@irtf.org > Subject: Re: [Cfrg] considering new topics for CFRG > > > > Hi all, > > > > - Postquantum cryptography. Signing algorithms based on hash functions > > > (based on the work of Merkle and Hulsing) will not be too hard. > > > Encryption based on codes would need more review, but should be > possible; Bernstein and > > > others have done good work in this area > > > recently. Other encryption and signature schemes could be considered > > > as well. Also useful would be parameter and algorithm guidance for > postquantum security. > > > (full disclosure: my company, Security Innovation, holds the patents for > the NTRU cryptosystems, which are among the leading candidates for use as > post quantum algorithms. We've recently made the patents available to use > under GPL or a range of other FOSS licenses -- see > https://github.com/NTRUOpenSourceProject/ntru-crypto/blob/master/LICENSE.md, > > https://github.com/NTRUOpenSourceProject/ntru-crypto/blob/master/FOSS%20Exception.md > ). > > > I agree that postquantum crypto is important and CFRG has a valuable role > to play in recommending algorithms for use. > > > However, I'd also like to see the internet community move away from using > a single public key algorithm per message or session. Any data that's > encrypted with a single public key algorithm is vulnerable to a single > cryptographic breakthrough, whether that's a classical or quantum > algorithm. An adversary who stores a large amount of historical traffic may > well be able to decrypt it in the future. This is particularly the case > with ECC and RSA-based ciphersuites because of the known threat from > quantum computing, but any algorithm is potentially vulnerable. > > > I'd like to see some thought given to how different public key algorithms > can be used in parallel so that a session has the strength of at least the > strongest of them. For TLS this is in principle pretty easy -- split the > master secret into two or more XORed strings, encrypt each with a different > public key algorithm, XOR the decrypted results together (or use a key > exchange algorithm to derive one or more of the XOR strings) -- but the > details may be tricky and CFRG can help here. > > > Combined public key algorithms would help give improved protection to > users against attacks yet to be discovered. It might also help with > migration -- service providers might be unwilling to migrate directly to a > newer algorithm like for example NTRU from a more widely understood one > like for example ECDH, but using both in parallel gives the assurance > associated with ECDH plus the (assumed) quantum resistance of NTRU. > > > In general, solutions based on a single public key algorithm run the risk > of baking in a single point of failure. Migration from one solution to > another will be hard; migrating from one single point of failure to another > runs the risk that we'll have to migrate again, which would be extremely > hard. Much better for the internet community to think about how to put in > place a system that we can change parameters in (such as choice of > algorithm) without having to change the underlying framework. This would > fit in with the catalog of clear and strong recommendations that Paul > Lambert mentioned in another mail: the catalog could contain different > algorithms with different properties, allowing implementers to select a > combination that gave the properties they want. > > > When potential new work areas are raised on CFRG, it's fair to ask who's > going to actually do the work, so let me state for the record that Security > Innovation is willing to commit resources to help get this work done within > the CFRG in 2014 and onwards. We obviously have an interest in that we > think it'll make adoption of NTRU easier, but it also seems like the right > thing to do. > > > Cheers, > > > William > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > >

- [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Henrick Hellström
- Re: [Cfrg] considering new topics for CFRG David Wagner
- Re: [Cfrg] considering new topics for CFRG Henrick Hellström
- Re: [Cfrg] considering new topics for CFRG Trevor Perrin
- Re: [Cfrg] considering new topics for CFRG Henrick Hellström
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG Stephen Farrell
- Re: [Cfrg] considering new topics for CFRG William Whyte
- Re: [Cfrg] considering new topics for CFRG Stephen Farrell
- Re: [Cfrg] considering new topics for CFRG Watson Ladd
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG Dan Brown
- Re: [Cfrg] considering new topics for CFRG Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG William Whyte
- Re: [Cfrg] considering new topics for CFRG Max Pritikin (pritikin)
- Re: [Cfrg] considering new topics for CFRG Watson Ladd
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Adam Back
- [Cfrg] QKD is pointless (was: Re: considering new… David McGrew
- Re: [Cfrg] considering new topics for CFRG Stephen Farrell
- Re: [Cfrg] QKD is pointless (was: Re: considering… Paterson, Kenny
- Re: [Cfrg] QKD is pointless (was: Re: considering… Sean Turner
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Max Pritikin (pritikin)
- Re: [Cfrg] considering new topics for CFRG Dan Brown
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] QKD is pointless (was: Re: considering… Igoe, Kevin M.
- Re: [Cfrg] QKD is pointless (was: Re: considering… Igoe, Kevin M.
- Re: [Cfrg] QKD is pointless (was: Re: considering… Watson Ladd
- [Cfrg] DANE in the IETF (was: Re: considering new… Paul Hoffman
- [Cfrg] One Key -> RE: considering new topics for … Paul Lambert
- Re: [Cfrg] QKD is pointless (was: Re: considering… Paul Lambert
- [Cfrg] ReL DANE in the IETF (was: Re: considering… Paul Hoffman
- Re: [Cfrg] QKD is pointless David McGrew
- Re: [Cfrg] QKD is pointless Hilarie Orman
- Re: [Cfrg] considering new topics for CFRG dan
- [Cfrg] likelihood that someone has a quantum comp… David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … David Jacobson
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … Watson Ladd
- Re: [Cfrg] likelihood that someone has a quantum … Yoav Nir
- Re: [Cfrg] likelihood that someone has a quantum … Stephen Farrell
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … arne renkema-padmos
- Re: [Cfrg] likelihood that someone has a quantum … Igoe, Kevin M.
- Re: [Cfrg] QKD is pointless David Wagner
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … arne renkema-padmos
- Re: [Cfrg] considering new topics for CFRG Igoe, Kevin M.
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- [Cfrg] 'key centric' architecture (was: Re: consi… Rene Struik
- Re: [Cfrg] 'key centric' architecture (was: Re: c… Richard Barnes
- Re: [Cfrg] considering new topics for CFRG David McGrew