[Cfrg] Response to TLS WG on SALSA

"Igoe, Kevin M." <kmigoe@nsa.gov> Mon, 07 October 2013 13:23 UTC

Return-Path: <kmigoe@nsa.gov>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8970421E80A7 for <cfrg@ietfa.amsl.com>; Mon, 7 Oct 2013 06:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTt2Sn5mF9D9 for <cfrg@ietfa.amsl.com>; Mon, 7 Oct 2013 06:23:23 -0700 (PDT)
Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 62FC321E80A6 for <cfrg@irtf.org>; Mon, 7 Oct 2013 06:23:21 -0700 (PDT)
X-TM-IMSS-Message-ID: <50b4836900054be8@nsa.gov>
Received: from MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 50b4836900054be8 ; Mon, 7 Oct 2013 09:31:21 -0400
Received: from MSMR-GH1-UEA05.corp.nsa.gov (10.215.228.28) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 7 Oct 2013 09:23:19 -0400
Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA05.corp.nsa.gov ([10.215.228.28]) with mapi id 14.02.0342.003; Mon, 7 Oct 2013 09:23:19 -0400
From: "Igoe, Kevin M." <kmigoe@nsa.gov>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: Response to TLS WG on SALSA
Thread-Index: Ac7DYGJmsEq+QbVQSsKP61HliRDsmA==
Date: Mon, 07 Oct 2013 13:23:18 +0000
Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CAB24E0267@MSMR-GH1-UEA03.corp.nsa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.215.225.46]
Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CAB24E0267MSMRGH1UEA03cor_"
MIME-Version: 1.0
Subject: [Cfrg] Response to TLS WG on SALSA
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
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, 07 Oct 2013 13:23:28 -0000

With IETF-88 looming in the near future, we owe the TS-WG a resonse
on the suitability of various stream ciphers snd MACsin TLS.
Three stream ciphers have been discussed:
1)      The original SALSA-20
2)      ChaCha, a variant of SALSA-20, modifying the prolog and epilog to
increase the efficiency.
3)      eStream SALSA-20 (hereafter eSALSA), reduces rounds from
20 rounds in SALSA-20 down to 12 rounds.

Here is my reading on the opinion of the mailing list:
1)      There seems to be substantial controversy over the efficiency of the various
      stream cipher candidates, especially when compared to AES counter modes.
      This needs to be straightened out before an informed decision can be made.
On the maturity of the cryptanalysis of the three stream ciphers:
1)      The analysis of SALSA-20 has been very thorough and the degree of confidence
      in SALSA-20 is very high.
2)      Though ChaCha has received slightly less analysis, the RG is confident that the
      analysis was sufficiently thorough that ChaCha is an acceptable alternative to
      SALSA-20.
3)      The RG was less comfortable with the maturity of the analysis of eSALSA, but
no substantive objections were raised.
Cryptanalytically all are almost certainly sufficient for use in TLS.  The RG expressed
a preference for ChaCha.

We were also asked our opinion on the MACs being considered, UMAC and POLY1305.
No cryptanalytic issues were raised, thought VMAC was suggested as a more efficient
alternative to the efficiency of UMAC.  The suitability of these MACs for efficient hardware
implementation was questioned.

Is this a reasonably accurate synopsis?



----------------+--------------------------------------------------
Kevin M. Igoe   | "We can't solve problems by using the same kind
kmigoe@nsa.gov  | of thinking we used when we created them."
                |              - Albert Einstein -
----------------+--------------------------------------------------