From: Dan Brown <dbrown@certicom.com>
To: William Whyte <wwhyte@securityinnovation.com>,
 David McGrew <mcgrew@cisco.com>
Thread-Topic: [Cfrg] considering new topics for CFRG
Thread-Index: Ac8LU0N3+Ps+p+/cFU6uojPzahL32Q==
Date: Tue, 7 Jan 2014 02:50:46 +0000
Message-ID: <20140107025045.6111382.97106.8115@certicom.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C6C812E45AB8494BB6580F1595952F15@rim.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Cc: Sean Turner <turners@ieca.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] considering new topics for CFRG
Precedence: list

Hi William,

I agree with your multiple PK algs suggestion, for parties who can afford i=
t.

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 Johnso=
n 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 postq=
uantum security.


(full disclosure: my company, Security Innovation, holds the patents for th=
e NTRU cryptosystems, which are among the leading candidates for use as pos=
t quantum algorithms. We've recently made the patents available to use unde=
r GPL or a range of other FOSS licenses -- see https://github.com/NTRUOpenS=
ourceProject/ntru-crypto/blob/master/LICENSE.md, https://github.com/NTRUOpe=
nSourceProject/ntru-crypto/blob/master/FOSS%20Exception.md).


I agree that postquantum crypto is important and CFRG has a valuable role t=
o 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 encryp=
ted with a single public key algorithm is vulnerable to a single cryptograp=
hic breakthrough, whether that's a classical or quantum algorithm. An adver=
sary who stores a large amount of historical traffic may well be able to de=
crypt it in the future. This is particularly the case with ECC and RSA-base=
d 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 c=
an be used in parallel so that a session has the strength of at least the s=
trongest of them. For TLS this is in principle pretty easy -- split the mas=
ter secret into two or more XORed strings, encrypt each with a different pu=
blic key algorithm, XOR the decrypted results together (or use a key exchan=
ge algorithm to derive one or more of the XOR strings) -- but the details m=
ay 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 algori=
thm like for example NTRU from a more widely understood one like for exampl=
e 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 o=
f baking in a single point of failure. Migration from one solution to anoth=
er 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) with=
out having to change the underlying framework. This would fit in with the c=
atalog of clear and strong recommendations that Paul Lambert mentioned in a=
nother mail: the catalog could contain different algorithms with different =
properties, allowing implementers to select a combination that gave the pro=
perties they want.


When potential new work areas are raised on CFRG, it's fair to ask who's go=
ing to actually do the work, so let me state for the record that Security I=
nnovation 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 thin=
k it'll make adoption of NTRU easier, but it also seems like the right thin=
g to do.


Cheers,


William


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.