Re: [Cfrg] Task for the CFRG

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Thu, 08 August 2013 20:51 UTC

Return-Path: <prvs=1932d60b24=uri@ll.mit.edu>
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 B1E0421F8A53 for <cfrg@ietfa.amsl.com>; Thu, 8 Aug 2013 13:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 l9E0fC5llDH7 for <cfrg@ietfa.amsl.com>; Thu, 8 Aug 2013 13:51:52 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id B39E621F9C20 for <cfrg@irtf.org>; Thu, 8 Aug 2013 13:51:41 -0700 (PDT)
Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r78KpeYY026668; Thu, 8 Aug 2013 16:51:40 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: Ted Krovetz <ted@krovetz.net>, "cfrg@irtf.org" <cfrg@irtf.org>
Date: Thu, 8 Aug 2013 16:51:37 -0400
Thread-Topic: [Cfrg] Task for the CFRG
Thread-Index: Ac6UeRTAWd5LkSXyQMGwWOBxGCriaA==
Message-ID: <CE297CE7.FF11%uri@ll.mit.edu>
In-Reply-To: <BDE10FD9-A9EB-406D-A02E-29AD0888820C@krovetz.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.6.130613
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3458825497_16844727"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-08_06:2013-08-08, 2013-08-08, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308080190
Subject: Re: [Cfrg] Task for the CFRG
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: Thu, 08 Aug 2013 20:51:57 -0000

I concur, and second the recommendation to use Chacha instead of Salsa.

TNX!
-- 
Regards, 
Uri Blumenthal                           Voice: (781) 981-1638




On 8/8/13 16:24 , "Ted Krovetz" <ted@krovetz.net>; wrote:

>
>> The TLS WG has asked the CFRG for their opinion for a stream cipher,
>>eSTREAM-SALSA20,
>> and two MAC algorithms, UMAC and POLY1305, that have been suggested for
>>use in TLS
>
>I am well familiar with all three. I edited the UMAC RFC, have been
>working with a Salsa variant called Chacha, and have used several
>polynomial hashes similar to Poly1305.
>
>I have no security concerns for any of the three. I do have a few
>comments.
>
>UMAC: Uses a large internal key (about 1KB), and complex code. UMAC has
>very high speed if key can be kept in cache. I suggested to the TLS
>mailing list VMAC as an alternative that uses less internal key and is of
>similar speed.
>
>Salsa20/12: The estream variant under consideration is the 12-round one.
>All the fastest Salsa implementations are SIMD, and Salsa's prolog and
>epilog are complicated under SIMD. Dan Bernstein recognized this and made
>a SIMD-friendly variant called Chacha. Chacha also made a couple rotation
>tweaks that improve speed and (Dan speculates) improves security. I wish
>everyone would forget about Salsa and replace it with Chacha.
>
>Poly1305: This is a standard polynomial evaluation hash with good
>security. As with UMAC and VMAC, it depends heavily on multiplication (in
>this case 128x128->256 bits followed by divisionless mod), making it
>expensive in hardware (same for UMAC and VMAC).
>
>If all the TLS group wants is our security assessment of Salsa, UMAC and
>Poly1305, we should give them a positive one. If we wish to give some
>advice as well, I'd recommend consideration of VMAC over UMAC and,
>especially, Chacha over Salsa.
>
>-Ted
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.org/mailman/listinfo/cfrg