Re: [Cfrg] considering new topics for CFRG

William Whyte <wwhyte@securityinnovation.com> Mon, 06 January 2014 22:45 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 A59C31AE2A8 for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 14:45:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.521
X-Spam-Level:
X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 Ksw7PT1NOSpG for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 14:45:17 -0800 (PST)
Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED7C1AE29A for <cfrg@irtf.org>; Mon, 6 Jan 2014 14:45:17 -0800 (PST)
Received: by mail-qe0-f53.google.com with SMTP id nc12so19420390qeb.12 for <cfrg@irtf.org>; Mon, 06 Jan 2014 14:45: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=HAr/gatIkuKu4umwLz11n1Rp9+lIzEsb4jJmF2d2XOQ=; b=CWYur7H3rsiYM2AqmkC51tf4aeni5S/hVU7xnprtEIsHr3j9TNtbafYujqghrFeNUW XLSmCQjyWewSEdN45SplsMVd7g34ITDvw/0CTH8F0zlm5xYOwgsiO77jZ1UePz9Mnz3B H7FWJ0Kwh8goE2lTMYV+qcVqYF+1p11fsBJro=
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=HAr/gatIkuKu4umwLz11n1Rp9+lIzEsb4jJmF2d2XOQ=; b=YgaCdT4A9of2FTr/7haKRyp6TP2uCPJ/6lX5LiefT+VyhaXIftzQkhzrFntb8znKha V3C/o8keVjjyzmFNvZ/c1MolOdEQzNTXS4K//Oki784L+oS0afN7GOiMsvPhCUSM1ivE FjO/UdM+7LbVFJvt8oIlPxUY4SGyin6Slfj9sXaXCwFJl44ISzk8KEWdosNspZ8/pCcI vAvbNbnPk7kIc+nCjDpzmfZmnHkA+sRSg3QF9KvYt+qqxEAUKgBqhJ9l749lg9DY98yX gl1iPqduz/A2nm30WWoE7ESyG1iJQimGH6dT0YOe8BxuX7BigDs1/NzsJTKMKExxNN7x IwYQ==
X-Gm-Message-State: ALoCoQmBcM9jQTPVHE1YhjbzuvxmwmCMKLWyLZYwWxIEs0Op9Yc1/wYdzv0ZYNszByGGwP9YSbZC
MIME-Version: 1.0
X-Received: by 10.49.38.37 with SMTP id d5mr189911597qek.17.1389048308516; Mon, 06 Jan 2014 14:45:08 -0800 (PST)
Received: by 10.96.162.99 with HTTP; Mon, 6 Jan 2014 14:45:08 -0800 (PST)
In-Reply-To: <52C9F879.9030706@cisco.com>
References: <52C755AA.70200@cisco.com> <52C9F879.9030706@cisco.com>
Date: Mon, 06 Jan 2014 17:45:08 -0500
Message-ID: <CACz1E9oYvpBqgwo80nGs-TsQr7q1+rbDiJoh76y8egKQMfbSWg@mail.gmail.com>
From: William Whyte <wwhyte@securityinnovation.com>
To: David McGrew <mcgrew@cisco.com>
Content-Type: multipart/alternative; boundary="047d7bb043b0015c4b04ef550336"
Cc: Sean Turner <turners@ieca.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: Mon, 06 Jan 2014 22:45:19 -0000

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