Re: [Cfrg] considering new topics for CFRG

Dan Brown <dbrown@certicom.com> Tue, 07 January 2014 02:51 UTC

Return-Path: <dbrown@certicom.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 2F19E1AE3D3 for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 18:51:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 vESFeo5ks4sI for <cfrg@ietfa.amsl.com>; Mon, 6 Jan 2014 18:51:05 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id D30291AE3D2 for <cfrg@irtf.org>; Mon, 6 Jan 2014 18:51:04 -0800 (PST)
Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 06 Jan 2014 21:50:47 -0500
Received: from XCT115CNC.rim.net (10.65.161.215) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 21:50:47 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 21:50:47 -0500
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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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
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 02:51:07 -0000

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.