From kmigoe@nsa.gov Thu Aug 8 12:45:48 2013 Return-Path: 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 0AB1011E821C for ; Thu, 8 Aug 2013 12:45:48 -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 xhr5YCziBWUL for ; Thu, 8 Aug 2013 12:45:44 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAC311E820D for ; Thu, 8 Aug 2013 12:45:43 -0700 (PDT) X-TM-IMSS-Message-ID: <343f8b02000a1822@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 343f8b02000a1822 ; Thu, 8 Aug 2013 15:45:13 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) with mapi id 14.02.0342.003; Thu, 8 Aug 2013 15:45:41 -0400 From: "Igoe, Kevin M." To: "cfrg@irtf.org" Thread-Topic: Task for the CFRG Thread-Index: Ac6Ub9vopigPuZ74Q3i+O+WDV9xpLQ== Date: Thu, 8 Aug 2013 19:45:40 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@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.228.46] Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CAB247161DMSMRGH1UEA03cor_" MIME-Version: 1.0 Subject: [Cfrg] Task for the CFRG X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:45:48 -0000 --_000_3C4AAD4B5304AB44A6BA85173B4675CAB247161DMSMRGH1UEA03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The TLS WG has asked the CFRG for their opinion for a stream cipher, eSTREA= M-SALSA20, and two MAC algorithms, UMAC and POLY1305, that have been suggested for use= in TLS (draft-josefsson-salsa20-tls-02). This was presented to the TLS WG at IETF= -87, slides can be found at http://www.ietf.org/proceedings/87/slides/slides-87-tls-2.pdf. The SALSA family works on blocks of 512 bits, and forms a key stream in 512= -bit blocks by applying a fixed map V^{512}->V^{512} to an input consisting of the key (ei= ther 16 octets or 32 octets), an 8-octet block counter, an 8-octet IV, and 16 constant octet= s. SALSA20 was one of the five finalists for a software stream cipher in the e= STREAM contest run by ECRYPTII (see http://www.ecrypt.eu.org/stream/). UMAC has been around since 1999 and is described in RFC 4418. POLY1305 first showed up as POLY1305-AES, but all it needs from AES is a 16= byte block of output. Adapting this to SALSA is straightforward. The 1305 in the name= reflects the fact that it uses arithmetic modulo 2^{130} - 5. See http://cr.yp.to/mac/p= oly1305-20050329.pdf for a description of poly1305-AES. Off the top of my head, the only objection I can see is that SALSA may be d= ifficult to implement efficiently in hardware. Hardware TLS acceleration can be useful= at heavily utilized servers. The most current attempt to attack SALSA that I could find is a 2012 paper = on the IACR e-print server. ----------------+-------------------------------------------------- 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 - ----------------+-------------------------------------------------- --_000_3C4AAD4B5304AB44A6BA85173B4675CAB247161DMSMRGH1UEA03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The TLS WG has asked the CFRG for their opinion for a stream cipher, e= STREAM-SALSA20,
and two MAC algorithms, UMAC and POLY1305, that have been suggested fo= r use in TLS
(draft-josefsson-salsa20-tls-02).  This was presented to the TLS = WG at IETF-87, slides can
The SALSA family works on blocks of 512 bits, and forms a key stream i= n 512-bit blocks by
applying a fixed map V^{512}->V^{512} to an input consisting of the= key (either 16 octets or
32 octets), an 8-octet block counter, an 8-octet IV, and 16 constant = octets.
=  
SALSA20 was one of the five finalists for a software stream cipher in = the eSTREAM
contest run by ECRYPTII (see http://www.ecrypt.eu.org/stream/= ).
=  
UMAC has been around since 1999 and is described in RFC 4418.
 
POLY1305 first showed up as POLY1305-AES, but all it needs from AES is= a 16 byte block
of output. Adapting this to SALSA is straightforward. The 1305 in the= name reflects the
fact that it uses arithmetic modulo 2^{130} – 5.  See ht= tp://cr.yp.to/mac/poly1305-20050329.pdf
for a description of poly1305-AES.
=  
Off the top of my head, the only objection I can see is that SALSA may= be difficult to
implement efficiently in hardware.  Hardware TLS acceleration can= be useful at heavily
utilized servers.
=  
The most current attempt to attack SALSA that I could find is a 2012 p= aper on the IACR
e-print server.
 
----------------+------------------------------------= --------------
Kevin M. Igoe   | "We can't solve problems= by using the same kind
kmigoe@nsa.gov  | of thinking we used when we create= d them."
         &nb= sp;      |      &nbs= p;       - Albert Einstein -
----------------+------------------------------------= --------------
 
 
 
--_000_3C4AAD4B5304AB44A6BA85173B4675CAB247161DMSMRGH1UEA03cor_-- From ted@krovetz.net Thu Aug 8 13:24:31 2013 Return-Path: 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 0C04111E821E for ; Thu, 8 Aug 2013 13:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 bOPEwOhdY4UB for ; Thu, 8 Aug 2013 13:24:23 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id CE29611E820D for ; Thu, 8 Aug 2013 13:24:19 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so3797106pbb.13 for ; Thu, 08 Aug 2013 13:24:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=qB7YtHhhhVBscyAoEKYXDlV51nb5bjfzwISJ6fVhQP4=; b=Y31gGBH63+XuoHwEsDBXzheaxq/ki4YP0g8aiYHoawdsqFgFz/v/mKtZUIGeKnk1iv bQ2yH+0XvWcYlhDiZUsf9y57uA48bkMF+A/fingrwvx4NL8jyS7GPkypC7aY/Cfx9WZZ TY1W6Mqubks3Q9pD1EUfxZVrxlEtFF2C/HA0Lp/mNdAIcJOocT/I4eoY0fkoy00CVCQ5 6CCkYuMlWrbWRmZ410+DSHtYN0YfusmIZvUVJMcIGQmXTQlZ/Ogq87mYkbtS8pMFMu5U 1X3dg8m7Jgb/6gMDNyJNmaNDf1xMk/tS3P78f825Irm2ogrvQHtp19WmISvD+fRDZam4 RmfA== X-Gm-Message-State: ALoCoQnAXvnBKe289guTITv9m1lpNBxTDf/jsBY4mGueIBwjBqSit+V2q5HMYftLNLD7sjpTJOrQ X-Received: by 10.66.154.1 with SMTP id vk1mr7997591pab.85.1375993452752; Thu, 08 Aug 2013 13:24:12 -0700 (PDT) Received: from [192.168.1.162] (c-67-166-145-119.hsd1.ca.comcast.net. [67.166.145.119]) by mx.google.com with ESMTPSA id sx7sm15929681pbc.41.2013.08.08.13.24.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 13:24:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Krovetz In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> Date: Thu, 8 Aug 2013 13:24:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> To: "cfrg@irtf.org" X-Mailer: Apple Mail (2.1508) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 20:24:31 -0000 > 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= From prvs=1932d60b24=uri@ll.mit.edu Thu Aug 8 13:51:57 2013 Return-Path: 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 ; 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 ; 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 ; 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" To: Ted Krovetz , "cfrg@irtf.org" Date: Thu, 8 Aug 2013 16:51:37 -0400 Thread-Topic: [Cfrg] Task for the CFRG Thread-Index: Ac6UeRTAWd5LkSXyQMGwWOBxGCriaA== Message-ID: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 20:51:57 -0000 --B_3458825497_16844727 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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" 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 --B_3458825497_16844727 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUFAYJKoZIhvcNAQcCoIIUBTCCFAECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghHjMIIEyzCCA7OgAwIBAgIKZmfFegAAAABv3jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDYwNTE3NDg1NVoXDTE0MDYwNTE3NDg1NVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQD0pxreUKJmz3cYObjwcqXaTyUCzAwXTeB7BABDIopD F0wfCHEAhf3lZCftQRtrN6lcvk2d530ESc00q11bwFjiifpTGVTJoxiumHVgFInWHrECeQy0 B9BWM4XiWY3MXvqFjsQJ8HmqQTGqLk9+0/4/CyEXEnwNqAWNYA2K2uLWuJb/WSiimxfcBc/p rIn+ObsIpkDnACG2jWRkE41GklcmaTexUTQetGRFVfYwrC73+4EQs32IKDVnJ+Rd2/yqwHgr i0kNwR8tu/5qIux4j0YVAwucQF43Mj2LmVhwCqHxHm4mVVJQQLJkS5ZA9wycKyze3Fm7k6h8 11i7laYKWiyvAgMBAAGjggGTMIIBjzAdBgNVHQ4EFgQUxkrbqy+gJYz6KplY/VQJigLNuzMw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYB BQUHAQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTIwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAw PQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhcveMof/ inMCAWQCAQUwIgYDVR0lAQH/BBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwGAYDVR0gBBEw DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAUpfpR1Sa9nInr3dVDOMvGcxg7GwHdSoCD9xCTXfPxqAkzI3UdOm6fLPUE7Wd XtaLsoInWIK/gP2uRTONUNbUScH21ia+J0UjZj5t2cbU+akefQkeobYXGAsa1BxIFSjaRQrq oLuZocef2ut8FjFeiU+YmNH4DAMGqtcg54Yq5PTdLVzZKJv8Z6vsJVcWgb/pLNIZ2dByb8K5 48A/rjUeJcBL/Gy0EveUYJAWTQvbCjZwFFdubfjoPDu2qFuhgAhAlER/fzTcq5bapjYnfEHZ /Yx6Tmg5hUl5zNhr6dQY7p3yb+koIiTz7gJCQFc/FZSGxfD4ScPTnCJZXhMPFOUbSDCCBLcw ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9v dCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7Deg MwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDK Ip5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2 QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0z XPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yK sORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRn qnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBTMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYBBQUH MAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEG MA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3 EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0G CyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8QXAqk zSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD 2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AU meFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWB snsX3nVTRdHCVi+Cf3Cx4YDWMIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMD UEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIz NTk1OVowVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx DDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMVOKRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKv f9VSQToAsA6q1bACtZUcMv5ZKx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXT XYQIdp1DgjtdADKVLAjXaYpD2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/ hipJ6+sI/ZtrFRmsKGhuwAKobFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpX TZFcM9SOX0f7wmsYi1yFuKFMnQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW 6oMCAwEAAaNgMF4wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3y EMND7SkwHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0G CSqGSIb3DQEBBQUAA4IBAQA+G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I 1Nf02qDU/GO2H9ETvnvTYhvfgQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8P yYtZtngb6DgeEUv+SwFnzcLO1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/ LbPjNuPdgJfO3d1WrHr1Etaaa0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/Yr oyqWFnH2KkNxRn9+2Ar7g3rnrOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90 ivQAMIIEzjCCA7agAwIBAgIKLRt82QAAAABhCDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDIyODE2MTcxNFoXDTE0MDIyODE2MTcxNFowYTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsT BlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCqgQaJR3nurw/TB1Gm3yRezeYoc6BXhdtn9ZToWjJA044X 519aJBKnWyVpLdTgGMmT1uX48QQrKT6WT6QyIqPlpPqZpq9Ex+ZPKOfbk5Jl1Pw5SnceFZQb z1EIMgvz8JX2vhfMrr6DCDk1YIQY+F9ox/iTZTlLwWthnor6FhNLWCz0Rg+d5IPrTWfTzWSn w71hQb6iY8xmrtCJ5njGJUUx1Z6xQ4v26vSvAGLqg9NsAHdaHuQkTCEzDIyRZ9QzfA8+Bti3 sB40yHSTgORE1BQ1wa5+CwyitHq4sSb8NOW41tQ0OnE+QL+rW9anJYkbOzBWHvMbWgo3p1Q8 B8yGuZlnAgMBAAGjggGWMIIBkjAdBgNVHQ4EFgQUdbttDhxCbk/gVL/0gcb3CagQkHQwDgYD VR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUH AQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIw IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJ KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SAC AWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEw DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAWHiBeNYY8PIHTsg1fyOX8E3PpnPiKvRyNpYEQ29ZWfgcEZo9OKtyeque14vn +t2jWRp+c7XQvmy0JUZO8Zz3RFFfjezTLfY6LCFWltJoRwGZRyhRC0SWOEsRzcFKrYFB/S5f NYjV69Id9UCNSnlSUTr+NxbVIczfs9TlbYstjamllfrms+XHhzH/xfLQ4bB8HOdxunlgsqBU 3jS7H7hpafBbWhL1Mt5685pAbj1hSAVy4bd1JkJSWi7O6M5Ca4KRp7l0XSZX6Au5h6eoy8IQ aC5xtxVNSUTWSI6ysoH0AzyZUH9nSu3iOM+sMYzKENqijk/pzM7vCDEb89M4S5ffhjGCAfUw ggHxAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMgIKZmfFegAAAABv3jANBglg hkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCUqT5taqE/4+tnrPjwGslrpWTDW57/RXox +CujzhU32zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA4 MDgyMDUxMzdaMA0GCSqGSIb3DQEBAQUABIIBALrPB65oXrA/sPYSGl9hC7i7Ynv5ICbd3n3+ FJvr9CpKzk7M5zjRPlW1RaIe+KQIJQ4qWRx6Ef2sx/Ho9yLCfeiw1geaeZrggg6MnQZjMXoi TQS8rRchCUc0Cwx+lVq3S7aCBBHw1ZR2WsAUHIMSMRMJLYxqcpSwxknm2Zf/yQwf/BtDBdLo Qfur8hyz7q0ervbbGgJleOfMfvOdyZ4dv0hiLuwWNHrucEu2y5dTHyDXSy5DHZWJqp/479qs DiweHfYvjU6PQGUl3jpzaamI+/kq2TIhtoH57oL+xu0BTPh8SvkrRPZQLgHd7M0tgY16q7CU p6wNY29x9aOJ1QlXNKY= --B_3458825497_16844727-- From prvs=4933d59343=dbrown@certicom.com Fri Aug 9 10:26:10 2013 Return-Path: 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 7B13C11E8114 for ; Fri, 9 Aug 2013 10:26:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 zjl2-6b57ng4 for ; Fri, 9 Aug 2013 10:26:05 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0A46121F841B for ; Fri, 9 Aug 2013 10:21:12 -0700 (PDT) X-AuditID: 0a412830-b7fca6d000000728-42-520525019886 Received: from XCT103CNC.rim.net (xct103cnc.rim.net [10.65.161.203]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id A9.90.01832.10525025; Fri, 9 Aug 2013 12:21:05 -0500 (CDT) Received: from XCT111CNC.rim.net (10.65.161.211) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Aug 2013 13:21:05 -0400 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Fri, 9 Aug 2013 13:21:04 -0400 From: Dan Brown To: "'kmigoe@nsa.gov'" , "'cfrg@irtf.org'" Thread-Topic: theoretical question ... RE: Task for the CFRG Thread-Index: Ac6Ub9vopigPuZ74Q3i+O+WDV9xpLQArEIUQ Date: Fri, 9 Aug 2013 17:21:04 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF51D9E4D@XMB111CNC.rim.net> References: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0123_01CE9503.4A9062A0" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLsWRmVeSWpSXmKPExsXC5bjwtC6jKmuQQfcCI4vuHweZLCaces3q wOQxeeNhNo/+XS9ZA5ii5G2SEkvKgjPT8/TtbFJSczLLUouQWQnyGc+3L2QqePCZsaJn9wW2 Bsb/txm7GDk5JARMJHa8vsEKYYtJXLi3nq2LkYtDSKCdSWLPhe+MEM4KRonLc26yQDizGSX+ zZ7DBtLCJqAqcf/oOeYuRg4OEQEviUv91SBhYQFziVO3VjKD2CICNhI/vtxhgrCNJLov9IJt ZhFQkTi3fBFYDa+Am8TbI5fA4kICQRJtU1aBxTkFgiVm7X0LFmcUkJXYffY62BxmAXGJW0/m M0FcLSLx8OJpNghbVOLl439Q3yhK7H12lAnkZmaBXkaJZe92MUIsE5Q4OfMJC8QyBYkr1/ex TGAUm4Vk7ixkPbOQ9EAURUt8mt/PBGEbSNw/1MEKYWtLLFv4mhnC1pdoO7aaGVPcVmL/1ZVQ tqLElO6H7BC2qcTrox8ZFzByr2IUzM0oNjAzTM5L1ivKzNXLSy3ZxAhOCRoGOxjfv7c4xCjA wajEw/tUgjVIiDWxrLgy9xCjCtCMRxtWX2CUYsnLz0tVEuF9zQWU5k1JrKxKLcqPLyrNSS0+ xLibCRjwE5mluJPzgYksryTe2MCAco4ojGNoZGluaGlmbGZqYmg2VIWVxHldVT4ECgmkJ5ak ZqemFqQWwYKPiYPzEKMEB5eUSHFqXkpqUWJpSUY8KOvFFwPznlQDo/s912Wi8V+e3yzYeex9 8f3nZWu8lNYudCusXFOYajn52n9JYbaX/zujyia5bRHfNmX7o6NpD6arbVQynbpW/qGV0+ZL C+c+D3ucOuX9BOGrnyPZmLmlyk5biiSY2k7wWfulYc/ezZcqa1wOxu19d+h0+ZQF9psNaw0i 69QuHyiKONnF/fZPwgwlluKMREMt5qLiRAClJfscTQQAAA== Subject: [Cfrg] theoretical question ... RE: Task for the CFRG X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:26:10 -0000 ------=_NextPart_000_0123_01CE9503.4A9062A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0124_01CE9503.4A9062A0" ------=_NextPart_001_0124_01CE9503.4A9062A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I cannot offer an expert opinion on these symmetric algorithms, only a generic concern and a na=EFve question, both theoretical and tangential = (to the original thread). =20 =20 Generic Concern =20 The proposal is in the form of: change from algorithm A to algorithm A = or B. =20 (+) This improves security in the sense that if we know A or B is = broken, we can shut if off, and then use the other. =20 (-) If we do not know that A or B is broken, or if we cannot easily shut = off one, then the adversary can perhaps just attack the weakest choice of A = or B. =20 Arguably (+) already outweighs (-)., but furthermore, many crypto = protocols, including TLS, take two parties, perhaps one of whom can shut off A or B = and be presumed to be more knowledgeable. In other words, one side can do = (+) to mitigate the (-) above on the other side, if the enforcement to use = the secure choice can be securely conveyed. =20 =20 Na=EFve (and theoretical) Questions =20 How does TLS enable one side to enforce the choice of A or B? Does it = use a mechanism other than A or B? For a concrete example, suppose a server implements (+), choosing MAC algorithm A, shutting off B. In TLS, the = server does not sign the algorithm choice of A, right? Consequently, if MAC algorithm B is sufficiently broken, can an adversary fool the client = into using the broken MAC alg B, leveraging the fact that B is broken to mis-authenticate the approval to use B? A similar question might be = asked about the encryption algorithm. So, I am concerned that, while the = server will not use the broken algorithms, then client is still at risk, = because the adversary can impersonate the server, or the else, the client leak plaintexts to the adversary. =20 =20 I guess what I am suggesting that for (+) to successfully mitigate (-) = as outlined above, some method other than a broken algorithm should be used = to enforce the other side to use the unbroken algorithm. In the case of = TLS, this may occur at the public key level, or pre-shared key. Maybe TLS already does this: I=92ve misunderstood TLS several times already, so = maybe my concerns are unfounded. =20 Also, all this is not suggest that specific alg might be weak, as in the hypothesis above, but rather to establish how much is gained by the = change to A or B. .Put another way, maybe A=E0B substitution I outlined is = possible only if B is disasterously weak, and we can be very confident that B is = not so weak, in which case there may be no downside to allowing A or B at = all. So, this is a theoretical question, not a practical question. =20 =20 Authentication of algorithm has already been discussed a few times on = this list and others, but I forget the conclusions. =20 =20 Best regards, =20 Dan =20 =20 =20 =20 From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Igoe, Kevin M. Sent: Thursday, August 08, 2013 3:46 PM To: cfrg@irtf.org Subject: [Cfrg] Task for the CFRG =20 The TLS WG has asked the CFRG for their opinion for a stream cipher, eSTREAM-SALSA20,=20 and two MAC algorithms, UMAC and POLY1305, that have been suggested for = use in TLS (draft-josefsson-salsa20-tls-02). This was presented to the TLS WG at IETF-87, slides can be found at = http://www.ietf.org/proceedings/87/slides/slides-87-tls-2.pdf. The SALSA family works on blocks of 512 bits, and forms a key stream in 512-bit blocks by applying a fixed map V^{512}->V^{512} to an input consisting of the key (either 16 octets or 32 octets), an 8-octet block counter, an 8-octet IV, and 16 constant = octets. =20 SALSA20 was one of the five finalists for a software stream cipher in = the eSTREAM contest run by ECRYPTII (see http://www.ecrypt.eu.org/stream/). =20 UMAC has been around since 1999 and is described in RFC 4418. =20 POLY1305 first showed up as POLY1305-AES, but all it needs from AES is a = 16 byte block of output. Adapting this to SALSA is straightforward. The 1305 in the = name reflects the fact that it uses arithmetic modulo 2^{130} =96 5. See http://cr.yp.to/mac/poly1305-20050329.pdf for a description of poly1305-AES. =20 Off the top of my head, the only objection I can see is that SALSA may = be difficult to implement efficiently in hardware. Hardware TLS acceleration can be = useful at heavily=20 utilized servers. =20 The most current attempt to attack SALSA that I could find is a 2012 = paper on the IACR e-print server. =20 ----------------+-------------------------------------------------- Kevin M. Igoe | "We can't solve problems by using the same kind kmigoe@nsa.gov | of thinking we used when we created them."=20 | - Albert Einstein - ----------------+-------------------------------------------------- =20 =20 =20 ------=_NextPart_001_0124_01CE9503.4A9062A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I cannot offer an expert opinion on these symmetric algorithms, only = a generic concern and a na=EFve question, both theoretical and = tangential (to the original thread).

 

 

Generic Concern

 

The proposal is in the form of: change from algorithm A to algorithm = A or B.=A0

 

(+) This improves security in the sense that if we know A or B is = broken, we can shut if off, and then use the = other.

 

(-) If we do not know that A or B is broken, or if we cannot easily = shut off one, then the adversary can perhaps just attack the weakest = choice of A or B.

 

Arguably (+) already outweighs (-)., but furthermore, many crypto = protocols, including TLS, take two parties, perhaps one of whom can shut = off A or B and be presumed to be more knowledgeable.=A0 In other words, = one side can do (+) to mitigate the (-) above on the other side, if the = enforcement to use the secure choice can be securely = conveyed.

 

 

Na=EFve (and theoretical) Questions

 

How does TLS enable one side to enforce the choice of A or B? Does it = use a mechanism other than A or B?=A0=A0 For a concrete example, suppose = a server implements (+), choosing MAC algorithm A, shutting off B. In = TLS, the server does not sign the algorithm choice of A, right?=A0 = Consequently, if MAC algorithm B is sufficiently broken, can an = adversary fool the client into using the broken MAC alg B, leveraging = the fact that B is broken to mis-authenticate the approval to use B?=A0 = A similar question might be asked about the encryption algorithm.=A0 So, = I am concerned that, while the server will not use the broken = algorithms, then client is still at risk, because the adversary can = impersonate the server, or the else, the client leak plaintexts to the = adversary.=A0

 

I guess what I am suggesting that for (+) to successfully mitigate = (-) as outlined above, some method other than a broken algorithm should = be used to enforce the other side to use the unbroken algorithm.=A0 In = the case of TLS, this may occur at the public key level, or pre-shared = key. =A0Maybe TLS already does this: I’ve misunderstood TLS = several times already, so maybe my concerns are = unfounded.

 

Also, all this is not suggest that specific alg might be weak, as in = the hypothesis above, but rather to establish how much is gained by the = change to A or B. .Put another way, maybe A=E0= B substitution I outlined is possible only if B is disasterously = weak, and we can be very confident that B is not so weak, in which case = there may be no downside to allowing A or B at all.=A0 So, this is a = theoretical question, not a practical question.=A0 =

 

Authentication of algorithm has already been discussed a few times on = this list and others, but I forget the conclusions.=A0 = =A0

 

Best regards,

 

Dan

 

 

 

 

From:= = cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of = Igoe, Kevin M.
Sent: Thursday, August 08, 2013 3:46 = PM
To: cfrg@irtf.org
Subject: [Cfrg] Task for the = CFRG

 

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

(draft-jose= fsson-salsa20-tls-02).  This was presented to the TLS WG at = IETF-87, slides can=

The SALSA = family works on blocks of 512 bits, and forms a key stream in 512-bit = blocks by

applying a = fixed map V^{512}->V^{512} to an input consisting of the key (either = 16 octets or

32 = octets), an 8-octet block counter, an 8-octet IV, and 16 constant = octets.

 =

SALSA20 = was one of the five finalists for a software stream cipher in the = eSTREAM

contest = run by ECRYPTII (see http://www.ecrypt.eu.org/stream= /).

 =

UMAC has = been around since 1999 and is described in RFC = 4418.

 =

POLY1305 = first showed up as POLY1305-AES, but all it needs from AES is a 16 byte = block

of output. = Adapting this to SALSA is straightforward. The 1305 in the name reflects = the

fact that = it uses arithmetic modulo 2^{130} – 5.  See http://cr.yp.to/mac/po= ly1305-20050329.pdf

for a = description of poly1305-AES.

 =

Off the = top of my head, the only objection I can see is that SALSA may be = difficult to

implement = efficiently in hardware.  Hardware TLS acceleration can be useful = at heavily

utilized = servers.

 =

The most = current attempt to attack SALSA that I could find is a 2012 paper on the = IACR

e-print = server.

 =

----------------+------------------------------------= --------------=

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 -=

----------------+------------------------------------= --------------=

 =

 =

 =

------=_NextPart_001_0124_01CE9503.4A9062A0-- ------=_NextPart_000_0123_01CE9503.4A9062A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6 xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2 6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0 KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODA5 MTcyMTAwWjAjBgkqhkiG9w0BCQQxFgQUFyacWxoBeAZzy0wCFRJaLbjQfR0wZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgKgeutU1YB2X Ga5yjYiiOPa0kMSYtp/HKUuP7oH512q24QtAeGJ0p0K9G7H78ZHLQhL/O2Ggm593RKGORTNzi8wb d+6naKSx9AmLRhA9OtMf3yDqSdNK4KYH9t7QL3jWGhS6nB1N0wP0v5R/Z5tv9P2TPmfEdysF2vve IuGJV7VFAAAAAAAA ------=_NextPart_000_0123_01CE9503.4A9062A0-- From kmigoe@nsa.gov Fri Aug 9 12:01:28 2013 Return-Path: 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 D05FE21E80A8 for ; Fri, 9 Aug 2013 12:01: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 UpZvd0C0w40Y for ; Fri, 9 Aug 2013 12:01:23 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6B88D21F89D8 for ; Fri, 9 Aug 2013 11:55:50 -0700 (PDT) X-TM-IMSS-Message-ID: Received: from MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id c3db8512000a85e7 ; Fri, 9 Aug 2013 15:01:42 -0400 Received: from MSMR-GH1-UEA04.corp.nsa.gov (10.215.228.141) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 9 Aug 2013 14:55:42 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA04.corp.nsa.gov ([10.215.228.141]) with mapi id 14.02.0342.003; Fri, 9 Aug 2013 14:55:42 -0400 From: "Igoe, Kevin M." To: "cfrg@irtf.org" Thread-Topic: theoretical question ... RE: Task for the CFRG Thread-Index: Ac6Ub9vopigPuZ74Q3i+O+WDV9xpLQArEIUQAANZJsAAAhxKIA== Date: Fri, 9 Aug 2013 18:55:40 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CAB2471708@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.215.228.46] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0013_01CE9510.851B5760" MIME-Version: 1.0 Subject: [Cfrg] FW: theoretical question ... RE: Task for the CFRG X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 19:01:28 -0000 ------=_NextPart_000_0013_01CE9510.851B5760 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0014_01CE9510.851B5760" ------=_NextPart_001_0014_01CE9510.851B5760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (Forgot to add the CFRG mailing list to this reply) =20 From: Igoe, Kevin M.=20 Sent: Friday, August 09, 2013 2:54 PM To: 'Dan Brown' Subject: RE: theoretical question ... RE: Task for the CFRG =20 To answer the concrete question about TLS, the client handshake passes a list of cipher suites the client is willing to use to the server. The server selects a cipher=20 suite that it supports from the client=92s list and passes their = selection back to the=20 client , or signals failure if there is no cipher suite they both = support. The standard=20 doesn=92t specify how the server selects a cipher suite, it is free to implement this as it sees fit. =20 Each cipher suite consists of a quadruplet=20 ( key agreement algorithm, authentication algorithm,=20 encryption algorithm, hash algorithm). IANA maintains a list of TLS cipher suites registry with entries like =20 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA =3D { 0xC0, 0x09 } =20 which breaks out as ephemeral elliptic curve Diffie Hellman for key agreement, elliptic curve DSA for authentication, AES with 128-bit key for = encryption, and SHA-1=20 for hash. (Note: thanks to IANA, the client=92s list of cipher suite is = just a list of=20 2-octet values rather than list of long character strings). The IANA registry also points to an RFC which provides further details on the cipher suite (RFC 4492 in this case). =20 At any rate, TLS already supports dozens of cipher suites (the soon to = come TLS 1.3 hopes to cull this down). Adding a handful of SALSA based suites = shouldn=92t be an issue. =20 =20 From: Dan Brown [mailto:dbrown@certicom.com]=20 Sent: Friday, August 09, 2013 1:21 PM To: Igoe, Kevin M.; 'cfrg@irtf.org' Subject: theoretical question ... RE: Task for the CFRG =20 I cannot offer an expert opinion on these symmetric algorithms, only a generic concern and a na=EFve question, both theoretical and tangential = (to the original thread). =20 =20 Generic Concern =20 The proposal is in the form of: change from algorithm A to algorithm A = or B. =20 (+) This improves security in the sense that if we know A or B is = broken, we can shut if off, and then use the other. =20 (-) If we do not know that A or B is broken, or if we cannot easily shut = off one, then the adversary can perhaps just attack the weakest choice of A = or B. =20 Arguably (+) already outweighs (-)., but furthermore, many crypto = protocols, including TLS, take two parties, perhaps one of whom can shut off A or B = and be presumed to be more knowledgeable. In other words, one side can do = (+) to mitigate the (-) above on the other side, if the enforcement to use = the secure choice can be securely conveyed. =20 =20 Na=EFve (and theoretical) Questions =20 How does TLS enable one side to enforce the choice of A or B? Does it = use a mechanism other than A or B? For a concrete example, suppose a server implements (+), choosing MAC algorithm A, shutting off B. In TLS, the = server does not sign the algorithm choice of A, right? Consequently, if MAC algorithm B is sufficiently broken, can an adversary fool the client = into using the broken MAC alg B, leveraging the fact that B is broken to mis-authenticate the approval to use B? A similar question might be = asked about the encryption algorithm. So, I am concerned that, while the = server will not use the broken algorithms, then client is still at risk, = because the adversary can impersonate the server, or the else, the client leak plaintexts to the adversary. =20 =20 I guess what I am suggesting that for (+) to successfully mitigate (-) = as outlined above, some method other than a broken algorithm should be used = to enforce the other side to use the unbroken algorithm. In the case of = TLS, this may occur at the public key level, or pre-shared key. Maybe TLS already does this: I=92ve misunderstood TLS several times already, so = maybe my concerns are unfounded. =20 Also, all this is not suggest that specific alg might be weak, as in the hypothesis above, but rather to establish how much is gained by the = change to A or B. .Put another way, maybe A=E0B substitution I outlined is = possible only if B is disasterously weak, and we can be very confident that B is = not so weak, in which case there may be no downside to allowing A or B at = all. So, this is a theoretical question, not a practical question. =20 =20 Authentication of algorithm has already been discussed a few times on = this list and others, but I forget the conclusions. =20 =20 Best regards, =20 Dan =20 =20 =20 =20 From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Igoe, Kevin M. Sent: Thursday, August 08, 2013 3:46 PM To: cfrg@irtf.org Subject: [Cfrg] Task for the CFRG =20 The TLS WG has asked the CFRG for their opinion for a stream cipher, eSTREAM-SALSA20,=20 and two MAC algorithms, UMAC and POLY1305, that have been suggested for = use in TLS (draft-josefsson-salsa20-tls-02). This was presented to the TLS WG at IETF-87, slides can be found at = http://www.ietf.org/proceedings/87/slides/slides-87-tls-2.pdf. The SALSA family works on blocks of 512 bits, and forms a key stream in 512-bit blocks by applying a fixed map V^{512}->V^{512} to an input consisting of the key (either 16 octets or 32 octets), an 8-octet block counter, an 8-octet IV, and 16 constant = octets. =20 SALSA20 was one of the five finalists for a software stream cipher in = the eSTREAM contest run by ECRYPTII (see http://www.ecrypt.eu.org/stream/). =20 UMAC has been around since 1999 and is described in RFC 4418. =20 POLY1305 first showed up as POLY1305-AES, but all it needs from AES is a = 16 byte block of output. Adapting this to SALSA is straightforward. The 1305 in the = name reflects the fact that it uses arithmetic modulo 2^{130} =96 5. See http://cr.yp.to/mac/poly1305-20050329.pdf for a description of poly1305-AES. =20 Off the top of my head, the only objection I can see is that SALSA may = be difficult to implement efficiently in hardware. Hardware TLS acceleration can be = useful at heavily=20 utilized servers. =20 The most current attempt to attack SALSA that I could find is a 2012 = paper on the IACR e-print server. =20 ----------------+-------------------------------------------------- Kevin M. Igoe | "We can't solve problems by using the same kind kmigoe@nsa.gov | of thinking we used when we created them."=20 | - Albert Einstein - ----------------+-------------------------------------------------- =20 =20 =20 ------=_NextPart_001_0014_01CE9510.851B5760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

(Forgot to add the CFRG mailing list to this = reply)

 

From:= = Igoe, Kevin M.
Sent: Friday, August 09, 2013 2:54 = PM
To: 'Dan Brown'
Subject: RE: theoretical question = ... RE: Task for the CFRG

 

To answer the concrete question about TLS, the client handshake = passes a list of

cipher suites the client is willing to use to the server.  =  The server selects a cipher

suite that  it supports from the client’s list and passes = their selection back to the

client , or signals failure if there is no cipher suite they both = support.  The standard

doesn’t specify how the server selects a cipher suite, it is = free to implement

this as it sees fit.

 

Each cipher suite consists of a quadruplet

      ( key agreement algorithm, =  authentication algorithm,

        encryption algorithm, = hash algorithm).

IANA maintains a list of TLS cipher suites registry with entries = like

 

  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA =3D { 0xC0, 0x09 = }

 

which breaks out as ephemeral elliptic curve Diffie Hellman for key = agreement,

elliptic curve DSA for authentication, AES with 128-bit key for = encryption, and SHA-1

for hash.  (Note: thanks to IANA, the client’s list of = cipher suite is just a list of

2-octet values rather than list of long character strings).  The = IANA registry also

points to an RFC which provides further details on the cipher suite = (RFC 4492

in this case).

 

At any rate, TLS already supports dozens of cipher suites (the soon = to come TLS 1.3

hopes to cull this down). Adding a handful of SALSA based suites = shouldn’t be an issue.

 

 

From:= = Dan Brown [mailto:dbrown@certicom.com]
Sent: Friday, August = 09, 2013 1:21 PM
To: Igoe, Kevin M.; = 'cfrg@irtf.org'
Subject: theoretical question ... RE: Task for = the CFRG

 

I cannot offer an expert opinion on these symmetric algorithms, only = a generic concern and a na=EFve question, both theoretical and = tangential (to the original thread).

 

 

Generic Concern

 

The proposal is in the form of: change from algorithm A to algorithm = A or B. 

 

(+) This improves security in the sense that if we know A or B is = broken, we can shut if off, and then use the = other.

 

(-) If we do not know that A or B is broken, or if we cannot easily = shut off one, then the adversary can perhaps just attack the weakest = choice of A or B.

 

Arguably (+) already outweighs (-)., but furthermore, many crypto = protocols, including TLS, take two parties, perhaps one of whom can shut = off A or B and be presumed to be more knowledgeable.  In other = words, one side can do (+) to mitigate the (-) above on the other side, = if the enforcement to use the secure choice can be securely = conveyed.

 

 

Na=EFve (and theoretical) Questions

 

How does TLS enable one side to enforce the choice of A or B? Does it = use a mechanism other than A or B?   For a concrete example, = suppose a server implements (+), choosing MAC algorithm A, shutting off = B. In TLS, the server does not sign the algorithm choice of A, = right?  Consequently, if MAC algorithm B is sufficiently broken, = can an adversary fool the client into using the broken MAC alg B, = leveraging the fact that B is broken to mis-authenticate the approval to = use B?  A similar question might be asked about the encryption = algorithm.  So, I am concerned that, while the server will not use = the broken algorithms, then client is still at risk, because the = adversary can impersonate the server, or the else, the client leak = plaintexts to the adversary. 

 

I guess what I am suggesting that for (+) to successfully mitigate = (-) as outlined above, some method other than a broken algorithm should = be used to enforce the other side to use the unbroken algorithm.  = In the case of TLS, this may occur at the public key level, or = pre-shared key.  Maybe TLS already does this: I’ve = misunderstood TLS several times already, so maybe my concerns are = unfounded.

 

Also, all this is not suggest that specific alg might be weak, as in = the hypothesis above, but rather to establish how much is gained by the = change to A or B. .Put another way, maybe A=E0= B substitution I outlined is possible only if B is disasterously = weak, and we can be very confident that B is not so weak, in which case = there may be no downside to allowing A or B at all.  So, this is a = theoretical question, not a practical question.  =

 

Authentication of algorithm has already been discussed a few times on = this list and others, but I forget the conclusions.  =  

 

Best regards,

 

Dan

 

 

 

 

From:= = cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of = Igoe, Kevin M.
Sent: Thursday, August 08, 2013 3:46 = PM
To: cfrg@irtf.org
Subject: [Cfrg] Task for the = CFRG

 

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

(draft-jose= fsson-salsa20-tls-02).  This was presented to the TLS WG at = IETF-87, slides = can=

The SALSA = family works on blocks of 512 bits, and forms a key stream in 512-bit = blocks by

applying a = fixed map V^{512}->V^{512} to an input consisting of the key (either = 16 octets or

32 = octets), an 8-octet block counter, an 8-octet IV, and 16 constant = octets.

 =

SALSA20 = was one of the five finalists for a software stream cipher in the = eSTREAM

contest = run by ECRYPTII (see http://www.ecrypt.eu.org/stream= /).

 =

UMAC has = been around since 1999 and is described in RFC = 4418.

 =

POLY1305 = first showed up as POLY1305-AES, but all it needs from AES is a 16 byte = block

of output. = Adapting this to SALSA is straightforward. The 1305 in the name reflects = the

fact that = it uses arithmetic modulo 2^{130} – 5.  See http://cr.yp.to/mac/po= ly1305-20050329.pdf

for a = description of poly1305-AES.

 =

Off the = top of my head, the only objection I can see is that SALSA may be = difficult to

implement = efficiently in hardware.  Hardware TLS acceleration can be useful = at heavily

utilized = servers.

 =

The most = current attempt to attack SALSA that I could find is a 2012 paper on the = IACR

e-print = server.

 =

----------------+------------------------------------= --------------=

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 -=

----------------+------------------------------------= --------------=

 =

 =

 =

------=_NextPart_001_0014_01CE9510.851B5760-- ------=_NextPart_000_0013_01CE9510.851B5760 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITVTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIFIzCCBAugAwIBAgICZ/cwDQYJKoZIhvcNAQEFBQAw XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yMjAeFw0xMTEwMDYxNTE4NThaFw0x NDEwMDYxNTE4MjRaMHcxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdPVkVSTk1FTlQxDDAK BgNVBAsTA0RPRDEMMAoGA1UECxMDUEtJMRAwDgYDVQQLEwdOU0EvQ1NTMSAwHgYDVQQDExdJR09F LktFVklOLk0uOTUwMDAwMTQ1NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN3YrH0T n1Zl9oq12B+AT3ViDFyOFVNb4Cy146E3sg6aYsosdYwLwe1oCWgmATvFiCN7DihUX79u19Qgxze0 1wFwLKPnVcyUj3LBS8y2MWxpH8uEVftUHI3eV/V27bWN+KAsYpYsWafzMN2hltOZPRvShydK8MD6 iY6SkuANC52ZeSwazrKGPwro9bNp5enR0U6/3BwASoMTm2NoigAvtFiCTLbksljV3YfasW7J37qx qOgsX7janSOUJbMPluztOX9yCOMyVKe2QzeCEnF4DsqIF0cEmc8eh9VhoUut9HnT5RzLCG/Orttn 99cjrfkcN+E5ab8dLR0ZumR+EnCIfo0CAwEAAaOCAdEwggHNMB8GA1UdIwQYMBaAFIUvDQqvNQhQ CY2bHHCsqP6Jd5RaMIHQBgNVHR8EgcgwgcUwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjIuY3JsMIGRoIGOoIGLhoGIbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24l M2RET0QlMjBFTUFJTCUyMENBLTIyJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIw R292ZXJubWVudCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTAOBgNV HQ8BAf8EBAMCBsAwIwYDVR0gBBwwGjALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsSMBkGA1UdEQQS MBCBDmttaWdvZUBuc2EuZ292MGgGCCsGAQUFBwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2Ny bC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjIuY2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2Nz cC5kaXNhLm1pbDAdBgNVHQ4EFgQUgPdnplR7nZcIcngwmGhUsVSkZt4wDQYJKoZIhvcNAQEFBQAD ggEBABaGmMN7TWTOKL68krMG/Ae2OTE/bFktk2JXmBlAVqyvwpHbJK/FU4BSdCX+rtcBJ8vD7FRD cBUf5wTdZ9KUX7UW8nyhUHfiqz4im5uwRBj22G2UBCc0f6Lyu+1M0wngmHu3TK8n4WcLixuzq48g Gam5xIXn50Cwp9cYuaOanUEzLcE1RcfeDUPt9on6mwwAYbgiWAyK4KBt2UlK4QTwuY2JVmVkuBwz iG9JlKb3jDQyo3cYGoFbWaitc1IPJZwG+cvIFy1gNyMHmrrdOSP3ApF5skyyut68tGiJ/dTO97K5 YSL9BaXi3yZbgOn6l8Hvr/hVCaIwNNxSqigawNhfvyowggUjMIIEC6ADAgECAgJn+DANBgkqhkiG 9w0BAQUFADBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTIyMB4XDTExMTAwNjE1 MTg1OFoXDTE0MTAwNjE1MTgyNFowdzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR09WRVJO TUVOVDEMMAoGA1UECxMDRE9EMQwwCgYDVQQLEwNQS0kxEDAOBgNVBAsTB05TQS9DU1MxIDAeBgNV BAMTF0lHT0UuS0VWSU4uTS45NTAwMDAxNDU0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA0K0gdSxSq1iV2CVhFLbdkSs9VvfqQJaXTED/HRBdV9psCTJQdPrUms6xGtX1gd7/I/VCqfg4 MASvjvaY+Y25wczvse93T9VbDT1WJgXn+ExcBcAUeyUSbW8rZSOGaNAO7/trjLKMO/npchka6kaS DpaWIJBEmrwaMQTi70XYeoqhrs384vvW73+WVaAIoGKKFgbXhKwYb1C5LgwgfBZ+2U+r5Qk6idv1 PkFEKc0g2uJPzSlxH1uQHLodZiUb5KKbtA+HF3FpC8AdfP/MxWQJJawtQUxpz26jO8a/U9d7ey4E 9pqBWIjm4COSi9dMuy86PE5tveXGH6OrhZKg5LFahwIDAQABo4IB0TCCAc0wHwYDVR0jBBgwFoAU hS8NCq81CFAJjZsccKyo/ol3lFowgdAGA1UdHwSByDCBxTAvoC2gK4YpaHR0cDovL2NybC5kaXNh Lm1pbC9jcmwvRE9ERU1BSUxDQV8yMi5jcmwwgZGggY6ggYuGgYhsZGFwOi8vY3JsLmdkcy5kaXNh Lm1pbC9jbiUzZERPRCUyMEVNQUlMJTIwQ0EtMjIlMmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUz ZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7Ymlu YXJ5MA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgELBTALBglghkgBZQIBCxIw GQYDVR0RBBIwEIEOa21pZ29lQG5zYS5nb3YwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipo dHRwOi8vY3JsLmRpc2EubWlsL3NpZ24vRE9ERU1BSUxDQV8yMi5jZXIwIAYIKwYBBQUHMAGGFGh0 dHA6Ly9vY3NwLmRpc2EubWlsMB0GA1UdDgQWBBT5Avv4k2f9nxN0ZzJ3a4owkV431TANBgkqhkiG 9w0BAQUFAAOCAQEAPnWfkbiWEk+41Pwo60l+xzTgLMQz+zExbYla+lXz2V2ReRc5n5BhJRPzsx3k HPVs0j3dJBegjmx222FTZgWwAf2jp27kN5RqgGco8oUoS0zbrD3OsxPXpTzHCkWej6HSm9WDb9be vpU/ny3IE2i554dlFDVTPF9rHKXEBCO2CXRCmFNf8eUUib+BIZDHApfKCtsULP0Cl6ccU5Yl7nPy N67KiCAZZe2qxMA7jUvN5cLmHkpQDuh8s6hZlw2O8D9afb84NtRyinQw617pUJctl7H7riW1HN+W ms0wq+lMQCK2ChaBSK+l49LBKbsUe7Xtd8MF60iCqtj28KKOWKGsXjCCBY8wggR3oAMCAQICAUYw DQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290IENBIDIwHhcNMDkw MTI2MjAyNTA3WhcNMTUwMTI1MjAyNTA3WjBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBH b3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlM IENBLTIyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApgAGJSOA+fVgxAYGKAVHLhtn H760ReUcNMb0xbrSTGidUyTXl7/Y6AfPeM6a6GTFEHnTb8cdM5uIwwDx8Cn4U/3gpTEoaMkujDgH kkW0PwgCy/fuAYEtX0sVsd2A8rnA/6ntoPUnm3nseyUrJREpq/1fETxik5dCeUjAnQbRtyMlmVfe BlXKHoeTFPcSQzHRJg5t0kVMOOLSmucSr8lMXePIfx/Hygk58QlPxqLnYYF5mQvSjAtlerk8GBXO ELsvwGQaMgjRsKASjBDLs2ykcECsvVYLVKXU8UYz3Oz2UVKvJycunVWkHfddWvhkaEGJWL0vd50o 3g14X4hn/By8sQIDAQABo4ICWjCCAlYwDgYDVR0PAQH/BAQDAgGGMB8GA1UdIwQYMBaAFEl0uwxe unr+AlTve6DGlcYJgHCWMB0GA1UdDgQWBBSFLw0KrzUIUAmNmxxwrKj+iXeUWjAMBgNVHSQEBTAD gAEAMBIGA1UdEwEB/wQIMAYBAf8CAQAwgZ8GA1UdIASBlzCBlDALBglghkgBZQIBCwUwCwYJYIZI AWUCAQsJMAsGCWCGSAFlAgELCjALBglghkgBZQIBCxIwCwYJYIZIAWUCAQsTMAsGCWCGSAFlAgEL FDAMBgpghkgBZQMCAQMGMAwGCmCGSAFlAwIBAwcwDAYKYIZIAWUDAgEDCDAMBgpghkgBZQMCAQMN MAwGCmCGSAFlAwIBAxEwPwYDVR0fBDgwNjA0oDKgMIYuaHR0cDovL2NybC5kaXNhLm1pbC9nZXRj cmw/RG9EJTIwUm9vdCUyMENBJTIwMjCB/gYIKwYBBQUHAQEEgfEwge4wPwYIKwYBBQUHMAKGM2h0 dHA6Ly9jcmwuZGlzYS5taWwvZ2V0SXNzdWVkVG8/RG9EJTIwUm9vdCUyMENBJTIwMjAgBggrBgEF BQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgYgGCCsGAQUFBzAChnxsZGFwOi8vY3JsLmdkcy5k aXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIlMmNvdSUzZFBLSSUyY291JTNkRG9EJTJj byUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5MA0GCSqG SIb3DQEBBQUAA4IBAQA4VPVLiTHj8/UXF6V0n8s/iVPvQepXUcXk4s66+kAfmExuQ2stz8AZbvQX R92WkEamcy/t8Sd4h0+37QE0bnlov4XJXGVsuXuYKoqeXWFAJrzkhzWfA+rOyXkMBn5o3p1Vw9EK CH/Y5uc6g1aX4+HDsm87RHa4c2zq8McgTI8xVYCGXR7mOUSZjjShafltX3IOBUdpmgjsZdkpgJ/g r34BA7gL6RP3WCHWMP6g7nJ7gXmBDZVghD3KSLYMe4lzX5hdex4PaaoEJnxqkXD982LYUE95drpp Vvq+bruMV2+xx/4u34VlwrIXFBkcFhP9fh1vsifWExwMWZBwvVa8rgKGMYIDPjCCAzoCAQEwYzBd MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTIyAgJn9zAJBgUrDgMCGgUAoIIBsDAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA4MDkxODU1NDJaMCMG CSqGSIb3DQEJBDEWBBTrcQAEYCDonUBq5L+2bh6o0bikNzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3EAQxZTBjMF0xCzAJBgNVBAYTAlVT MRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgw FgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjICAmf4MHQGCyqGSIb3DQEJEAILMWWgYzBdMQswCQYDVQQG EwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BL STEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTIyAgJn+DANBgkqhkiG9w0BAQEFAASCAQALEmIhVnKX /zP6V2QNyxfo4wnn15pp7uVF90/06nr7EWix+xRaWWr3g+ncnQvZAt5usyO8Qsr4YQAVXm8KlVDl 0ic8f60VMbc+gQckOPmhwceM0MSIcDl4JRlMxg6IEnWAxc6OfFRMeo3CJqKutW/6pzWVb8ZAcTUS VZKZm6/PBrCW9zcDxbm0ybyhBheXcyH7z6rsAfi1RIDbpnMYbX02kv+DjPHF3QATCsKdBqN2ZZrx ZzwoK08d1KFSvxQi5mplqqqfGzTWFEXMk8G7Gu6/X0QW19KhAxvD4CXmxaayCHe8qvK+OwAqVEPB 58xaNfBnwfYSJumDA7pYGMn5+vsXAAAAAAAA ------=_NextPart_000_0013_01CE9510.851B5760-- From mcgrew@cisco.com Mon Aug 12 06:31:53 2013 Return-Path: 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 D8AD921F8F29 for ; Mon, 12 Aug 2013 06:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 JfWpdzAvU5op for ; Mon, 12 Aug 2013 06:31:49 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5037221F9CC3 for ; Mon, 12 Aug 2013 06:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2326; q=dns/txt; s=iport; t=1376313800; x=1377523400; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=9ntUdDPCj+Q/Xu/+hmPP6kaPwoLDJ+pBeT2EZHj5gRU=; b=PAo9/jUZ/G1HiyGBbmc98otgzyIRTudRbiY+vw2VjJ4S3TbHsaspuovm 2f2giyd0X6N0Njunq3WsI4uGfBTl7C1WT5+nTscG2MzS/aYzJtPVZ1bXv iX25KLn6tvEHxgYs0SsLNVevzyar2VcNQePXIW4E1Sfgl0RghKRG8itgB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJfgCFKtJXHA/2dsb2JhbABagwY1g2O7QYEZFnSCJAEBAQIBAQEBASAECwE7CxALGAICJgICJzAGEwmIAQYMpQKRIoEpjBOBLoFRB4JogSkDngyGBYUkgzcg X-IronPort-AV: E=Sophos;i="4.89,862,1367971200"; d="scan'208";a="246323855" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 12 Aug 2013 13:23:19 +0000 Received: from [10.0.2.15] (rtp-mcgrew-8913.cisco.com [10.117.10.228]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7CDNIdt019034; Mon, 12 Aug 2013 13:23:18 GMT Message-ID: <1376313807.4318.303.camel@darkstar> From: David McGrew To: "Igoe, Kevin M." Date: Mon, 12 Aug 2013 09:23:27 -0400 In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> References: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: "cfrg@irtf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 13:31:54 -0000 Thanks Kevin for laying out the questions and background here; I have a short comment inline: On Thu, 2013-08-08 at 19:45 +0000, Igoe, Kevin M. 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 > (draft-josefsson-salsa20-tls-02). This was presented to the TLS WG at > IETF-87, slides can > be found at > http://www.ietf.org/proceedings/87/slides/slides-87-tls-2.pdf. > The SALSA family works on blocks of 512 bits, and forms a key stream > in 512-bit blocks by > applying a fixed map V^{512}->V^{512} to an input consisting of the > key (either 16 octets or > 32 octets), an 8-octet block counter, an 8-octet IV, and 16 constant > octets. > > SALSA20 was one of the five finalists for a software stream cipher in > the eSTREAM > contest run by ECRYPTII (see http://www.ecrypt.eu.org/stream/). > > UMAC has been around since 1999 and is described in RFC 4418. The UMAC details evolved over the years, as people who have been in this RG since 2005 will recall (as the RFC was reviewed on this list). David > > POLY1305 first showed up as POLY1305-AES, but all it needs from AES is > a 16 byte block > of output. Adapting this to SALSA is straightforward. The 1305 in the > name reflects the > fact that it uses arithmetic modulo 2^{130} – 5. See > http://cr.yp.to/mac/poly1305-20050329.pdf > for a description of poly1305-AES. > > Off the top of my head, the only objection I can see is that SALSA may > be difficult to > implement efficiently in hardware. Hardware TLS acceleration can be > useful at heavily > utilized servers. > > The most current attempt to attack SALSA that I could find is a 2012 > paper on the IACR > e-print server. > > ----------------+-------------------------------------------------- > 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 - > ----------------+-------------------------------------------------- > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From zooko@zooko.com Mon Aug 12 12:35:25 2013 Return-Path: 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 8067F21F9F40 for ; Mon, 12 Aug 2013 12:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] 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 EWqFcVnRiZJv for ; Mon, 12 Aug 2013 12:35:06 -0700 (PDT) Received: from zooko.com (216-155-145-223.cinfuserver.com [216.155.145.223]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD9E21F9F3A for ; Mon, 12 Aug 2013 12:35:04 -0700 (PDT) Received: by zooko.com (Postfix, from userid 1000) id 66A7271E001; Mon, 12 Aug 2013 23:34:59 +0400 (MSK) Date: Mon, 12 Aug 2013 23:34:59 +0400 From: zooko To: "cfrg@irtf.org" Message-ID: <20130812193458.GF14392@zooko.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:35:26 -0000 Another point in favor of Salsa20 and especially ChaCha is that the latter formed the core of the BLAKE candidate for SHA3. BLAKE was one of the three most thoroughly-studied candidates in the SHA3 process (according to NIST's final report ¹, the most "depthof analysis" was applied to BLAKE, Skein, and Grøst). ¹ http://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf Of course, the requirements of a secure hash function aren't the same as those for a cipher, but I still think that having all those cryptographers studying that core function so closely, and not finding any major weakness in it when used as a secure hash function, gives confidence that there isn't any major weakness in it when used as a cipher. Disclosure: I'm an author of a successor hash function based on BLAKE, named "BLAKE2", but not an author of the original BLAKE. Here are my slides about that, from ACNS'13, which includes a few quotes from the NIST report: https://tahoe-lafs.org/~zooko/acns/slides.html Regards, Zooko From mcgrew@cisco.com Wed Aug 14 13:32:42 2013 Return-Path: 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 B09F211E817E for ; Wed, 14 Aug 2013 13:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 cGdsKq5dBEmj for ; Wed, 14 Aug 2013 13:32:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A926B11E8159 for ; Wed, 14 Aug 2013 13:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6428; q=dns/txt; s=iport; t=1376512360; x=1377721960; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=PJIY2iMweEoEQyal5HoPfKwRJucla9vGA8l+EJ/wAdw=; b=FMyWWotEKI4tZG5ep9ixOyTPefVxho9dzzKgw8jxVlSdXgOZ/tTdWcX1 e8fooGCPK9eZys36axB33qQ1DkZ8nQ8ZGU9KUYjS4RiKyC6IoEwa/7SB4 j92g3Kiq6YoplVyLVve3YXluaUhkSZagVVR3QnLKpY5hEzsSslYBULbH2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoGABvoC1KtJV2b/2dsb2JhbABbgwY1g2moBwGTdYEkFm0HgiQBAQEBAQIBAQEgBAsBOwsQHgUCAiYCAicwBhMJiAcMp0aRPYEpjB6BMYFYB4JogSoDmRGEfIYFhSSDNyA X-IronPort-AV: E=Sophos;i="4.89,879,1367971200"; d="scan'208";a="244401175" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 14 Aug 2013 20:32:38 +0000 Received: from [10.0.2.15] (rtp-mcgrew-8913.cisco.com [10.117.10.228]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7EKWaLs011518; Wed, 14 Aug 2013 20:32:36 GMT Message-ID: <1376512356.16950.360.camel@darkstar> From: David McGrew To: "cfrg@irtf.org" Date: Wed, 14 Aug 2013 16:32:36 -0400 In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> References: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [Cfrg] problems with draft-josefsson-salsa20-tls-02 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 20:32:42 -0000 This draft lists two motivations: RC4 security is inadequate, and the performance of the symmetric cryptography in other ciphersuites is inadequate. I agree with the first premise, and the authors deserve kudos for raising and starting to address the issue. However, the second premise is questionable. The draft cites [AEAD-PERFORMANCE], and that reference shows that the performance of AES-GCM and AES-CCM are suboptimal in some scenarios, not that they are inadequate. The draft ought to cite some other work such as [1] to provide a broader viewpoint on ciphersuite performance and deployment considerations of new ciphersuites. If it is the case that SALSA20 and UMAC (or POLY1305) compellingly outperform existing ciphersuites on some particular client environments and server environments, the draft should document the particulars. The security question that we should be considering is: are the authenticated encryption schemes defined in this draft sound? The strategy used in this draft is to rely on the "generic composition" framework provided by TLS: a new GenericStreamCipher is defined and is used at the same time as a TLS MAC algorithm, which is either the conventional TLS HMAC or the new TLS UMAC algorithm defined in this draft. Thus, there is a merely a loose binding between authentication and encryption, and a potential opportunity for a side channel attack like the ones described in [CBC-ATTACK]. The draft recognizes the value of resisting side channel attacks, but the loose binding approach works against that goal. Instead of defining a GenericStreamCipher, the draft should define an AEAD algorithm, which would close the door on that sort of vulnerability. One of the motivations for not using the TLS GenericAEADCipher mechanism is that it appears only in TLSv1.2. However, the draft proposes extensions to both the GenericStreamCipher and MAC algorithms used by TLSv1.0 and TLSv1.1, and it would be no more intrusive to those protocols to define the use of GenericAEADCipher in them. Using the same AEAD mechanism for versions 1.0, 1.1, and 1.2 would result in smaller and less complex implementation. There is ongoing work on authenticated encryption which this draft is not taking advantage of, e.g. [2]. This could be a missed opportunity; if the IETF is publishing new authenticated encryption schemes for TLS, they should improve on the existing schemes. For instance, the ciphersuites in the draft do not provide any misuse resistance; they have the same properties with respect to IV/nonce misuse as does AES-GCM. Granted that many GCM implementations successfully avoid misuse, but several observers have identified misuse resistance as a desirable property for future AEAD methods. (See for instance [3] and RFC 5297.) A draft using an AEAD method based on SALSA20 that provides misuse resistance of some kind would be more useful, and would be less likely to become obsolete in the near future. Some more minor points below: The draft has no mechanism to allow multiple encrypters to work in parallel, such as is provided in Section 6.2 of RFC5288. Previous AEAD work has chosen to not use the sequence number provided by TLS (and other protocols) because of a lack of assurance that those values will be unique. This draft does use those sequence numbers, which enables its ciphersuites to have less data overhead, but introducing a potential vulnerability through mismanagement of sequence numbers by TLS implementations. Slide 16 shown at IETF87 presents the shorter MAC size as having less data overhead as compared with existing ciphersuites. This is true, but if compactness is a goal, AEAD schemes with less overhead could be used instead. (Some are defined already at [3].) I don't have anything against SALSA20, nor am I the best person to assess its quality as a pseudorandom function. David, speaking as a research group member and not a research group co-chair [1] Gueron, S. AES-GCM for Efficient Authenticated Encryption - Ending the Reign of HMAC-SHA-1? Workshop on Real-World Cryptography, 2013. [2] http://2013.diac.cr.yp.to/ [3] http://hyperelliptic.org/DIAC/slides/DIAC-mcgrew.pdf [4] IANA AEAD Registry, http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml On Thu, 2013-08-08 at 19:45 +0000, Igoe, Kevin M. 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 (draft-josefsson-salsa20-tls-02). This > was presented to the TLS WG at IETF-87, slides can be found at > http://www.ietf.org/proceedings/87/slides/slides-87-tls-2.pdf. > The SALSA family works on blocks of 512 bits, and forms a key stream > in 512-bit blocks by applying a fixed map V^{512}->V^{512} to an input > consisting of the key (either 16 octets or 32 octets), an 8-octet > block counter, an 8-octet IV, and 16 constant octets. > > SALSA20 was one of the five finalists for a software stream cipher in > the eSTREAM contest run by ECRYPTII (see > http://www.ecrypt.eu.org/stream/). > > UMAC has been around since 1999 and is described in RFC 4418. > > POLY1305 first showed up as POLY1305-AES, but all it needs from AES is > a 16 byte block of output. Adapting this to SALSA is straightforward. > The 1305 in the name reflects the fact that it uses arithmetic modulo > 2^{130} – 5. See http://cr.yp.to/mac/poly1305-20050329.pdf > for a description of poly1305-AES. > > Off the top of my head, the only objection I can see is that SALSA may > be difficult to implement efficiently in hardware. Hardware TLS > acceleration can be useful at heavily utilized servers. > > The most current attempt to attack SALSA that I could find is a 2012 > paper on the IACR > e-print server. > > ----------------+-------------------------------------------------- > 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 - > ----------------+-------------------------------------------------- > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From rgm-sec@htt-consult.com Fri Aug 16 04:45:21 2013 Return-Path: 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 1ACAA21F9A81 for ; Fri, 16 Aug 2013 04:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_LETTER=-2, HTML_MESSAGE=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 ok9nBAEYnIyM for ; Fri, 16 Aug 2013 04:45:19 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id A343B21F944C for ; Fri, 16 Aug 2013 04:45:12 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id BA7CA62A77 for ; Fri, 16 Aug 2013 11:45:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXksfx2M0TV2 for ; Fri, 16 Aug 2013 07:44:52 -0400 (EDT) Received: from lx120e2.htt-consult.com (lx120e2.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm-sec@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 88EB562A64 for ; Fri, 16 Aug 2013 07:44:52 -0400 (EDT) Message-ID: <520E10A2.2030908@htt-consult.com> Date: Fri, 16 Aug 2013 07:44:34 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: cfrg@irtf.org References: <32A53FD55709804D8533DD5D308A40A216B2F1A1CC@FHDP1LUMXC7V33.us.one.verizon.com> In-Reply-To: <32A53FD55709804D8533DD5D308A40A216B2F1A1CC@FHDP1LUMXC7V33.us.one.verizon.com> X-Forwarded-Message-Id: <32A53FD55709804D8533DD5D308A40A216B2F1A1CC@FHDP1LUMXC7V33.us.one.verizon.com> Content-Type: multipart/alternative; boundary="------------020101030002090900000406" Subject: [Cfrg] Fwd: Encryption is less secure than we thought - MIT News Office X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 11:45:21 -0000 This is a multi-part message in MIME format. --------------020101030002090900000406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit So what are the thoughts about this here? I have been asked to do a little digging amongst my contacts. Seems it clearly states that our secure communications stuff we do is not affected by this work, but perhaps secure data objects and various wireless password passing technologies might be at risk? -------- Original Message -------- From Evernote: Encryption is less secure than we thought - MIT News Office Clipped from: *http://web.mit.edu/newsoffice/2013/encryption-is-less-secure-than-we-thought-0814.html* Encryption is less secure than we thought For 65 years, most information-theoretic analyses of cryptographic systems have made a mathematical assumption that turns out to be wrong*.* Larry Hardesty, MIT News Office Muriel Médard is a professor in the MIT Department of Electrical Engineering*.* Photo: Bryce Vickmark Information theory — the discipline that gave us digital communication and data compression — also put cryptography on a secure mathematical foundation*.* Since 1948, when the *paper that created information theory * first appeared, most information-theoretic analyses of secure schemes have depended on a common assumption*.* Unfortunately, as a group of researchers at MIT and the National University of Ireland (NUI) at Maynooth, demonstrated in a paper presented at the recent International Symposium on Information Theory (*view PDF * ), that assumption is false*.* In a follow-up paper being presented this fall at the Asilomar Conference on Signals and Systems, the same team shows that, as a consequence, the wireless card readers used in many keyless-entry systems may not be as secure as previously thought*.* In information theory, the concept of information is intimately entwined with that of entropy*.* Two digital files might contain the same amount of information, but if one is shorter, it has more entropy*.* If a compression algorithm — such as WinZip or gzip — worked perfectly, the compressed file would have the maximum possible entropy*.* That means that it would have the same number of 0s and 1s, and the way in which they were distributed would be totally unpredictable*.* In information-theoretic parlance, it would be perfectly uniform*.* Traditionally, information-theoretic analyses of secure schemes have assumed that the source files are perfectly uniform*.* In practice, they rarely are, but they’re close enough that it appeared that the standard mathematical analyses still held*.* “We thought we’d establish that the basic premise that everyone was using was fair and reasonable,” says Ken Duffy, one of the researchers at NUI*.* “And it turns out that it’s not.” On both papers, Duffy is joined by his student Mark Christiansen; Muriel Médard, a professor of electrical engineering at MIT; and her student Flávio du Pin Calmon*.* The problem, Médard explains, is that information-theoretic analyses of secure systems have generally used the wrong notion of entropy*.* They relied on so-called Shannon entropy, named after the founder of information theory, Claude Shannon, who taught at MIT from 1956 to 1978*.* Shannon entropy is based on the average probability that a given string of bits will occur in a particular type of digital file*.* In a general-purpose communications system, that’s the right type of entropy to use, because the characteristics of the data traffic will quickly converge to the statistical averages*.* Although Shannon’s seminal 1948 paper dealt with cryptography, it was primarily concerned with communication, and it used the same measure of entropy in both discussions*.* But in cryptography, the real concern isn’t with the average case but with the worst case*.* A codebreaker needs only one reliable correlation between the encrypted and unencrypted versions of a file in order to begin to deduce further correlations*.* In the years since Shannon’s paper, information theorists have developed other notions of entropy, some of which give greater weight to improbable outcomes*.* Those, it turns out, offer a more accurate picture of the problem of codebreaking*.* When Médard, Duffy and their students used these alternate measures of entropy, they found that slight deviations from perfect uniformity in source files, which seemed trivial in the light of Shannon entropy, suddenly loomed much larger*.* The upshot is that a computer turned loose to simply guess correlations between the encrypted and unencrypted versions of a file would make headway much faster than previously expected*.* “It’s still exponentially hard, but it’s exponentially easier than we thought,” Duffy says*.* One implication is that an attacker who simply relied on the frequencies with which letters occur in English words could probably guess a user-selected password much more quickly than was previously thought*.* “Attackers often use graphics processors to distribute the problem,” Duffy says*.* “You’d be surprised at how quickly you can guess stuff*.*” In their Asilomar paper, the researchers apply the same type of mathematical analysis in a slightly different way*.* They consider the case in which an attacker is, from a distance, able to make a “noisy” measurement of the password stored on a credit card with an embedded chip or a key card used in a keyless-entry system*.* “Noise” is the engineer’s term for anything that degrades an electromagnetic signal — such as physical obstructions, out-of-phase reflections or other electromagnetic interference*.* Noise comes in lots of different varieties: The familiar white noise of sleep aids is one, but so is pink noise, black noise and more exotic-sounding types of noise, such as power-law noise or Poisson noise*.* In this case, rather than prior knowledge about the statistical frequency of the symbols used in a password, the attacker has prior knowledge about the probable noise characteristics of the environment: Phase noise with one set of parameters is more probable than phase noise with another set of parameters, which in turn is more probable than Brownian noise, and so on*.* Armed with these statistics, an attacker could infer the password stored on the card much more rapidly than was previously thought*.* “Some of the approximations that we’re used to making, they make perfect sense in the context of traditional communication,” says Matthieu Bloch, an assistant professor of electrical and computer engineering at the Georgia Institute of Technology*.* “You design your system in a framework, and then you test it*.* But for crypto, you’re actually trying to prove that it’s robust to things you cannot test*.* So you have to be sure that your assumptions make sense from the beginning*.* And I think that going back to the assumptions is something people don’t do often enough*.*” Bloch doubts that the failure of the uniformity assumption means that cryptographic systems in wide use today are fundamentally insecure*.* “My guess is that it will show that some of them are slightly less secure than we had hoped, but usually in the process, we’ll also figure out a way of patching them,” he says*.* The MIT and NUI researchers’ work, he says, “is very constructive, because it’s essentially saying, ‘Hey, we have to be careful*.*’ But it also provides a methodology to go back and reanalyze all these things*.*” Comments *Log in to write comments * ** --------------020101030002090900000406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit So what are the thoughts about this here?  I have been asked to do a little digging amongst my contacts.  Seems it clearly states that our secure communications stuff we do is not affected by this work, but perhaps secure data objects and various wireless password passing technologies might be at risk?


-------- Original Message --------

 


From Evernote:

Encryption is less secure than we thought - MIT News Office

Clipped from: http://web.mit.edu/newsoffice/2013/encryption-is-less-secure-than-we-thought-0814.html

Encryption is less secure than we thought 

For 65 years, most information-theoretic analyses of cryptographic systems have made a mathematical assumption that turns out to be wrong.

Larry Hardesty, MIT News Office


Muriel Médard is a professor in the MIT Department of Electrical Engineering. Photo: Bryce Vickmark

Information theory — the discipline that gave us digital communication and data compression — also put cryptography on a secure mathematical foundation. Since 1948, when the paper that created information theory first appeared, most information-theoretic analyses of secure schemes have depended on a common assumption.

Unfortunately, as a group of researchers at MIT and the National University of Ireland (NUI) at Maynooth, demonstrated in a paper presented at the recent International Symposium on Information Theory (view PDF ), that assumption is false. In a follow-up paper being presented this fall at the Asilomar Conference on Signals and Systems, the same team shows that, as a consequence, the wireless card readers used in many keyless-entry systems may not be as secure as previously thought.

In information theory, the concept of information is intimately entwined with that of entropy. Two digital files might contain the same amount of information, but if one is shorter, it has more entropy. If a compression algorithm — such as WinZip or gzip — worked perfectly, the compressed file would have the maximum possible entropy. That means that it would have the same number of 0s and 1s, and the way in which they were distributed would be totally unpredictable. In information-theoretic parlance, it would be perfectly uniform.

Traditionally, information-theoretic analyses of secure schemes have assumed that the source files are perfectly uniform. In practice, they rarely are, but they’re close enough that it appeared that the standard mathematical analyses still held.

“We thought we’d establish that the basic premise that everyone was using was fair and reasonable,” says Ken Duffy, one of the researchers at NUI. “And it turns out that it’s not.” On both papers, Duffy is joined by his student Mark Christiansen; Muriel Médard, a professor of electrical engineering at MIT; and her student Flávio du Pin Calmon.

The problem, Médard explains, is that information-theoretic analyses of secure systems have generally used the wrong notion of entropy. They relied on so-called Shannon entropy, named after the founder of information theory, Claude Shannon, who taught at MIT from 1956 to 1978.

Shannon entropy is based on the average probability that a given string of bits will occur in a particular type of digital file. In a general-purpose communications system, that’s the right type of entropy to use, because the characteristics of the data traffic will quickly converge to the statistical averages. Although Shannon’s seminal 1948 paper dealt with cryptography, it was primarily concerned with communication, and it used the same measure of entropy in both discussions.

But in cryptography, the real concern isn’t with the average case but with the worst case. A codebreaker needs only one reliable correlation between the encrypted and unencrypted versions of a file in order to begin to deduce further correlations. In the years since Shannon’s paper, information theorists have developed other notions of entropy, some of which give greater weight to improbable outcomes. Those, it turns out, offer a more accurate picture of the problem of codebreaking.

When Médard, Duffy and their students used these alternate measures of entropy, they found that slight deviations from perfect uniformity in source files, which seemed trivial in the light of Shannon entropy, suddenly loomed much larger. The upshot is that a computer turned loose to simply guess correlations between the encrypted and unencrypted versions of a file would make headway much faster than previously expected.

“It’s still exponentially hard, but it’s exponentially easier than we thought,” Duffy says. One implication is that an attacker who simply relied on the frequencies with which letters occur in English words could probably guess a user-selected password much more quickly than was previously thought. “Attackers often use graphics processors to distribute the problem,” Duffy says. “You’d be surprised at how quickly you can guess stuff.

In their Asilomar paper, the researchers apply the same type of mathematical analysis in a slightly different way. They consider the case in which an attacker is, from a distance, able to make a “noisy” measurement of the password stored on a credit card with an embedded chip or a key card used in a keyless-entry system.

“Noise” is the engineer’s term for anything that degrades an electromagnetic signal — such as physical obstructions, out-of-phase reflections or other electromagnetic interference. Noise comes in lots of different varieties: The familiar white noise of sleep aids is one, but so is pink noise, black noise and more exotic-sounding types of noise, such as power-law noise or Poisson noise.

In this case, rather than prior knowledge about the statistical frequency of the symbols used in a password, the attacker has prior knowledge about the probable noise characteristics of the environment: Phase noise with one set of parameters is more probable than phase noise with another set of parameters, which in turn is more probable than Brownian noise, and so on. Armed with these statistics, an attacker could infer the password stored on the card much more rapidly than was previously thought.

“Some of the approximations that we’re used to making, they make perfect sense in the context of traditional communication,” says Matthieu Bloch, an assistant professor of electrical and computer engineering at the Georgia Institute of Technology. “You design your system in a framework, and then you test it. But for crypto, you’re actually trying to prove that it’s robust to things you cannot test. So you have to be sure that your assumptions make sense from the beginning. And I think that going back to the assumptions is something people don’t do often enough.

Bloch doubts that the failure of the uniformity assumption means that cryptographic systems in wide use today are fundamentally insecure. “My guess is that it will show that some of them are slightly less secure than we had hoped, but usually in the process, we’ll also figure out a way of patching them,” he says. The MIT and NUI researchers’ work, he says, “is very constructive, because it’s essentially saying, ‘Hey, we have to be careful.’ But it also provides a methodology to go back and reanalyze all these things.

 



--------------020101030002090900000406-- From benlaurie@gmail.com Fri Aug 16 05:35:30 2013 Return-Path: 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 8E5D221F9ADF for ; Fri, 16 Aug 2013 05:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-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 uP83FkP6d7Aq for ; Fri, 16 Aug 2013 05:35:26 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 38DB921F9798 for ; Fri, 16 Aug 2013 05:35:23 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id l18so445968qak.4 for ; Fri, 16 Aug 2013 05:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mk3ZGT2LfixtkGD3m8+ub5F/VkQzwO7hIw8IUnKdOjE=; b=vR9Ok+9THw6q2+eTooCUf9hBlz120GRraJTe+Pqv8HF9YXZkwDSPCSURr1p74/nj1q jWR+xCQ2ePNHZP9ZZ4b8mErPViEewaxTajPKds2H7T4bxfGg+M5NgfQFMDZoGSnpSCFP XxJ+eMNjlJ8CjbkTP5ZIVjpWFr14qo1b4NDERbz0NBmKjaW3dkhJU6weV1vt5LiYWCCw J9Qa6lr4t3IC3lktMlStyYNobbkUTfPdw1GuZEuQkIJ3jWlv+VYhQPL6Gf/RwT+fKui1 Va+Nx9L2neqnuIftNx37Wa+mRXfVVvgjeuHBe9GpeCbMdr8hpZimHaGneK/BC1vpe3Lv QzHw== MIME-Version: 1.0 X-Received: by 10.224.80.9 with SMTP id r9mr1011045qak.89.1376656522642; Fri, 16 Aug 2013 05:35:22 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.4.227 with HTTP; Fri, 16 Aug 2013 05:35:22 -0700 (PDT) In-Reply-To: <520E10A2.2030908@htt-consult.com> References: <32A53FD55709804D8533DD5D308A40A216B2F1A1CC@FHDP1LUMXC7V33.us.one.verizon.com> <520E10A2.2030908@htt-consult.com> Date: Fri, 16 Aug 2013 08:35:22 -0400 X-Google-Sender-Auth: FCLQ8W62SKKFbXjbCq1cjYpRfTI Message-ID: From: Ben Laurie To: Robert Moskowitz Content-Type: multipart/alternative; boundary=001a11c2b9ea02a42e04e40fd376 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Fwd: Encryption is less secure than we thought - MIT News Office X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 12:35:30 -0000 --001a11c2b9ea02a42e04e40fd376 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 16 August 2013 07:44, Robert Moskowitz wrote: > So what are the thoughts about this here? I have been asked to do a > little digging amongst my contacts. Seems it clearly states that our > secure communications stuff we do is not affected by this work, but perha= ps > secure data objects and various wireless password passing technologies > might be at risk? > This seems to be restating essentially what Joe Bonneau said far more readably a year ago: http://www.jbonneau.com/doc/B12-IEEESP-analyzing_70M_anonymized_passwords.p= df . > > > -------- Original Message -------- > > ** ** > > From Evernote: **** Encryption is less secure > than we thought - MIT News Office**** > > Clipped from: * > http://web.mit.edu/newsoffice/2013/encryption-is-less-secure-than-we-thou= ght-0814.html > * > **** > Encryption is less secure than we thought **** > > For 65 years, most information-theoretic analyses of cryptographic system= s > have made a mathematical assumption that turns out to be wrong*.***** > > Larry Hardesty, MIT News Office**** > > > **** > > Muriel M=E9dard is a professor in the MIT Department of Electrical > Engineering*.* Photo: Bryce Vickmark **** > > Information theory =97 the discipline that gave us digital communication = and > data compression =97 also put cryptography on a secure mathematical found= ation > *.* Since 1948, when the *paper that created information theory *first > appeared, most information-theoretic analyses of secure schemes have > depended on a common assumption*.* > > Unfortunately, as a group of researchers at MIT and the National > University of Ireland (NUI) at Maynooth, demonstrated in a paper presente= d > at the recent International Symposium on Information Theory (*view PDF *<= http://arxiv.org/pdf/1301.6356.pdf>), > that assumption is false*.* In a follow-up paper being presented this > fall at the Asilomar Conference on Signals and Systems, the same team sho= ws > that, as a consequence, the wireless card readers used in many > keyless-entry systems may not be as secure as previously thought*.* > > In information theory, the concept of information is intimately entwined > with that of entropy*.* Two digital files might contain the same amount > of information, but if one is shorter, it has more entropy*.* If a > compression algorithm =97 such as WinZip or gzip =97 worked perfectly, th= e > compressed file would have the maximum possible entropy*.* That means > that it would have the same number of 0s and 1s, and the way in which the= y > were distributed would be totally unpredictable*.* In > information-theoretic parlance, it would be perfectly uniform*.* > > Traditionally, information-theoretic analyses of secure schemes have > assumed that the source files are perfectly uniform*.* In practice, they > rarely are, but they=92re close enough that it appeared that the standard > mathematical analyses still held*.* > > =93We thought we=92d establish that the basic premise that everyone was u= sing > was fair and reasonable,=94 says Ken Duffy, one of the researchers at NUI= *.*=93And it turns out that it=92s not.=94 On both papers, Duffy is joined = by his > student Mark Christiansen; Muriel M=E9dard, a professor of electrical > engineering at MIT; and her student Fl=E1vio du Pin Calmon*.* > > The problem, M=E9dard explains, is that information-theoretic analyses of > secure systems have generally used the wrong notion of entropy*.* They > relied on so-called Shannon entropy, named after the founder of informati= on > theory, Claude Shannon, who taught at MIT from 1956 to 1978*.* > > Shannon entropy is based on the average probability that a given string o= f > bits will occur in a particular type of digital file*.* In a > general-purpose communications system, that=92s the right type of entropy= to > use, because the characteristics of the data traffic will quickly converg= e > to the statistical averages*.* Although Shannon=92s seminal 1948 paper > dealt with cryptography, it was primarily concerned with communication, a= nd > it used the same measure of entropy in both discussions*.* > > But in cryptography, the real concern isn=92t with the average case but w= ith > the worst case*.* A codebreaker needs only one reliable correlation > between the encrypted and unencrypted versions of a file in order to begi= n > to deduce further correlations*.* In the years since Shannon=92s paper, > information theorists have developed other notions of entropy, some of > which give greater weight to improbable outcomes*.* Those, it turns out, > offer a more accurate picture of the problem of codebreaking*.* > > When M=E9dard, Duffy and their students used these alternate measures of > entropy, they found that slight deviations from perfect uniformity in > source files, which seemed trivial in the light of Shannon entropy, > suddenly loomed much larger*.* The upshot is that a computer turned loose > to simply guess correlations between the encrypted and unencrypted versio= ns > of a file would make headway much faster than previously expected*.* > > =93It=92s still exponentially hard, but it=92s exponentially easier than = we > thought,=94 Duffy says*.* One implication is that an attacker who simply > relied on the frequencies with which letters occur in English words could > probably guess a user-selected password much more quickly than was > previously thought*.* =93Attackers often use graphics processors to > distribute the problem,=94 Duffy says*.* =93You=92d be surprised at how q= uickly > you can guess stuff*.*=94 > > In their Asilomar paper, the researchers apply the same type of > mathematical analysis in a slightly different way*.* They consider the > case in which an attacker is, from a distance, able to make a =93noisy=94 > measurement of the password stored on a credit card with an embedded chip > or a key card used in a keyless-entry system*.* > > =93Noise=94 is the engineer=92s term for anything that degrades an > electromagnetic signal =97 such as physical obstructions, out-of-phase > reflections or other electromagnetic interference*.* Noise comes in lots > of different varieties: The familiar white noise of sleep aids is one, bu= t > so is pink noise, black noise and more exotic-sounding types of noise, su= ch > as power-law noise or Poisson noise*.* > > In this case, rather than prior knowledge about the statistical frequency > of the symbols used in a password, the attacker has prior knowledge about > the probable noise characteristics of the environment: Phase noise with o= ne > set of parameters is more probable than phase noise with another set of > parameters, which in turn is more probable than Brownian noise, and so on= * > .* Armed with these statistics, an attacker could infer the password > stored on the card much more rapidly than was previously thought*.* > > =93Some of the approximations that we=92re used to making, they make perf= ect > sense in the context of traditional communication,=94 says Matthieu Bloch= , an > assistant professor of electrical and computer engineering at the Georgia > Institute of Technology*.* =93You design your system in a framework, and > then you test it*.* But for crypto, you=92re actually trying to prove tha= t > it=92s robust to things you cannot test*.* So you have to be sure that yo= ur > assumptions make sense from the beginning*.* And I think that going back > to the assumptions is something people don=92t do often enough*.*=94 > > Bloch doubts that the failure of the uniformity assumption means that > cryptographic systems in wide use today are fundamentally insecure*.* =93= My > guess is that it will show that some of them are slightly less secure tha= n > we had hoped, but usually in the process, we=92ll also figure out a way o= f > patching them,=94 he says*.* The MIT and NUI researchers=92 work, he says= , > =93is very constructive, because it=92s essentially saying, =91Hey, we ha= ve to be > careful*.*=92 But it also provides a methodology to go back and reanalyze > all these things*.*=94 **** > > Comments**** > > *Log in to write comments * > **** > > * ***** > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > --001a11c2b9ea02a42e04e40fd376 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On 16 August 2013 07:44, Robert Moskowitz <rgm-sec@htt-consu= lt.com> wrote:
=20 =20 =20
So what are the thoughts about this here?=A0 I have been asked to do a little digging amongst my contacts.=A0 Seems it clearly states that our secure communications stuff we do is not affected by this work, but perhaps secure data objects and various wireless password passing technologies might be at risk?

<= /div>
This seems to be restating essentially what Joe Bonneau said far = more readably a year ago: http://www.jbonneau.com/doc/B12-IE= EESP-analyzing_70M_anonymized_passwords.pdf.
=A0


-------- Original Message --------

=20 =20 =20 =20

=A0


From Evernote:

Encryption is less secure than we thought - MIT News Office=

Clipped from: http= ://web.mit.edu/newsoffice/2013/encryption-is-less-secure-than-we-thought-08= 14.html

Encryption is less secure than we thought=A0

For 65 years, most information-theoretic analyses of cryptographic systems have made a mathematical assumption that turns out to be wrong.<= u>

Larry Hardesty, MIT News Office


Muriel M=E9dard is a professor in the MIT Department of Electrical Engineering. Photo: Bryce Vickmark

Information theory =97 the discipline that gave us digital communication and data compression =97 also put cryptography on a secure mathematical foundation. Since 1948, when the paper that created information theory first appeared, most information-theoretic analyses of secure schemes have depended on a common assumption.

Unfortunately, as a group of researchers at MIT and the National University of Ireland (NUI) at Maynooth, demonstrated in a paper presented at the recent International Symposium on Information Theory (view PDF ), tha= t assumption is false. In a follow-up paper being presented this fall at the Asilomar Conference on Signals and Systems, the same team shows that, as a consequence, the wireless card readers used in many keyless-entry systems may not be as secure as previously thought.

In information theory, the concept of information is intimately entwined with that of entropy. Two digital files might contain the same amount of information, but if one is shorter, it has more entropy. If a compression algorithm =97 such as WinZip or gzip =97 worked perfectly, the compressed file would have the maximum possible entropy. That means that it would have the same number of 0s and 1s, and the way in which they were distributed would be totally unpredictable. In information-theoretic parlance, it would be perfectly uniform.

Traditionally, information-theoretic analyses of secure schemes have assumed that the source files are perfectly uniform. In practice, they rarely are, but they=92re close enough that it appeared that the standard mathematical analyses still held.

=93We thought we=92d establish that the basic premise that everyone was using was fair and reasonable,=94 says Ken Duffy, one of the researchers at NUI. =93And it turns out that it=92s not.=94 On both papers, Duffy is joined by his student Mark Christiansen; Muriel M=E9dard, a professor of electrical engineering at MIT; and her student Fl=E1vio du Pin Calmon.

The problem, M=E9dard explains, is that information-theoretic analyses of secure systems have generally used the wrong notion of entropy. They relied on so-called Shannon entropy, named after the founder of information theory, Claude Shannon, who taught at MIT from 1956 to 1978.

Shannon entropy is based on the average probability that a given string of bits will occur in a particular type of digital file. In a general-purpose communications system, that=92s the right type of entropy to use, because the characteristics of the data traffic will quickly converge to the statistical averages. Although Shannon=92s seminal 1948 paper dealt with cryptography, it was primarily concerned with communication, and it used the same measure of entropy in both discussions.<= /span>

But in cryptography, the real concern isn=92t with the average case but with the worst case. A codebreaker needs only one reliable correlation between the encrypted and unencrypted versions of a file in order to begin to deduce further correlations. In the years since Shannon=92s paper, information theorists have developed other notions of entropy, some of which give greater weight to improbable outcomes. Those, it turns out, offer a more accurate picture of the problem of codebreaking.<= /span>

When M=E9dard, Duffy and their students used these alternate measures of entropy, they found that slight deviations from perfect uniformity in source files, which seemed trivial in the light of Shannon entropy, suddenly loomed much larger. The upshot is that a computer turned loose to simply guess correlations between the encrypted and unencrypted versions of a file would make headway much faster than previously expected.

=93It=92s still exponentially hard, but it=92s exponentially easier than we thought,=94 Duffy says. One implication is that an attacker who simply relied on the frequencies with which letters occur in English words could probably guess a user-selected password much more quickly than was previously thought. =93Attackers often use graphics processors to distribute the problem,=94 Duffy says. =93You=92d be surprised at how quickly you can guess stuff.=94

In their Asilomar paper, the researchers apply the same type of mathematical analysis in a slightly different way. They consider the case in which an attacker is, from a distance, able to make a =93noisy=94 measurement of the password stored on a credit card with an embedded chip or a key card used in a keyless-entry system.

=93Noise=94 is the engineer=92s term for anything that degrades an electromagnetic signal =97 such as physical obstructions, out-of-phase reflections or other electromagnetic interference. Noise comes in lots of different varieties: The familiar white noise of sleep aids is one, but so is pink noise, black noise and more exotic-sounding types of noise, such as power-law noise or Poisson noise.

In this case, rather than prior knowledge about the statistical frequency of the symbols used in a password, the attacker has prior knowledge about the probable noise characteristics of the environment: Phase noise with one set of parameters is more probable than phase noise with another set of parameters, which in turn is more probable than Brownian noise, and so on. Armed with these statistics, an attacker could infer the password stored on the card much more rapidly than was previously thought.

=93Some of the approximations that we=92re used t= o making, they make perfect sense in the context of traditional communication,=94 says Matthieu Bloch, an assistant professor of electrical and computer engineering at the Georgia Institute of Technology. =93You design your system in a framework, and then you test it. But for crypto, you=92re actually trying to prove that it=92s robust to things you cannot test. So you have to be sure that your assumptions make sense from the beginning. And I think that going back to the assumptions is something people don=92t do often enough.=94

Bloch doubts that the failure of the uniformity assumption means that cryptographic systems in wide use today are fundamentally insecure. =93My guess is that it will show that some of them are slightly less secure than we had hoped, but usually in the process, we=92ll also figure out a way of patching them,=94 he says. The MIT and NUI researchers=92 work, he says, =93is very constructive, because it=92s essentially saying, =91Hey, we have to be careful.=92 But it also provides a methodology to go back and reanalyze all these things.=94 <= /u>

Comments


=A0=




_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
htt= p://www.irtf.org/mailman/listinfo/cfrg


--001a11c2b9ea02a42e04e40fd376-- From dbrown@certicom.com Fri Aug 16 08:38:40 2013 Return-Path: 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 1712211E8119 for ; Fri, 16 Aug 2013 08:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 UTFrte2n7pci for ; Fri, 16 Aug 2013 08:38:34 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4A411E8155 for ; Fri, 16 Aug 2013 08:38:30 -0700 (PDT) X-AuditID: 0a41282f-b7f8b6d000004656-40-520e476f99fb Received: from XCT103CNC.rim.net (smtp-pop.rim.net [10.65.161.203]) by mhs060cnc.rim.net (SBG) with SMTP id 9B.18.18006.F674E025; Fri, 16 Aug 2013 10:38:23 -0500 (CDT) Received: from XCT104CNC.rim.net (10.65.161.204) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 16 Aug 2013 11:38:22 -0400 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Fri, 16 Aug 2013 11:38:22 -0400 From: Dan Brown To: "'ben@links.org'" , "'rgm-sec@htt-consult.com'" Thread-Topic: [Cfrg] Fwd: Encryption is less secure than we thought - MIT News Office Thread-Index: AQHOmn0aBVGzTxgTP02h2SMzK0sRUZmX5wWg Date: Fri, 16 Aug 2013 15:38:22 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF51DC548@XMB111CNC.rim.net> References: <32A53FD55709804D8533DD5D308A40A216B2F1A1CC@FHDP1LUMXC7V33.us.one.verizon.com> <520E10A2.2030908@htt-consult.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CE9A75.1C2C27B0" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLsWRmVeSWpSXmKPExsXC5bjwtG6+O1+QQf8GdYtFszktun8cZLI4 +ifIgdlj96Qmdo/JGw+zeWxumsMWwBwlYpOSmpNZllqkb4dgJYhkfJg8i7Xg4V6miktH+pka GOfMZOpi5OSQEDCRWLLoPSuELSZx4d56ti5GLg4hgZWMEt333zPBOW13nkJl5jBKfNl2jB2k hU1AVeL+0XPMILaIQJzEwcZ2NhCbGSg+a8kfRhBbWCBMonHhYqB6DqCacIl/M0Ugyo0kdnQt B2tlASrv6P4IdhGvgJvEhE9/oXYdY5T4uP0a2ExOgUCJNTcbwPYyAp36/dQaJohd4hK3nsyH ekdE4uHF02wQtqjEy8f/oF5TlHh2Zyk7yFBmgV5GiQnLVrJBbBOUODnzCQuILSSgIHHl+j6W CYzis5DMnYWsZxaSHoiiaIn+xyvYIGwDifuHOlghbG2JZQtfM0PY+hJtx1YzY4rbSuy/uhLK VpSY0v2QHcI2lXh99CPjAkbuVYyCuRnFBmYGyXnJekWZuXp5qSWbGMFpQkN/B+Pb9xaHGAU4 GJV4eN11+YKEWBPLiitzDzGqAM14tGH1BUYplrz8vFQlEd6tBkBp3pTEyqrUovz4otKc1OJD jLuZgCE/kVmKOzkfmNzySuKNDQwo54jCOIZGluaGlmbGZqYmhmZDVVhJnNdV5UOgkEB6Yklq dmpqQWoRLPiYODilGhh71HK33wjvYrW88nbzDz9XD+WPf4KniUxaeHbOth8Kz/deDO6eo9o1 V+6/zXwxffmaBdELg/dYinKcLrPRN772pbZYqzJIZ13Jqhd9rvlWWQ8e3p154tf2hZ/Fed5O WvCw3uq1k96EG6aqd7myrnHoHogt8nrp63H6a9WuGavrWqWuJ1Zs379FiaU4I9FQi7moOBEA VvEEDjwEAAA= Cc: "'cfrg@irtf.org'" Subject: Re: [Cfrg] Fwd: Encryption is less secure than we thought - MIT News Office X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 15:38:40 -0000 ------=_NextPart_000_0000_01CE9A75.1C2C27B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01CE9A75.1C441C80" ------=_NextPart_001_0001_01CE9A75.1C441C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cryptographers on this list, and cryptographic implementers in general, should be aware of at least NIST SP 800-90{A,B,C}. =20 I agree with the article(s) that=20 =20 a) parts of industry pay inadequate attention to the randomness on which keys rely. Some examples are failed RNGs leading to security vulnerabilities are well known. b) assumptions about uniform distribution of keys, e.g. provable = security is common (but I view this as forgivable from the standpoint of modular = design) c) the common perpetuation of the misconception to use Shannon entropy = for crypto may have contributed, or risk contributing, to overestimates of entropy =20 I am baffled by (or else misunderstand) the news article stating that cryptographers assume that content files are assumed to be perfectly. I never came across such an assumption: often encryption papers assume = that the plaintext is highly biased, and intended to work properly under a = biased message, and uniform key. =20 The problem of true randomness is difficult, both philosophically and technically. Many have written on the subject, including me: http://eprint.iacr.org/2011/659 =20 I disagree with the below-cited arXiv article=92s use of expected = guesswork: see Remark 3.15 of my own eprint above. =20 Best regards, =20 Dan =20 =20 =20 From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of = Ben Laurie Sent: Friday, August 16, 2013 8:35 AM To: Robert Moskowitz Cc: cfrg@irtf.org Subject: Re: [Cfrg] Fwd: Encryption is less secure than we thought - MIT News Office =20 =20 =20 On 16 August 2013 07:44, Robert Moskowitz = wrote: So what are the thoughts about this here? I have been asked to do a = little digging amongst my contacts. Seems it clearly states that our secure communications stuff we do is not affected by this work, but perhaps = secure data objects and various wireless password passing technologies might be = at risk? =20 This seems to be restating essentially what Joe Bonneau said far more readably a year ago: http://www.jbonneau.com/doc/B12-IEEESP-analyzing_70M_anonymized_passwords= .pd f. =20 -------- Original Message -------- =20 =20 >From Evernote: =20 Encryption is less secure than we thought - MIT News Office Clipped from: http://web.mit.edu/newsoffice/2013/encryption-is-less-secure-than-we-thou= ght -0814.html=20 Encryption is less secure than we thought=20 For 65 years, most information-theoretic analyses of cryptographic = systems have made a mathematical assumption that turns out to be wrong. Larry Hardesty, MIT News Office =20 Muriel M=E9dard is a professor in the MIT Department of Electrical Engineering. Photo: Bryce Vickmark=20 Information theory =97 the discipline that gave us digital communication = and data compression =97 also put cryptography on a secure mathematical foundation. Since 1948, when the paper = that created information theory first appeared, most information-theoretic analyses of secure schemes have depended on a common assumption. Unfortunately, as a group of researchers at MIT and the National = University of Ireland (NUI) at Maynooth, demonstrated in a paper presented at the recent International Symposium on Information Theory ( view PDF ), that assumption is = false. In a follow-up paper being presented this fall at the Asilomar = Conference on Signals and Systems, the same team shows that, as a consequence, the wireless card readers used in many keyless-entry systems may not be as secure as previously thought. In information theory, the concept of information is intimately entwined with that of entropy. Two digital files might contain the same amount of information, but if one is shorter, it has more entropy. If a = compression algorithm =97 such as WinZip or gzip =97 worked perfectly, the = compressed file would have the maximum possible entropy. That means that it would have = the same number of 0s and 1s, and the way in which they were distributed = would be totally unpredictable. In information-theoretic parlance, it would be perfectly uniform. Traditionally, information-theoretic analyses of secure schemes have = assumed that the source files are perfectly uniform. In practice, they rarely = are, but they=92re close enough that it appeared that the standard = mathematical analyses still held. =93We thought we=92d establish that the basic premise that everyone was = using was fair and reasonable,=94 says Ken Duffy, one of the researchers at = NUI. =93And it turns out that it=92s not.=94 On both papers, Duffy is joined = by his student Mark Christiansen; Muriel M=E9dard, a professor of electrical engineering at MIT; and her student Fl=E1vio du Pin Calmon. The problem, M=E9dard explains, is that information-theoretic analyses = of secure systems have generally used the wrong notion of entropy. They = relied on so-called Shannon entropy, named after the founder of information = theory, Claude Shannon, who taught at MIT from 1956 to 1978. Shannon entropy is based on the average probability that a given string = of bits will occur in a particular type of digital file. In a = general-purpose communications system, that=92s the right type of entropy to use, = because the characteristics of the data traffic will quickly converge to the = statistical averages. Although Shannon=92s seminal 1948 paper dealt with = cryptography, it was primarily concerned with communication, and it used the same measure = of entropy in both discussions. But in cryptography, the real concern isn=92t with the average case but = with the worst case. A codebreaker needs only one reliable correlation = between the encrypted and unencrypted versions of a file in order to begin to = deduce further correlations. In the years since Shannon=92s paper, information theorists have developed other notions of entropy, some of which give greater weight to improbable outcomes. Those, it turns out, offer a more accurate picture of the problem of codebreaking. When M=E9dard, Duffy and their students used these alternate measures of entropy, they found that slight deviations from perfect uniformity in = source files, which seemed trivial in the light of Shannon entropy, suddenly = loomed much larger. The upshot is that a computer turned loose to simply guess correlations between the encrypted and unencrypted versions of a file = would make headway much faster than previously expected. =93It=92s still exponentially hard, but it=92s exponentially easier than = we thought,=94 Duffy says. One implication is that an attacker who simply = relied on the frequencies with which letters occur in English words could = probably guess a user-selected password much more quickly than was previously thought. =93Attackers often use graphics processors to distribute the problem,=94 Duffy says. =93You=92d be surprised at how quickly you can = guess stuff.=94 In their Asilomar paper, the researchers apply the same type of = mathematical analysis in a slightly different way. They consider the case in which an attacker is, from a distance, able to make a =93noisy=94 measurement of = the password stored on a credit card with an embedded chip or a key card = used in a keyless-entry system.=20 =93Noise=94 is the engineer=92s term for anything that degrades an = electromagnetic signal =97 such as physical obstructions, out-of-phase reflections or = other electromagnetic interference. Noise comes in lots of different = varieties: The familiar white noise of sleep aids is one, but so is pink noise, = black noise and more exotic-sounding types of noise, such as power-law noise = or Poisson noise. In this case, rather than prior knowledge about the statistical = frequency of the symbols used in a password, the attacker has prior knowledge about = the probable noise characteristics of the environment: Phase noise with one = set of parameters is more probable than phase noise with another set of parameters, which in turn is more probable than Brownian noise, and so = on. Armed with these statistics, an attacker could infer the password stored = on the card much more rapidly than was previously thought. =93Some of the approximations that we=92re used to making, they make = perfect sense in the context of traditional communication,=94 says Matthieu = Bloch, an assistant professor of electrical and computer engineering at the = Georgia Institute of Technology. =93You design your system in a framework, and = then you test it. But for crypto, you=92re actually trying to prove that = it=92s robust to things you cannot test. So you have to be sure that your assumptions make sense from the beginning. And I think that going back = to the assumptions is something people don=92t do often enough.=94 Bloch doubts that the failure of the uniformity assumption means that cryptographic systems in wide use today are fundamentally insecure. = =93My guess is that it will show that some of them are slightly less secure = than we had hoped, but usually in the process, we=92ll also figure out a way = of patching them,=94 he says. The MIT and NUI researchers=92 work, he says, = =93is very constructive, because it=92s essentially saying, =91Hey, we have to = be careful.=92 But it also provides a methodology to go back and reanalyze = all these things.=94=20 Comments =09 = Log in to write comments=20 =20 =20 =20 _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg =20 ------=_NextPart_001_0001_01CE9A75.1C441C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Cryptographers on this list, and cryptographic implementers in = general, should be aware of at least NIST SP = 800-90{A,B,C}.

 

I agree with the article(s) that

 

a) parts of industry pay inadequate attention to the randomness on = which keys rely.=A0 Some examples are failed RNGs leading to security = vulnerabilities are well known.

b) assumptions about uniform distribution of keys, e.g. provable = security is common (but I view this as forgivable from the standpoint of = modular design)

c) the common perpetuation of the misconception to use Shannon = entropy for crypto may have contributed, or risk contributing, to = overestimates of entropy

 

I am baffled by (or else misunderstand) the news article stating that = cryptographers assume that content files are assumed to be perfectly.=A0 = I never came across such an assumption: often encryption papers assume = that the plaintext is highly biased, and intended to work properly under = a biased message, and uniform key.

 

The problem of true randomness is difficult, both philosophically and = technically.=A0 Many have written on the subject, including me: http://eprint.iacr.org/2011/659<= /a>

 

I disagree with the below-cited arXiv article’s use of expected = guesswork: see Remark 3.15 of my own eprint = above.

 

Best regards,

 

Dan

 

 

 

 

 

 

On 16 August 2013 07:44, Robert Moskowitz <rgm-sec@htt-consult.com> = wrote:

So what are the thoughts = about this here?  I have been asked to do a little digging amongst = my contacts.  Seems it clearly states that our secure = communications stuff we do is not affected by this work, but perhaps = secure data objects and various wireless password passing technologies = might be at risk?

 

This seems to be restating essentially what Joe = Bonneau said far more readably a year ago: http://www.jbonneau.com/doc/B12-IEEESP-analyzing_70M_anonym= ized_passwords.pdf.

 



-------- Original Message = --------

 

 

From = Evernote:

Encryption is less secure than = we thought - MIT News Office

Clipped from: http://web.mit.edu/newsoffice/2013/encryption-is-les= s-secure-than-we-thought-0814.html =

Encryption is = less secure than we thought 

= For 65 years, most information-theoretic analyses of cryptographic = systems have made a mathematical assumption that turns out to be = wrong.

= Larry Hardesty, MIT News = Office

 <= /o:p>

= Muriel M=E9dard is a professor in the MIT Department of Electrical = Engineering. Photo: Bryce Vickmark

= Information theory — the discipline that gave us digital = communication and data compression — also put cryptography on a = secure mathematical foundation. Since 1948, when the paper that created information theory first = appeared, most information-theoretic analyses of secure schemes have = depended on a common assumption.

Unfortunately, as a group = of researchers at MIT and the National University of Ireland (NUI) at = Maynooth, demonstrated in a paper presented at the recent International = Symposium on Information Theory (view = PDF ), that assumption is false. In a follow-up paper = being presented this fall at the Asilomar Conference on Signals and = Systems, the same team shows that, as a consequence, the wireless card = readers used in many keyless-entry systems may not be as secure as = previously thought.

In information theory, the concept of = information is intimately entwined with that of entropy. Two = digital files might contain the same amount of information, but if one = is shorter, it has more entropy. If a compression algorithm = — such as WinZip or gzip — worked perfectly, the compressed = file would have the maximum possible entropy. That means that it = would have the same number of 0s and 1s, and the way in which they were = distributed would be totally unpredictable. In = information-theoretic parlance, it would be perfectly = uniform.

Traditionally, information-theoretic analyses of = secure schemes have assumed that the source files are perfectly = uniform. In practice, they rarely are, but they’re close = enough that it appeared that the standard mathematical analyses still = held.

“We thought we’d establish that the = basic premise that everyone was using was fair and reasonable,” = says Ken Duffy, one of the researchers at NUI. “And it = turns out that it’s not.” On both papers, Duffy is joined by = his student Mark Christiansen; Muriel M=E9dard, a professor of = electrical engineering at MIT; and her student Fl=E1vio du Pin = Calmon.

The problem, M=E9dard explains, is that = information-theoretic analyses of secure systems have generally used the = wrong notion of entropy. They relied on so-called Shannon = entropy, named after the founder of information theory, Claude Shannon, = who taught at MIT from 1956 to 1978.

Shannon entropy is based on the average = probability that a given string of bits will occur in a particular type = of digital file. In a general-purpose communications system, = that’s the right type of entropy to use, because the = characteristics of the data traffic will quickly converge to the = statistical averages. Although Shannon’s seminal 1948 paper = dealt with cryptography, it was primarily concerned with communication, = and it used the same measure of entropy in both = discussions.

But = in cryptography, the real concern isn’t with the average case but = with the worst case. A codebreaker needs only one reliable = correlation between the encrypted and unencrypted versions of a file in = order to begin to deduce further correlations. In the years since = Shannon’s paper, information theorists have developed other = notions of entropy, some of which give greater weight to improbable = outcomes. Those, it turns out, offer a more accurate picture of = the problem of codebreaking.

When M=E9dard, Duffy and their students = used these alternate measures of entropy, they found that slight = deviations from perfect uniformity in source files, which seemed trivial = in the light of Shannon entropy, suddenly loomed much larger. The = upshot is that a computer turned loose to simply guess correlations = between the encrypted and unencrypted versions of a file would make = headway much faster than previously expected.

“It’s still exponentially hard, = but it’s exponentially easier than we thought,” Duffy = says. One implication is that an attacker who simply relied on = the frequencies with which letters occur in English words could probably = guess a user-selected password much more quickly than was previously = thought. “Attackers often use graphics processors to = distribute the problem,” Duffy says. “You’d be = surprised at how quickly you can guess = stuff.

In their Asilomar paper, the = researchers apply the same type of mathematical analysis in a slightly = different way. They consider the case in which an attacker is, = from a distance, able to make a “noisy” measurement of the = password stored on a credit card with an embedded chip or a key card = used in a keyless-entry system.

“Noise” is = the engineer’s term for anything that degrades an electromagnetic = signal — such as physical obstructions, out-of-phase reflections = or other electromagnetic interference. Noise comes in lots of = different varieties: The familiar white noise of sleep aids is one, but = so is pink noise, black noise and more exotic-sounding types of noise, = such as power-law noise or Poisson noise.

In this case, = rather than prior knowledge about the statistical frequency of the = symbols used in a password, the attacker has prior knowledge about the = probable noise characteristics of the environment: Phase noise with one = set of parameters is more probable than phase noise with another set of = parameters, which in turn is more probable than Brownian noise, and so = on. Armed with these statistics, an attacker could infer the = password stored on the card much more rapidly than was previously = thought.

“Some of the approximations that = we’re used to making, they make perfect sense in the context of = traditional communication,” says Matthieu Bloch, an assistant = professor of electrical and computer engineering at the Georgia = Institute of Technology. “You design your system in a = framework, and then you test it. But for crypto, you’re = actually trying to prove that it’s robust to things you cannot = test. So you have to be sure that your assumptions make sense = from the beginning. And I think that going back to the = assumptions is something people don’t do often = enough.

Bloch doubts that the failure of the = uniformity assumption means that cryptographic systems in wide use today = are fundamentally insecure. “My guess is that it will show = that some of them are slightly less secure than we had hoped, but = usually in the process, we’ll also figure out a way of patching = them,” he says. The MIT and NUI researchers’ work, he = says, “is very constructive, because it’s essentially = saying, ‘Hey, we have to be careful.’ But it also = provides a methodology to go back and reanalyze all these = things.

=  

 

 


______________________________________= _________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

 

------=_NextPart_001_0001_01CE9A75.1C441C80-- ------=_NextPart_000_0000_01CE9A75.1C2C27B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6 xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2 6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0 KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODE2 MTUzODIxWjAjBgkqhkiG9w0BCQQxFgQUqSe7V6pAHf/sUbSXFtKkMElQwf8wZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgDdkUYUj3ykf ontrr/lYnlIvy8nMWlHac8SEgcGHLDQoLV6bnpW8LGdbstlN3HgcZd9hRqNbhVGh9OAwIHPz6VFG aGYpCalfW3Wq2n9XC9OOzmn1YGCuneFQWZKalB4/OpZ+V4eHYXu5oVof7q/riaZQW6Dsv0gch8Y7 qpr7A1HIAAAAAAAA ------=_NextPart_000_0000_01CE9A75.1C2C27B0-- From dmjacobson@sbcglobal.net Sat Aug 17 17:37:51 2013 Return-Path: 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 E3AA411E815C for ; Sat, 17 Aug 2013 17:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.109 X-Spam-Level: X-Spam-Status: No, score=-3.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, GB_I_LETTER=-2, HTML_MESSAGE=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 513DSZ2UskdC for ; Sat, 17 Aug 2013 17:37:45 -0700 (PDT) Received: from nm26-vm4.access.bullet.mail.gq1.yahoo.com (nm26-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2E911E817C for ; Sat, 17 Aug 2013 17:37:39 -0700 (PDT) Received: from [216.39.60.167] by nm26.access.bullet.mail.gq1.yahoo.com with NNFMP; 18 Aug 2013 00:37:38 -0000 Received: from [67.195.14.111] by tm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 18 Aug 2013 00:37:38 -0000 Received: from [127.0.0.1] by smtp108.sbc.mail.gq1.yahoo.com with NNFMP; 18 Aug 2013 00:37:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1376786258; bh=XZVA2usuYmZqhsf2HBtyXqOKkYutXiYGl5zoAsfk84Q=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; b=ab0Prb2T5VueuJZDhQ6/357efz4NEzLnyaw18R3l9ZH4uLnehlwEWsZpfZ3UM6Xlvs68atDc6wed7uT0wauFmKjBCRP1eF2KVQ8+YhyhY0Bff+R56eKDdQ8uXo10EVuzoTR5gv+1aQaZ1EDm2j5TDKwxwVaCmt3Oo+xpaQ6Dt+4= X-Yahoo-Newman-Id: 892344.33841.bm@smtp108.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NGOg7joVM1kOEsL5tfo5X2Muow.fxH5WCdnud7uR7m_dvGo CtT1c_v5me8wxcEW2HBlFzCi1gt59OSvQRRRpGAUZyGhZdAdj2HLpYHRGEzx YzogC85MxF4zaUIZMhv6.i3iGFHHL0sWi4tDrgmx_U7PbioRqFEsXVJaYB0b P.Kw9U7WFkjfbP3HJiMI6GeFIUfqiXGIs45nUGJmiV9LPoVPuf7Yky_Z81GJ O0Mspw_ZKeacP1Y356CClLcZetEZrlArBNoqIihCjvkSh0OXz6oCO9sdBE1V Ib0ckJAXDc8eCVuS4wDfyfD3yW2789cBF3V5ZeCLgL1ijLBk3XK0JIbo_6kK eqlAeWdMloZcGa3911n8LQMc1dGmWvYw1tTCqexfeEKqgSCrF_KRLnlxUfgQ sVupCuU8nXqQHlDNB.GT1EvijCSafG7SztyxyrEBmrQjELxrGhq82ejEHUfk w3HDVtQ.Gb_hVMfpquK2h6fmyTrHZR7EItSQCJH6F8wJasZL2_QA.6aqDGBV 4KN18CUMzpzEq3Kkmnag4yfwFHZC.Nk4xVrBaU.YnSICWCy6zbvn9pngvmEW CZ3kUzqhq6A7F_2d9Kf63FQ4fjpU3fEyTPEOLWZOqiLCFzmeMr6xBk26HZTX eaYnRNIoiJ8W6cg.tHzzFVjroATtnFTV0l_k37iOaOJGdB.UrEY1w3o_pAb1 R22F7e3zZI7EUDTc3W.UEeY7H0_RCqheNt8r30JKp6NwwV9Rg5DPdxcqf4Yw Z0zA08AnG.hTCrLM8atrK_RoK9O9dmpq0XyGHwXgb1r.Lp6E3gY6Qnu.LJCC pBpGeZanc41_LRurmEXCnI7GId4.x1K3xphL8SQl2BpHn2FX.EQdC4vxxMoP G_b7DcOC_6F1C61a13OAueL6jnXpB.lloGb5k1LI- X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g-- X-Rocket-Received: from [192.168.1.64] (dmjacobson@99.120.98.171 with plain) by smtp108.sbc.mail.gq1.yahoo.com with SMTP; 17 Aug 2013 17:37:38 -0700 PDT Message-ID: <52101751.7080807@sbcglobal.net> Date: Sat, 17 Aug 2013 17:37:37 -0700 From: David Jacobson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: cfrg@irtf.org References: <32A53FD55709804D8533DD5D308A40A216B2F1A1CC@FHDP1LUMXC7V33.us.one.verizon.com> <520E10A2.2030908@htt-consult.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030604000102000005030806" Subject: Re: [Cfrg] Fwd: Encryption is less secure than we thought - MIT News Office X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 00:37:51 -0000 This is a multi-part message in MIME format. --------------030604000102000005030806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit This is ancient news. Back in 2004 I went to the NIST Workshop on Random Number Generation, which was convened to get reaction to a draft of ANSI X9.82 (about random number generation) That draft really made the point that min-entropy was the preferred measure, and even had examples of why Shannon entropy, another one they called "guessing entropy", and some other one were all flawed. The flaws were all the same: you could find distributions that were quite good in the measure in question, yet there was one value that occurred with high probability. Personally, I'm quite fond of order-2 Renyi entropy. There is a theorem that min-entropy is not less than half the order-2 Renyi entropy, so if the order-2 Renyi entropy is decent, you can't have terrible min-entropy. I'll elaborate more on why I like order-2 Renyi entropy some day when I have some spare time. But this is off-topic. --David Jacobson On 8/16/13 5:35 AM, Ben Laurie wrote: > > > > On 16 August 2013 07:44, Robert Moskowitz > wrote: > > So what are the thoughts about this here? I have been asked to do > a little digging amongst my contacts. Seems it clearly states > that our secure communications stuff we do is not affected by this > work, but perhaps secure data objects and various wireless > password passing technologies might be at risk? > > > This seems to be restating essentially what Joe Bonneau said far more > readably a year ago: > http://www.jbonneau.com/doc/B12-IEEESP-analyzing_70M_anonymized_passwords.pdf. > > > > -------- Original Message -------- > > > From Evernote: > > > Encryption is less secure than we thought - MIT News Office > > Clipped from: > *http://web.mit.edu/newsoffice/2013/encryption-is-less-secure-than-we-thought-0814.html* > > > > Encryption is less secure than we thought > > For 65 years, most information-theoretic analyses of cryptographic > systems have made a mathematical assumption that turns out to be > wrong*.* > > Larry Hardesty, MIT News Office > > > Muriel Mdard is a professor in the MIT Department of Electrical > Engineering*.* Photo: Bryce Vickmark > > Information theory --- the discipline that gave us digital > communication and data compression --- also put cryptography on a > secure mathematical foundation*.* Since 1948, when the *paper that > created information theory * > first > appeared, most information-theoretic analyses of secure schemes > have depended on a common assumption*.* > > Unfortunately, as a group of researchers at MIT and the National > University of Ireland (NUI) at Maynooth, demonstrated in a paper > presented at the recent International Symposium on Information > Theory (*view PDF * ), that > assumption is false*.* In a follow-up paper being presented this > fall at the Asilomar Conference on Signals and Systems, the same > team shows that, as a consequence, the wireless card readers used > in many keyless-entry systems may not be as secure as previously > thought*.* > > In information theory, the concept of information is intimately > entwined with that of entropy*.* Two digital files might contain > the same amount of information, but if one is shorter, it has more > entropy*.* If a compression algorithm --- such as WinZip or gzip > --- worked perfectly, the compressed file would have the maximum > possible entropy*.* That means that it would have the same number > of 0s and 1s, and the way in which they were distributed would be > totally unpredictable*.* In information-theoretic parlance, it > would be perfectly uniform*.* > > Traditionally, information-theoretic analyses of secure schemes > have assumed that the source files are perfectly uniform*.* In > practice, they rarely are, but they're close enough that it > appeared that the standard mathematical analyses still held*.* > > "We thought we'd establish that the basic premise that everyone > was using was fair and reasonable," says Ken Duffy, one of the > researchers at NUI*.* "And it turns out that it's not." On both > papers, Duffy is joined by his student Mark Christiansen; Muriel > Mdard, a professor of electrical engineering at MIT; and her > student Flvio du Pin Calmon*.* > > The problem, Mdard explains, is that information-theoretic > analyses of secure systems have generally used the wrong notion of > entropy*.* They relied on so-called Shannon entropy, named after > the founder of information theory, Claude Shannon, who taught at > MIT from 1956 to 1978*.* > > Shannon entropy is based on the average probability that a given > string of bits will occur in a particular type of digital file*.* > In a general-purpose communications system, that's the right type > of entropy to use, because the characteristics of the data traffic > will quickly converge to the statistical averages*.* Although > Shannon's seminal 1948 paper dealt with cryptography, it was > primarily concerned with communication, and it used the same > measure of entropy in both discussions*.* > > But in cryptography, the real concern isn't with the average case > but with the worst case*.* A codebreaker needs only one reliable > correlation between the encrypted and unencrypted versions of a > file in order to begin to deduce further correlations*.* In the > years since Shannon's paper, information theorists have developed > other notions of entropy, some of which give greater weight to > improbable outcomes*.* Those, it turns out, offer a more accurate > picture of the problem of codebreaking*.* > > When Mdard, Duffy and their students used these alternate > measures of entropy, they found that slight deviations from > perfect uniformity in source files, which seemed trivial in the > light of Shannon entropy, suddenly loomed much larger*.* The > upshot is that a computer turned loose to simply guess > correlations between the encrypted and unencrypted versions of a > file would make headway much faster than previously expected*.* > > "It's still exponentially hard, but it's exponentially easier than > we thought," Duffy says*.* One implication is that an attacker who > simply relied on the frequencies with which letters occur in > English words could probably guess a user-selected password much > more quickly than was previously thought*.* "Attackers often use > graphics processors to distribute the problem," Duffy says*.* > "You'd be surprised at how quickly you can guess stuff*.*" > > In their Asilomar paper, the researchers apply the same type of > mathematical analysis in a slightly different way*.* They consider > the case in which an attacker is, from a distance, able to make a > "noisy" measurement of the password stored on a credit card with > an embedded chip or a key card used in a keyless-entry system*.* > > "Noise" is the engineer's term for anything that degrades an > electromagnetic signal --- such as physical obstructions, > out-of-phase reflections or other electromagnetic interference*.* > Noise comes in lots of different varieties: The familiar white > noise of sleep aids is one, but so is pink noise, black noise and > more exotic-sounding types of noise, such as power-law noise or > Poisson noise*.* > > In this case, rather than prior knowledge about the statistical > frequency of the symbols used in a password, the attacker has > prior knowledge about the probable noise characteristics of the > environment: Phase noise with one set of parameters is more > probable than phase noise with another set of parameters, which in > turn is more probable than Brownian noise, and so on*.* Armed with > these statistics, an attacker could infer the password stored on > the card much more rapidly than was previously thought*.* > > "Some of the approximations that we're used to making, they make > perfect sense in the context of traditional communication," says > Matthieu Bloch, an assistant professor of electrical and computer > engineering at the Georgia Institute of Technology*.* "You design > your system in a framework, and then you test it*.* But for > crypto, you're actually trying to prove that it's robust to things > you cannot test*.* So you have to be sure that your assumptions > make sense from the beginning*.* And I think that going back to > the assumptions is something people don't do often enough*.*" > > Bloch doubts that the failure of the uniformity assumption means > that cryptographic systems in wide use today are fundamentally > insecure*.* "My guess is that it will show that some of them are > slightly less secure than we had hoped, but usually in the > process, we'll also figure out a way of patching them," he says*.* > The MIT and NUI researchers' work, he says, "is very constructive, > because it's essentially saying, 'Hey, we have to be careful*.*' > But it also provides a methodology to go back and reanalyze all > these things*.*" > > Comments > > > > *Log in to write comments * > > > ** > > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --------------030604000102000005030806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
This is ancient news.  Back in 2004 I went to the NIST Workshop on Random Number Generation, which was convened to get reaction to a draft of ANSI X9.82 (about random number generation)  That draft really made the point that min-entropy was the preferred measure, and even had examples of why Shannon entropy, another one they called "guessing entropy", and some other one were all flawed.  The flaws were all the same:  you could find distributions that were quite good in the measure in question, yet there was one value that occurred with high probability.

Personally, I'm quite fond of order-2 Renyi entropy.  There is a theorem that min-entropy is not less than half the order-2 Renyi entropy, so if the order-2 Renyi entropy is decent, you can't have terrible min-entropy.   I'll elaborate more on why I like order-2 Renyi entropy some day when I have some spare time.  But this is off-topic.

  --David Jacobson


On 8/16/13 5:35 AM, Ben Laurie wrote:



On 16 August 2013 07:44, Robert Moskowitz <rgm-sec@htt-consult.com> wrote:
So what are the thoughts about this here?  I have been asked to do a little digging amongst my contacts.  Seems it clearly states that our secure communications stuff we do is not affected by this work, but perhaps secure data objects and various wireless password passing technologies might be at risk?

This seems to be restating essentially what Joe Bonneau said far more readably a year ago: http://www.jbonneau.com/doc/B12-IEEESP-analyzing_70M_anonymized_passwords.pdf.
 


-------- Original Message --------

 


From Evernote:

Encryption is less secure than we thought - MIT News Office

Clipped from: http://web.mit.edu/newsoffice/2013/encryption-is-less-secure-than-we-thought-0814.html

Encryption is less secure than we thought 

For 65 years, most information-theoretic analyses of cryptographic systems have made a mathematical assumption that turns out to be wrong.

Larry Hardesty, MIT News Office


Muriel Médard is a professor in the MIT Department of Electrical Engineering. Photo: Bryce Vickmark

Information theory — the discipline that gave us digital communication and data compression — also put cryptography on a secure mathematical foundation. Since 1948, when the paper that created information theory first appeared, most information-theoretic analyses of secure schemes have depended on a common assumption.

Unfortunately, as a group of researchers at MIT and the National University of Ireland (NUI) at Maynooth, demonstrated in a paper presented at the recent International Symposium on Information Theory (view PDF ), that assumption is false. In a follow-up paper being presented this fall at the Asilomar Conference on Signals and Systems, the same team shows that, as a consequence, the wireless card readers used in many keyless-entry systems may not be as secure as previously thought.

In information theory, the concept of information is intimately entwined with that of entropy. Two digital files might contain the same amount of information, but if one is shorter, it has more entropy. If a compression algorithm — such as WinZip or gzip — worked perfectly, the compressed file would have the maximum possible entropy. That means that it would have the same number of 0s and 1s, and the way in which they were distributed would be totally unpredictable. In information-theoretic parlance, it would be perfectly uniform.

Traditionally, information-theoretic analyses of secure schemes have assumed that the source files are perfectly uniform. In practice, they rarely are, but they’re close enough that it appeared that the standard mathematical analyses still held.

“We thought we’d establish that the basic premise that everyone was using was fair and reasonable,” says Ken Duffy, one of the researchers at NUI. “And it turns out that it’s not.” On both papers, Duffy is joined by his student Mark Christiansen; Muriel Médard, a professor of electrical engineering at MIT; and her student Flávio du Pin Calmon.

The problem, Médard explains, is that information-theoretic analyses of secure systems have generally used the wrong notion of entropy. They relied on so-called Shannon entropy, named after the founder of information theory, Claude Shannon, who taught at MIT from 1956 to 1978.

Shannon entropy is based on the average probability that a given string of bits will occur in a particular type of digital file. In a general-purpose communications system, that’s the right type of entropy to use, because the characteristics of the data traffic will quickly converge to the statistical averages. Although Shannon’s seminal 1948 paper dealt with cryptography, it was primarily concerned with communication, and it used the same measure of entropy in both discussions.

But in cryptography, the real concern isn’t with the average case but with the worst case. A codebreaker needs only one reliable correlation between the encrypted and unencrypted versions of a file in order to begin to deduce further correlations. In the years since Shannon’s paper, information theorists have developed other notions of entropy, some of which give greater weight to improbable outcomes. Those, it turns out, offer a more accurate picture of the problem of codebreaking.

When Médard, Duffy and their students used these alternate measures of entropy, they found that slight deviations from perfect uniformity in source files, which seemed trivial in the light of Shannon entropy, suddenly loomed much larger. The upshot is that a computer turned loose to simply guess correlations between the encrypted and unencrypted versions of a file would make headway much faster than previously expected.

“It’s still exponentially hard, but it’s exponentially easier than we thought,” Duffy says. One implication is that an attacker who simply relied on the frequencies with which letters occur in English words could probably guess a user-selected password much more quickly than was previously thought. “Attackers often use graphics processors to distribute the problem,” Duffy says. “You’d be surprised at how quickly you can guess stuff.

In their Asilomar paper, the researchers apply the same type of mathematical analysis in a slightly different way. They consider the case in which an attacker is, from a distance, able to make a “noisy” measurement of the password stored on a credit card with an embedded chip or a key card used in a keyless-entry system.

“Noise” is the engineer’s term for anything that degrades an electromagnetic signal — such as physical obstructions, out-of-phase reflections or other electromagnetic interference. Noise comes in lots of different varieties: The familiar white noise of sleep aids is one, but so is pink noise, black noise and more exotic-sounding types of noise, such as power-law noise or Poisson noise.

In this case, rather than prior knowledge about the statistical frequency of the symbols used in a password, the attacker has prior knowledge about the probable noise characteristics of the environment: Phase noise with one set of parameters is more probable than phase noise with another set of parameters, which in turn is more probable than Brownian noise, and so on. Armed with these statistics, an attacker could infer the password stored on the card much more rapidly than was previously thought.

“Some of the approximations that we’re used to making, they make perfect sense in the context of traditional communication,” says Matthieu Bloch, an assistant professor of electrical and computer engineering at the Georgia Institute of Technology. “You design your system in a framework, and then you test it. But for crypto, you’re actually trying to prove that it’s robust to things you cannot test. So you have to be sure that your assumptions make sense from the beginning. And I think that going back to the assumptions is something people don’t do often enough.

Bloch doubts that the failure of the uniformity assumption means that cryptographic systems in wide use today are fundamentally insecure. “My guess is that it will show that some of them are slightly less secure than we had hoped, but usually in the process, we’ll also figure out a way of patching them,” he says. The MIT and NUI researchers’ work, he says, “is very constructive, because it’s essentially saying, ‘Hey, we have to be careful.’ But it also provides a methodology to go back and reanalyze all these things.

 




_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg




_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

--------------030604000102000005030806-- From benlaurie@gmail.com Mon Aug 19 04:27:39 2013 Return-Path: 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 C4F5111E824B for ; Mon, 19 Aug 2013 04:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 Wkv2du6Dzq-u for ; Mon, 19 Aug 2013 04:27:39 -0700 (PDT) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF0E11E80D9 for ; Mon, 19 Aug 2013 04:27:39 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id i11so2544163qej.13 for ; Mon, 19 Aug 2013 04:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=67GLFlf41U2rOTLItbhffQ2tphz9QourAv7n/mL+zpw=; b=Cy0CMS8s6pqEwAPbPrK+wnt5+xJCi5QutfgZAVVHZqZakwf8t2Iz11yet4muSU53AS yyDJNsW5DhI2ILQd0Mj8W7aDh6TKBkkCnwXri9HItJ9cW/1co83o5fAbw+Vzuk/kIaaz 3QRLvTnqbGEMOGp3GL5lkuUXedYgYayhIvHAlPM4FgNW44tAjGRlsDcqOeT8mWy6QCvU TNjS1w+6hwzAHsKRz4jCEFhHkAqev5HUtHCZG5o7R7SUVHbMN0Pysy1tlTGS/e17O7Zy fusQLMvfIxbZbREamQ5uHdghUesQgz2zdHvYRjAsZFjsOr4PQwMyqlGs6lUqz4l2GpjV Fe7A== MIME-Version: 1.0 X-Received: by 10.224.80.9 with SMTP id r9mr1744892qak.89.1376911658604; Mon, 19 Aug 2013 04:27:38 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.4.70 with HTTP; Mon, 19 Aug 2013 04:27:38 -0700 (PDT) In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> References: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> Date: Mon, 19 Aug 2013 07:27:38 -0400 X-Google-Sender-Auth: ost7q5-8eqxZg5loOtCm48jKPiE Message-ID: From: Ben Laurie To: "Igoe, Kevin M." Content-Type: multipart/alternative; boundary=001a11c2b9ea4c77df04e44b3af5 Cc: "cfrg@irtf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 11:27:39 -0000 --001a11c2b9ea4c77df04e44b3af5 Content-Type: text/plain; charset=ISO-8859-1 On 8 August 2013 15:45, Igoe, Kevin M. wrote: > > Off the top of my head, the only objection I can see is that SALSA may be > difficult to > implement efficiently in hardware. Hardware TLS acceleration can be > useful at heavily > utilized servers. > This is a myth that should stop being repeated. The only use of hardware acceleration is for attackers. --001a11c2b9ea4c77df04e44b3af5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 8 August 2013 15:45, Igoe, Kevin M. <kmigoe@nsa.gov>= wrote:
Off the top of my head, the only objection I can see is that SALSA may= be difficult to
implement efficiently in hardware.=A0 Hardware TLS acceleration can be= useful at heavily
utilized servers.

This is a myth that should stop being repeated.
=A0
The only use of hardware acceleration is for attackers.

--001a11c2b9ea4c77df04e44b3af5-- From paul.hoffman@vpnc.org Mon Aug 19 08:45:35 2013 Return-Path: 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 0E6BB11E82A1 for ; Mon, 19 Aug 2013 08:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 zl7wWQleYOHt for ; Mon, 19 Aug 2013 08:45:34 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9B32F11E8295 for ; Mon, 19 Aug 2013 08:45:34 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r7JFjVBr045278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Aug 2013 08:45:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Mon, 19 Aug 2013 08:45:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> To: Ben Laurie X-Mailer: Apple Mail (2.1508) Cc: "cfrg@irtf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 15:45:35 -0000 On Aug 19, 2013, at 4:27 AM, Ben Laurie wrote: > On 8 August 2013 15:45, Igoe, Kevin M. wrote: > Off the top of my head, the only objection I can see is that SALSA may = be difficult to > implement efficiently in hardware. Hardware TLS acceleration can be = useful at heavily > utilized servers. >=20 > This is a myth that should stop being repeated. > =20 > The only use of hardware acceleration is for attackers. And this is an overgeneralization that should stop being repeated. Hardware acceleration is used in firewalls because SSL decryption is = often the biggest performance hit. (You might consider these to be an = attack, but none of the companies that purchase them do.) --Paul Hoffman= From Joachim@Strombergson.com Mon Aug 19 23:23:40 2013 Return-Path: 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 8DB5A11E81C8 for ; Mon, 19 Aug 2013 23:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 lXvV4ZlluqYM for ; Mon, 19 Aug 2013 23:23:26 -0700 (PDT) Received: from susano.oderland.com (susano.oderland.com [91.201.63.143]) by ietfa.amsl.com (Postfix) with ESMTP id ABE3311E80D2 for ; Mon, 19 Aug 2013 23:23:26 -0700 (PDT) Received: from 2.67.227.87.static.g-sn.siw.siwnet.net ([87.227.67.2]:43996 helo=tunnis.local) by susano.oderland.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VBfLe-001OSY-HR; Tue, 20 Aug 2013 08:23:22 +0200 Message-ID: <52130B58.2000209@Strombergson.com> Date: Tue, 20 Aug 2013 08:23:20 +0200 From: =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= Organization: Kryptologik User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Igoe, Kevin M." References: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - susano.oderland.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - Strombergson.com X-Get-Message-Sender-Via: susano.oderland.com: authenticated_id: joachim@strombergson.com Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] Task for the CFRG X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Joachim@Strombergson.com List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 06:23:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! Igoe, Kevin M. wrote: > Off the top of my head, the only objection I can see is that SALSA > may be difficult to implement efficiently in hardware. Hardware TLS > acceleration can be useful at heavily utilized servers. And Salsa isn't that hard to implement in HW. ChaCha is better. But compared to other eSTREAM profiles such as HC-128 (which is a pain to implement efficiently in FPGAs) and Rabbit, Salsa is actually pretty ok. - -- Med vnlig hlsning, Yours Joachim Strmbergson - Alltid i harmonisk svngning. ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlITC1gACgkQZoPr8HT30QGdAgCfaWzIjhZyGOmhC7VW+hxzrcHm RrUAoN7e/8SJ1pBLBb2cUD1IBzd5aGmV =5Vcz -----END PGP SIGNATURE----- From n.mavrogiannopoulos@gmail.com Thu Aug 22 12:57:11 2013 Return-Path: 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 B6B2521F9F77 for ; Thu, 22 Aug 2013 12:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 k0un06cpj+m7 for ; Thu, 22 Aug 2013 12:57:10 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DFB0121F9EED for ; Thu, 22 Aug 2013 12:57:09 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ev20so1835743lab.36 for ; Thu, 22 Aug 2013 12:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eFVaFpI4XAB8PnGLdjflG1Ywv2gydd22PzwAu9VWS7A=; b=z+L6EpEd+xGUXEzisAgLh7dab+RwQXiFLmPN0Sgq19jJ152VIEwpKqFRPhnWNK1L07 N+CtplGEjr9Zg4vuAJtpMp0dkpGCITIsR+f9bisg9Z3l6GYHgxEnEoOLG5x3yYrVkETX Bx8jtPX7dBgMzPkIHvDHC8+0xBNswg3PRVKbylUM5myU5b5h8G4dOjQM8yVLP01IcJ1j zBYld7jYNA8/gR+4gUmdwnNnKJUp7tD8KXLU7cJ/KG9+MSCLM8UYcQRDZnfyGxgtO+ZH VYn42tJu7y+Uhs4bDjUdVdiiPk2WlL4NhOZlRfWrY9m3dzTj1dFLag+nTz75W6Pj6AVM rSIQ== MIME-Version: 1.0 X-Received: by 10.112.158.225 with SMTP id wx1mr2716051lbb.37.1377201427206; Thu, 22 Aug 2013 12:57:07 -0700 (PDT) Received: by 10.112.63.66 with HTTP; Thu, 22 Aug 2013 12:57:07 -0700 (PDT) In-Reply-To: <1376512356.16950.360.camel@darkstar> References: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> <1376512356.16950.360.camel@darkstar> Date: Thu, 22 Aug 2013 22:57:07 +0300 Message-ID: From: Nikos Mavrogiannopoulos To: David McGrew Content-Type: multipart/alternative; boundary=001a11c34932da596104e48eb1d7 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] problems with draft-josefsson-salsa20-tls-02 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 19:57:11 -0000 --001a11c34932da596104e48eb1d7 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 14, 2013 at 11:32 PM, David McGrew wrote: Hello, I believe your comments relate more to the ietf-tls rather than this list. In any case some comments are in-line. > This draft lists two motivations: RC4 security is inadequate, and the > performance of the symmetric cryptography in other ciphersuites is > inadequate. I agree with the first premise, and the authors deserve > kudos for raising and starting to address the issue. However, the > second premise is questionable. The draft cites [AEAD-PERFORMANCE], and > that reference shows that the performance of AES-GCM and AES-CCM are > suboptimal in some scenarios, not that they are inadequate. The draft > ought to cite some other work such as [1] to provide a broader viewpoint > on ciphersuite performance and deployment considerations of new > ciphersuites. If it is the case that SALSA20 and UMAC (or POLY1305) > compellingly outperform existing ciphersuites on some particular client > environments and server environments, the draft should document the > particulars. > I thought that it was generally accepted that salsa20 (or any other estream candidate) outperform AES. There are benchmarks in the estream framework we can link to [0] if it is deemed necessary. [0]. http://www.ecrypt.eu.org/stream/perf/ The security question that we should be considering is: are the > authenticated encryption schemes defined in this draft sound? The > strategy used in this draft is to rely on the "generic composition" > framework provided by TLS: a new GenericStreamCipher is defined and is > used at the same time as a TLS MAC algorithm, which is either the > conventional TLS HMAC or the new TLS UMAC algorithm defined in this > draft. Thus, there is a merely a loose binding between authentication > and encryption, and a potential opportunity for a side channel attack > like the ones described in [CBC-ATTACK]. I don't understand why you think that. There is no padding involved in the salsa20 ciphersuites, so the padding based [CBC-ATTACK] (or any other similar attack) do not apply. To my knowledge there is no known issue for the mode used in salsa20/hmac or salsa20/umac in the draft. The draft recognizes the value > of resisting side channel attacks, but the loose binding approach works > against that goal. Instead of defining a GenericStreamCipher, the draft > should define an AEAD algorithm, which would close the door on that sort > of vulnerability. > I don't quite understand that. Could you elaborate on the particulars? Why do you think that the TLS GenericStreamCipher is vulnerable to side-channel attacks (and the GenericAEADCipher is not?). I believe your comment is towards the general constructions (and more precisely you mean the GenericBlockCipher) rather than this particular ciphersuite. > One of the motivations for not using the TLS GenericAEADCipher mechanism > is that it appears only in TLSv1.2. However, the draft proposes > extensions to both the GenericStreamCipher and MAC algorithms used by > TLSv1.0 and TLSv1.1, and it would be no more intrusive to those > protocols to define the use of GenericAEADCipher in them. Using the > same AEAD mechanism for versions 1.0, 1.1, and 1.2 would result in > smaller and less complex implementation. > Only if you can work in clean slate. Unfortunately that doesn't happen in practice. In practice one would add the ciphersuite in an existing implementation that may not support TLS 1.2. > The draft has no mechanism to allow multiple encrypters to work in > parallel, such as is provided in Section 6.2 of RFC5288. > Actually RFC5288 needs this section because it uses a random nonce. Since the salsa draft doesn't use a random nonce it doesn't require such a special provision for parallel encryptors. Parallel encryptors come for free in the salsa20 draft. > Previous AEAD work has chosen to not use the sequence number provided by > TLS (and other protocols) because of a lack of assurance that those > values will be unique. This draft does use those sequence numbers, > which enables its ciphersuites to have less data overhead, but > introducing a potential vulnerability through mismanagement of sequence > numbers by TLS implementations. > TLS ensures that sequence numbers are unique. All of the TLS 1.x documents mention specifically: "Sequence numbers are of type uint64 and may not exceed 2^64-1. Sequence numbers do not wrap". regards, Nikos --001a11c34932da596104e48eb1d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 14, 2013 at 11:32 PM, David McGrew <mcgrew@cisco.com>= wrote:

Hello,
=C2=A0I believe your comments relate more to the ietf-tls rather than= this list. In any case some comments are in-line.
=C2=A0
This draft lists two motivations: RC4 security is inadequate, and the
performance of the symmetric cryptography in other ciphersuites is
inadequate. =C2=A0I agree with the first premise, and the authors deserve kudos for raising and starting to address the issue. =C2=A0 However, the second premise is questionable. =C2=A0The draft cites [AEAD-PERFORMANCE], a= nd
that reference shows that the performance of AES-GCM and AES-CCM are
suboptimal in some scenarios, not that they are inadequate. =C2=A0The draft=
ought to cite some other work such as [1] to provide a broader viewpoint on ciphersuite performance and deployment considerations of new
ciphersuites. =C2=A0 If it is the case that SALSA20 and UMAC (or POLY1305)<= br> compellingly outperform existing ciphersuites on some particular client
environments and server environments, the draft should document the
particulars.

I thought that it was gene= rally accepted that salsa20 (or any other estream candidate) outperform AES= . There are benchmarks in the estream framework we can link to [0] if it is= deemed necessary.

[0]. http://www.ecryp= t.eu.org/stream/perf/


The security question that we should be considering is: are the
authenticated encryption schemes defined in this draft sound? =C2=A0 The strategy used in this draft is to rely on the "generic composition&quo= t;
framework provided by TLS: a new GenericStreamCipher is defined and is
used at the same time as a TLS MAC algorithm, which is either the
conventional TLS HMAC or the new TLS UMAC algorithm defined in this
draft. =C2=A0 Thus, there is a merely a loose binding between authenticatio= n
and encryption, and a potential opportunity for a side channel attack
like the ones described in [CBC-ATTACK]. =C2=A0

=
I don't understand why you think that. There is no padding involve= d in the salsa20 ciphersuites, so the padding based=C2=A0 [CBC-ATTACK] (or = any other similar attack) do not apply. To my knowledge there is no known i= ssue for the mode used in salsa20/hmac or salsa20/umac in the draft.

The = draft recognizes the value
of resisting side channel attacks, but the loose binding approach works
against that goal. =C2=A0Instead of defining a GenericStreamCipher, the dra= ft
should define an AEAD algorithm, which would close the door on that sort of vulnerability.

I don't quite und= erstand that. Could you elaborate on the particulars? Why do you think that= the TLS GenericStreamCipher is vulnerable to side-channel attacks (and the= GenericAEADCipher is not?). I believe your comment is towards the general = constructions (and more precisely you mean the GenericBlockCipher) rather t= han this particular ciphersuite.
=C2=A0
regards,
Nikos

<= /div>
--001a11c34932da596104e48eb1d7-- From zooko@zooko.com Thu Aug 22 15:59:55 2013 Return-Path: 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 7194311E8242 for ; Thu, 22 Aug 2013 15:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] 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 vsx74zwzyEuj for ; Thu, 22 Aug 2013 15:59:51 -0700 (PDT) Received: from zooko.com (216-155-145-223.cinfuserver.com [216.155.145.223]) by ietfa.amsl.com (Postfix) with ESMTP id 22E3111E8230 for ; Thu, 22 Aug 2013 15:59:50 -0700 (PDT) Received: by zooko.com (Postfix, from userid 1000) id 208C071E001; Fri, 23 Aug 2013 02:59:44 +0400 (MSK) Date: Fri, 23 Aug 2013 02:59:44 +0400 From: zooko To: Nikos Mavrogiannopoulos Message-ID: <20130822225944.GB5240@zooko.com> References: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> <1376512356.16950.360.camel@darkstar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: David McGrew , "cfrg@irtf.org" Subject: Re: [Cfrg] problems with draft-josefsson-salsa20-tls-02 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 22:59:55 -0000 Very thorough and recent benchmarks including Salsa20, ChaCha, Salsa20/8, and AES, are available here: http://bench.cr.yp.to/results-stream.html Regards, Zooko From mcgrew@cisco.com Mon Aug 26 08:49:52 2013 Return-Path: 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 0B47A11E81BC for ; Mon, 26 Aug 2013 08:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 X-cgigS77obi for ; Mon, 26 Aug 2013 08:49:47 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD1511E81B9 for ; Mon, 26 Aug 2013 08:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7699; q=dns/txt; s=iport; t=1377532187; x=1378741787; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=ss2w3wnjIQR9P0vy1CyRAc2kaOmLkq9KfwM4d5Ntx7M=; b=d6nvLFdUdb2F0u8QYakzF1H4Qbpu5xtx+ekZaQmICdvGu9KZPuCwf0hf qXE7MB5BytkBrdXEQt6HaoX/FXtPDKLxp/hT0V2mJFX/j+idW0qWoIxL3 nNx5fjABNiPVUYVmLyuVdwNEwFo8zW5r+LY+aa1KXKEUlqJqoj7qR7rnD o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAAp4G1KtJV2a/2dsb2JhbABbgwc1g3i8boEiFnSCJAEBAQMBAQEBIEsLBQsLGAICJgICJzAGEwmHcgYMpT6SJYEpjEiBT4E4B4JogTEDnhiLN4M6IA X-IronPort-AV: E=Sophos;i="4.89,959,1367971200"; d="scan'208";a="251719191" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 26 Aug 2013 15:49:44 +0000 Received: from [10.0.2.15] (rtp-mcgrew-8912.cisco.com [10.117.10.227]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7QFni00031640; Mon, 26 Aug 2013 15:49:44 GMT Message-ID: <1377532182.4027.103.camel@darkstar> From: David McGrew To: Nikos Mavrogiannopoulos Date: Mon, 26 Aug 2013 11:49:42 -0400 In-Reply-To: References: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> <1376512356.16950.360.camel@darkstar> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] problems with draft-josefsson-salsa20-tls-02 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 15:49:52 -0000 Hi Nikos, On Thu, 2013-08-22 at 22:57 +0300, Nikos Mavrogiannopoulos wrote: > On Wed, Aug 14, 2013 at 11:32 PM, David McGrew > wrote: > > Hello, > > I believe your comments relate more to the ietf-tls rather than this > list. In any case some comments are in-line. > > This draft lists two motivations: RC4 security is inadequate, > and the > performance of the symmetric cryptography in other > ciphersuites is > inadequate. I agree with the first premise, and the authors > deserve > kudos for raising and starting to address the issue. > However, the > second premise is questionable. The draft cites > [AEAD-PERFORMANCE], and > that reference shows that the performance of AES-GCM and > AES-CCM are > suboptimal in some scenarios, not that they are inadequate. > The draft > ought to cite some other work such as [1] to provide a broader > viewpoint > on ciphersuite performance and deployment considerations of > new > ciphersuites. If it is the case that SALSA20 and UMAC (or > POLY1305) > compellingly outperform existing ciphersuites on some > particular client > environments and server environments, the draft should > document the > particulars. > > > I thought that it was generally accepted that salsa20 (or any other > estream candidate) outperform AES. If there is a compelling benefit to using these ciphersuites, it deserves to be quantified. > There are benchmarks in the estream framework we can link to [0] if it > is deemed necessary. > > [0]. http://www.ecrypt.eu.org/stream/perf/ It definitely would be good to reference the ESTREAM performance comparisons, but the draft should also explain what platform(s) are the performance targets. Is the goal of the draft to minimize CPU utilization, and thus power usage, on mobile clients, without regard to servers? Or perhaps there is another goal; I'm speculating here. An example of why better documentation of the benefits is needed: in the ESTREAM performance tables that you cite above, AES CTR uses fewer CPU cycles than Salsa20 on some platforms, while Salsa20 uses fewer cycles on some other platforms. > > > > > The security question that we should be considering is: are > the > authenticated encryption schemes defined in this draft sound? > The > strategy used in this draft is to rely on the "generic > composition" > framework provided by TLS: a new GenericStreamCipher is > defined and is > used at the same time as a TLS MAC algorithm, which is either > the > conventional TLS HMAC or the new TLS UMAC algorithm defined in > this > draft. Thus, there is a merely a loose binding between > authentication > and encryption, and a potential opportunity for a side channel > attack > like the ones described in [CBC-ATTACK]. > > > I don't understand why you think that. There is no padding involved in > the salsa20 ciphersuites, so the padding based [CBC-ATTACK] (or any > other similar attack) do not apply. To my knowledge there is no known > issue for the mode used in salsa20/hmac or salsa20/umac in the draft. > > > The draft recognizes the value > of resisting side channel attacks, but the loose binding > approach works > against that goal. Instead of defining a GenericStreamCipher, > the draft > should define an AEAD algorithm, which would close the door on > that sort > of vulnerability. > > > I don't quite understand that. Could you elaborate on the particulars? > Why do you think that the TLS GenericStreamCipher is vulnerable to > side-channel attacks (and the GenericAEADCipher is not?). I believe > your comment is towards the general constructions (and more precisely > you mean the GenericBlockCipher) rather than this particular > ciphersuite. > One of the important properties of a sound authenticated encryption scheme is that the decryption operation does not release any (potentially invalid) plaintext data until the authentication check is complete. The GenericStreamCipher does not require an implementation to have this property. Experience with AEAD has shown that implementers are sometimes reluctant to comply with the requirement to not release post-decryption, pre-verification plaintext, even when the specification is quite clear on that point. > > > One of the motivations for not using the TLS GenericAEADCipher > mechanism > is that it appears only in TLSv1.2. However, the draft > proposes > extensions to both the GenericStreamCipher and MAC algorithms > used by > TLSv1.0 and TLSv1.1, and it would be no more intrusive to > those > protocols to define the use of GenericAEADCipher in them. > Using the > same AEAD mechanism for versions 1.0, 1.1, and 1.2 would > result in > smaller and less complex implementation. > > > Only if you can work in clean slate. Unfortunately that doesn't happen > in practice. In practice one would add the ciphersuite in an existing > implementation that may not support TLS 1.2. The point that I wanted to make is: instead of re-defining the GenericStreamCipher and MAC algorithms for TLS v 1.0 and 1.1, GenericAEADCipher can be added to those versions of the protocol. That would enable a TLS implementation that supports the current version of the protocol to use its GenericAEADCipher for all three versions, and relieve that implementation of the need to support an updated definition for GenericStreamCipher and MAC. > > > > The draft has no mechanism to allow multiple encrypters to > work in > parallel, such as is provided in Section 6.2 of RFC5288. > > > Actually RFC5288 needs this section because it uses a random nonce. No, RFC5288 uses a deterministic nonce. > Since the salsa draft doesn't use a random nonce it doesn't require > such a special provision for parallel encryptors. Parallel encryptors > come for free in the salsa20 draft. > No, each Salsa20 nonce MUST be distinct, and the draft makes no provision to ensure that they can be distinct when multiple encrypters are in use. Rather than being "for free", the draft provides no way to allow for an implementation to use parallel encryptors and to maintain security. regards, David > > > Previous AEAD work has chosen to not use the sequence number > provided by > TLS (and other protocols) because of a lack of assurance that > those > values will be unique. This draft does use those sequence > numbers, > which enables its ciphersuites to have less data overhead, but > introducing a potential vulnerability through mismanagement of > sequence > numbers by TLS implementations. > > > TLS ensures that sequence numbers are unique. All of the TLS 1.x > documents mention specifically: > > "Sequence numbers are of type uint64 and may not exceed 2^64-1. > Sequence numbers do not wrap". > > > > regards, > Nikos > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From lhitt@21ct.com Mon Aug 26 12:24:07 2013 Return-Path: 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 AC82B21F99CE for ; Mon, 26 Aug 2013 12:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 7NiNtukPkIVj for ; Mon, 26 Aug 2013 12:24:02 -0700 (PDT) Received: from 21ct-exg07.21technologies.com (unknown [173.226.154.197]) by ietfa.amsl.com (Postfix) with ESMTP id 7D57D21F8C0C for ; Mon, 26 Aug 2013 12:24:02 -0700 (PDT) Received: from 21ct-exg07.21technologies.com ([10.0.10.16]) by 21ct-exg07.21technologies.com ([10.0.10.16]) with mapi; Mon, 26 Aug 2013 14:23:55 -0500 From: Laura Hitt To: Kohei Kasamatsu Date: Mon, 26 Aug 2013 14:23:54 -0500 Thread-Topic: [Cfrg] request for comments: ZSS Short Signature Scheme for SS and BN Curves Thread-Index: Ac6JGr9S4ZGNVFTUS6q0Je1ar1gRGgZdttuA Message-ID: <04920BD67C651C469D0387704CD7692A801128D84A@21ct-exg07.21technologies.com> References: <04920BD67C651C469D0387704CD7692A74B0844B94@21ct-exg07.21technologies.com> <51F0F1E6.5080505@po.ntts.co.jp> In-Reply-To: <51F0F1E6.5080505@po.ntts.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] request for comments: ZSS Short Signature Scheme for SS and BN Curves X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 19:24:07 -0000 Dear Kohei Kasamatsu, Thank you for your comment. The Cheon attacks against (variably named) strong or static Diffie-Hellman assumption, or the Diffie-Hellman with Auxiliary Input problem are very interesting work. I will include the suggested references in the I-D. However, I do not believe it poses a substantial danger for ZSS for the following reasons: 1) Those attacks are predicated on the notion that the attacker will have access to an oracle that will supply s^d*P for large d to help solve the discrete log of sP for s, and there's not sufficient reason to think that this additional information would be available in the cases of interest. 2) Because the parameters used in the I-D (taken from the MIKEY-SAKKE rfc) have a full sized cryptographic subgroup, even if the attack applied, at best these attacks convert the problem to O(Sqrt{(p-1)/d}+d) which is optimized if d<=3Dp^(1/3), but for the rfc parameters, this would still be an attack of order O(p^(1/3))~=3D2^341, which is way worse than the standard NSF costing. Thanks again for your comment. Please let me know if you have other concerns. All the best, Laura =20 -----Original Message----- From: Kohei Kasamatsu [mailto:kasamatsu.kohei@po.ntts.co.jp]=20 Sent: Thursday, July 25, 2013 4:38 AM To: Laura Hitt Cc: cfrg@irtf.org Subject: Re: [Cfrg] request for comments: ZSS Short Signature Scheme for SS= and BN Curves Dear L. Hitt I have a comment. The security of ZSS-signature depends on k+1 Exponent Problem. The problem more efficiently can be computed by cheon algorithm [1,2] than = Pollard's method. (cheon algorithm is not probabilistic polynomial time alg= orithm) Hence I think that it is needed that you analyze security against t= he algorithm. [1] J.H. Cheon, Security Analysis of the Strong Diffie-Hellman Problem, EUR= OCRYPT 2006, LNCS 4004, pp. 1-11, Springer, 2006 [2] Y. Sakemi, G. Hanaoka,= T. Izu, M. Takenaka, and M. Yasuda, "Solving a discrete logarithm problem = with auxiliary input on a 160-bit elliptic curve", PKC 2012, LNCS 7293 pp. = 595-608, Springer, 2012. Best regards, Kohei Kasamatsu (2013/03/23 2:27), Laura Hitt wrote: > end, so thought I'd try again.> > > I have recently submitted (as an Individual) two I-Ds and would greatly a= ppreciate any comments you are able to offer. They pertain to the ZSS shor= t signature scheme from bilinear pairings on supersingular elliptic curves = and on Barreto-Naerhig elliptic curves. > > http://www.ietf.org/internet-drafts/draft-irtf-cfrg-zss-00.txt > http://www.ietf.org/internet-drafts/draft-irtf-cfrg-zssbn-00.txt > > Thank you! > Laura Hitt > > > > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > -- Kohei Kasamatsu NTT Software Corporation E-mail: kasamatsu.kohei@po.ntts.co.jp From internet-drafts@ietf.org Tue Aug 27 13:53:32 2013 Return-Path: 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 F209321F9E63; Tue, 27 Aug 2013 13:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.172 X-Spam-Level: X-Spam-Status: No, score=-102.172 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] 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 AvF1H8HvaEaU; Tue, 27 Aug 2013 13:53:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1419521F9E5C; Tue, 27 Aug 2013 13:53:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130827205330.12848.88868.idtracker@ietfa.amsl.com> Date: Tue, 27 Aug 2013 13:53:30 -0700 Cc: cfrg@ietf.org Subject: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-02.txt X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 20:53:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Crypto Forum Research Group Working Group= of the IETF. Title : Dragonfly Key Exchange Author(s) : Dan Harkins Filename : draft-irtf-cfrg-dragonfly-02.txt Pages : 15 Date : 2013-08-27 Abstract: This document specifies a key exchange using discrete logarithm cryptogprahy that is authenticated using a password or passphrase. It is resistant to active attack, passive attack, and off-line dictionary attack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-cfrg-dragonfly There's also a htmlized version available at: http://tools.ietf.org/html/draft-irtf-cfrg-dragonfly-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-cfrg-dragonfly-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mcgrew@cisco.com Wed Aug 28 04:19:33 2013 Return-Path: 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 9796521F9E5E for ; Wed, 28 Aug 2013 04:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 IORgZPlFMDKz for ; Wed, 28 Aug 2013 04:19:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3375F21F99E8 for ; Wed, 28 Aug 2013 04:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60; q=dns/txt; s=iport; t=1377688769; x=1378898369; h=message-id:subject:from:to:date:mime-version: content-transfer-encoding; bh=M67DwcLEmv5qXICvN2FZxvtLgidHGippJOJ++uy93CA=; b=mpSPkAtsplDnK5joAX6SqlhBQr+BL3MZnkGNkkRLQfhaEPSnMmE+ioFW nH8itqQkafZaS5XVdI7arVm/9KuIWaKRJFfCJri4rpcBVU/c3Q8pvVetE r59wr4jmJRm81E9FbPpi0+I+8VmCdTLci8MyR2vG671VynuhlWQokXCmW 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAJAPvbHVKtJV2d/2dsb2JhbABbgwc1gzG9QAQEgSMWdIRiHId4DJdKoT2UBAOeG4s3gzwg X-IronPort-AV: E=Sophos;i="4.89,975,1367971200"; d="scan'208";a="252409656" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 28 Aug 2013 11:19:28 +0000 Received: from [10.0.2.15] (rtp-mcgrew-8912.cisco.com [10.117.10.227]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7SBJSX9021372 for ; Wed, 28 Aug 2013 11:19:28 GMT Message-ID: <1377688770.4027.258.camel@darkstar> From: David McGrew To: cfrg Date: Wed, 28 Aug 2013 07:19:30 -0400 Content-Type: text/plain X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Cfrg] minutes from meeting at 87th IETF X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 11:19:33 -0000 http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg From mcgrew@cisco.com Wed Aug 28 04:39:04 2013 Return-Path: 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 9357F11E8181 for ; Wed, 28 Aug 2013 04:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.599 X-Spam-Level: X-Spam-Status: No, score=-111.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 joDgnYmoLn1w for ; Wed, 28 Aug 2013 04:39:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7003C11E816F for ; Wed, 28 Aug 2013 04:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8673; q=dns/txt; s=iport; t=1377689939; x=1378899539; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=WwW4HDmROhE974yNeI5zn2D+DUpVac6nvm/C6BwPtNI=; b=jwX7vf+Da+gccwhi5E2R9tEMjpWKUc2oNSbdREtne6B27spjjQvb6SG+ njAVhfYtxOfkBb3T4MZX81PRNHykX2ts9q02q3VuyjqDdbLPHxxFv1hOs GAjyuwC+cfyDgjSwUuLgG88ojonhIi0Cpuslw99QLzWsQAXtc2ZMCxOmb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFADfgHVKtJXG//2dsb2JhbABbgwc1g3i9AoEiFnSCJAEBAQQBAQEgDgEBNQYBCgwECw4KAgIUEgICJyIOBhMJEYdnDKZOgh2QHoEpi0IngRqBOAcYglCBMQOUF4N7hgmLN4M8IA X-IronPort-AV: E=Sophos;i="4.89,975,1367971200"; d="scan'208";a="252630714" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 28 Aug 2013 11:38:56 +0000 Received: from [10.0.2.15] (rtp-mcgrew-8912.cisco.com [10.117.10.227]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7SBctAC022390; Wed, 28 Aug 2013 11:38:55 GMT Message-ID: <1377689938.4027.265.camel@darkstar> From: David McGrew To: Robert Moskowitz Date: Wed, 28 Aug 2013 07:38:58 -0400 In-Reply-To: <520E10A2.2030908@htt-consult.com> References: <32A53FD55709804D8533DD5D308A40A216B2F1A1CC@FHDP1LUMXC7V33.us.one.verizon.com> <520E10A2.2030908@htt-consult.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: cfrg@irtf.org Subject: Re: [Cfrg] Fwd: Encryption is less secure than we thought - MIT News Office X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 11:39:04 -0000 Perhaps this thread could be retitled "The MIT News Office is more effective at Marketing Communications than we thought", since they have done a good job at getting us to discuss the work they wanted to highlight ;-) I agree completely with the other comments on the thread that min-entropy is a more appropriate measure than Shannon entropy, and that the latter is already discredited for many cryptographic applications. It seems that the paper is an interesting result on guesswork, and guesswork is interesting because it applies to some (but not all) interesting cryptographic problems. David On Fri, 2013-08-16 at 07:44 -0400, Robert Moskowitz wrote: > So what are the thoughts about this here? I have been asked to do a > little digging amongst my contacts. Seems it clearly states that our > secure communications stuff we do is not affected by this work, but > perhaps secure data objects and various wireless password passing > technologies might be at risk? > > > -------- Original Message -------- > > > > > From Evernote: > Encryption is less secure than we thought - MIT News Office > Clipped from: > http://web.mit.edu/newsoffice/2013/encryption-is-less-secure-than-we-thought-0814.html > > > Encryption is less secure than we thought > For 65 years, most information-theoretic analyses of cryptographic > systems have made a mathematical assumption that turns out to be > wrong. > > > Larry Hardesty, MIT News Office > > > > > Muriel Médard is a professor in the MIT Department of Electrical > Engineering. Photo: Bryce Vickmark > > > Information theory — the discipline that gave us digital communication > and data compression — also put cryptography on a secure mathematical > foundation. Since 1948, when the paper that created information theory > first appeared, most information-theoretic analyses of secure schemes > have depended on a common assumption. > > Unfortunately, as a group of researchers at MIT and the National > University of Ireland (NUI) at Maynooth, demonstrated in a paper > presented at the recent International Symposium on Information Theory > (view PDF ), that assumption is false. In a follow-up paper being > presented this fall at the Asilomar Conference on Signals and Systems, > the same team shows that, as a consequence, the wireless card readers > used in many keyless-entry systems may not be as secure as previously > thought. > > In information theory, the concept of information is intimately > entwined with that of entropy. Two digital files might contain the > same amount of information, but if one is shorter, it has more > entropy. If a compression algorithm — such as WinZip or gzip — worked > perfectly, the compressed file would have the maximum possible > entropy. That means that it would have the same number of 0s and 1s, > and the way in which they were distributed would be totally > unpredictable. In information-theoretic parlance, it would be > perfectly uniform. > > Traditionally, information-theoretic analyses of secure schemes have > assumed that the source files are perfectly uniform. In practice, they > rarely are, but they’re close enough that it appeared that the > standard mathematical analyses still held. > > “We thought we’d establish that the basic premise that everyone was > using was fair and reasonable,” says Ken Duffy, one of the researchers > at NUI. “And it turns out that it’s not.” On both papers, Duffy is > joined by his student Mark Christiansen; Muriel Médard, a professor of > electrical engineering at MIT; and her student Flávio du Pin Calmon. > > The problem, Médard explains, is that information-theoretic analyses > of secure systems have generally used the wrong notion of entropy. > They relied on so-called Shannon entropy, named after the founder of > information theory, Claude Shannon, who taught at MIT from 1956 to > 1978. > > Shannon entropy is based on the average probability that a given > string of bits will occur in a particular type of digital file. In a > general-purpose communications system, that’s the right type of > entropy to use, because the characteristics of the data traffic will > quickly converge to the statistical averages. Although Shannon’s > seminal 1948 paper dealt with cryptography, it was primarily concerned > with communication, and it used the same measure of entropy in both > discussions. > > But in cryptography, the real concern isn’t with the average case but > with the worst case. A codebreaker needs only one reliable correlation > between the encrypted and unencrypted versions of a file in order to > begin to deduce further correlations. In the years since Shannon’s > paper, information theorists have developed other notions of entropy, > some of which give greater weight to improbable outcomes. Those, it > turns out, offer a more accurate picture of the problem of > codebreaking. > > When Médard, Duffy and their students used these alternate measures of > entropy, they found that slight deviations from perfect uniformity in > source files, which seemed trivial in the light of Shannon entropy, > suddenly loomed much larger. The upshot is that a computer turned > loose to simply guess correlations between the encrypted and > unencrypted versions of a file would make headway much faster than > previously expected. > > “It’s still exponentially hard, but it’s exponentially easier than we > thought,” Duffy says. One implication is that an attacker who simply > relied on the frequencies with which letters occur in English words > could probably guess a user-selected password much more quickly than > was previously thought. “Attackers often use graphics processors to > distribute the problem,” Duffy says. “You’d be surprised at how > quickly you can guess stuff.” > > In their Asilomar paper, the researchers apply the same type of > mathematical analysis in a slightly different way. They consider the > case in which an attacker is, from a distance, able to make a “noisy” > measurement of the password stored on a credit card with an embedded > chip or a key card used in a keyless-entry system. > > “Noise” is the engineer’s term for anything that degrades an > electromagnetic signal — such as physical obstructions, out-of-phase > reflections or other electromagnetic interference. Noise comes in lots > of different varieties: The familiar white noise of sleep aids is one, > but so is pink noise, black noise and more exotic-sounding types of > noise, such as power-law noise or Poisson noise. > > In this case, rather than prior knowledge about the statistical > frequency of the symbols used in a password, the attacker has prior > knowledge about the probable noise characteristics of the environment: > Phase noise with one set of parameters is more probable than phase > noise with another set of parameters, which in turn is more probable > than Brownian noise, and so on. Armed with these statistics, an > attacker could infer the password stored on the card much more rapidly > than was previously thought. > > “Some of the approximations that we’re used to making, they make > perfect sense in the context of traditional communication,” says > Matthieu Bloch, an assistant professor of electrical and computer > engineering at the Georgia Institute of Technology. “You design your > system in a framework, and then you test it. But for crypto, you’re > actually trying to prove that it’s robust to things you cannot test. > So you have to be sure that your assumptions make sense from the > beginning. And I think that going back to the assumptions is something > people don’t do often enough.” > > Bloch doubts that the failure of the uniformity assumption means that > cryptographic systems in wide use today are fundamentally insecure. > “My guess is that it will show that some of them are slightly less > secure than we had hoped, but usually in the process, we’ll also > figure out a way of patching them,” he says. The MIT and NUI > researchers’ work, he says, “is very constructive, because it’s > essentially saying, ‘Hey, we have to be careful.’ But it also provides > a methodology to go back and reanalyze all these things.” > > Comments > > > > > Log in to write comments > > > > > > > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From n.mavrogiannopoulos@gmail.com Wed Aug 28 07:45:25 2013 Return-Path: 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 ECF3A11E81B6 for ; Wed, 28 Aug 2013 07:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 4V31k3WEWySl for ; Wed, 28 Aug 2013 07:45:23 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C967D21F9FCA for ; Wed, 28 Aug 2013 07:45:17 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id r11so3859294lbi.18 for ; Wed, 28 Aug 2013 07:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WeZLN6wq9Oy/zF7/qW8chtMng/5sAnmt1X5WPagrTUk=; b=ogr4tr7iajgJD2qVjDGGq0AgKN1mmwbDw/VDyS+YTLzXU9IipUH6CObRpr5R6Hv1B/ bIjnEihjPWllt6AnBfks4EjYUVDOcMyYAbdcJECjFNiJf79aizjvNfvPHSX1v7mTFtF4 8ACH7Q+GGVm2z4kmob5biDF1t4DCIk+mE3cxTHKDrqZBWaIFGW5+ACngFsWSDf8CfZ1M 9pcmXXEeoR4Rzj+wuthglHeF7GsCX30wwyhuDziImabk+xvbOuf8mpgzlLMmbR34tkT5 xtF4ftLbWQYHj/VF5Ql3qseF4xOft/M7mL8ROBt4gj9u326yAmxqOXGSSLdT40pkuBIW LPUQ== MIME-Version: 1.0 X-Received: by 10.152.6.202 with SMTP id d10mr66765laa.49.1377701115336; Wed, 28 Aug 2013 07:45:15 -0700 (PDT) Received: by 10.112.63.66 with HTTP; Wed, 28 Aug 2013 07:45:15 -0700 (PDT) In-Reply-To: <1377532182.4027.103.camel@darkstar> References: <3C4AAD4B5304AB44A6BA85173B4675CAB247161D@MSMR-GH1-UEA03.corp.nsa.gov> <1376512356.16950.360.camel@darkstar> <1377532182.4027.103.camel@darkstar> Date: Wed, 28 Aug 2013 17:45:15 +0300 Message-ID: From: Nikos Mavrogiannopoulos To: David McGrew Content-Type: multipart/alternative; boundary=089e01419b1c961cd104e503093b Cc: "cfrg@irtf.org" Subject: Re: [Cfrg] problems with draft-josefsson-salsa20-tls-02 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 14:45:25 -0000 --089e01419b1c961cd104e503093b Content-Type: text/plain; charset=UTF-8 On Mon, Aug 26, 2013 at 6:49 PM, David McGrew wrote: > Hi Nikos, > If there is a compelling benefit to using these ciphersuites, it > deserves to be quantified. > > > There are benchmarks in the estream framework we can link to [0] if it > > is deemed necessary. > > > > [0]. http://www.ecrypt.eu.org/stream/perf/ > > It definitely would be good to reference the ESTREAM performance > comparisons, but the draft should also explain what platform(s) are the > performance targets. Is the goal of the draft to minimize CPU > utilization, and thus power usage, on mobile clients, without regard to > servers? Or perhaps there is another goal; I'm speculating here. > Hello David, I don't think that this is the purpose of this draft. This draft merely defines how to use salsa20 in TLS. There is a lot of controversy on whether a cipher is fast/slow or whatever on a particular platform (depending on the implementation, power usage), and personal taste :) If we'd try to quantify those things in this draft it would take more effort and heat than needed. If as you imply salsa20 is not as fast in some platforms, then things are simple, it will not be used in those platforms. The intention is to define salsa20 to be used in the platforms that is faster than AES. > > I don't quite understand that. Could you elaborate on the particulars? > > Why do you think that the TLS GenericStreamCipher is vulnerable to > > side-channel attacks (and the GenericAEADCipher is not?). I believe > > your comment is towards the general constructions (and more precisely > > you mean the GenericBlockCipher) rather than this particular > > ciphersuite. > > > One of the important properties of a sound authenticated encryption > scheme is that the decryption operation does not release any > (potentially invalid) plaintext data until the authentication check is > complete. The GenericStreamCipher does not require an implementation to > have this property. I believe that you have misunderstood how the GenericStreamCipher operates in TLS. No TLS implementation releases plaintext data that have not been authenticated in GenericStreamCipher or any other mode. This was one of the initial goals in TLS, and that is the reason that (unlike IPSec) there aren't any ciphersuites that do not provide authentication. > Only if you can work in clean slate. Unfortunately that doesn't happen > in practice. In practice one would add the ciphersuite in an existing > implementation that may not support TLS 1.2. The point that I wanted to make is: instead of re-defining the > GenericStreamCipher and MAC algorithms for TLS v 1.0 and 1.1, > GenericAEADCipher can be added to those versions of the protocol. That > would enable a TLS implementation that supports the current version of > the protocol to use its GenericAEADCipher for all three versions, and > relieve that implementation of the need to support an updated definition > for GenericStreamCipher and MAC. > That is a nice idea, and we can consider this option when this is done. However, as you previously argued it would be good to have a GenericAEADCipher that uses the TLS sequence numbers instead of another explicit nonce to save bytes. > > The draft has no mechanism to allow multiple encrypters to > > work in > > parallel, such as is provided in Section 6.2 of RFC5288. > > Actually RFC5288 needs this section because it uses a random nonce. > No, RFC5288 uses a deterministic nonce. > As far as I understand RFC5288 doesn't use a deterministic nonce. It allows the implementer to use any nonce he likes. It merely suggests (with a MAY) to copy the TLS sequence number as nonce. > Since the salsa draft doesn't use a random nonce it doesn't require > such a special provision for parallel encryptors. Parallel encryptors > come for free in the salsa20 draft. > No, each Salsa20 nonce MUST be distinct, and the draft makes no > provision to ensure that they can be distinct when multiple encrypters > are in use. Rather than being "for free", the draft provides no way to > allow for an implementation to use parallel encryptors and to maintain > security. > I don't quite understand your objection. Since each TLS record has a distinct and unique sequence number (and thus nonce), it is pretty straightforward to map each record on a different CPUs for encryption. There is nothing non-obvious needed to clarify there (unless I don't understand your point). regards, Nikos --089e01419b1c961cd104e503093b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 26, 2013 at 6:49 PM, David McGrew <mcgrew@cisco.com> = wrote:
Hi Nikos,
If there is a comp= elling benefit to using these ciphersuites, it
deserves to be quantified.

> There are benchmarks in the estream framework we can link to [0] if it=
> is deemed necessary.
>
> [0]. http://www.ecrypt.eu.org/stream/perf/

It definitely would be good to reference the ESTREAM performance
comparisons, but the draft should also explain what platform(s) are the
performance targets. =C2=A0 Is the goal of the draft to minimize CPU
utilization, and thus power usage, on mobile clients, without regard to
servers? =C2=A0 Or perhaps there is another goal; I'm speculating here.=

Hello David,
=C2=A0I don't thin= k that this is the purpose of this draft. This draft merely defines how to = use salsa20 in TLS. There is a lot of controversy on whether a cipher is fa= st/slow or whatever on a particular platform (depending on the implementati= on, power usage), and personal taste :) If we'd try to quantify those t= hings in this draft it would take more effort and heat than needed. If as y= ou imply salsa20 is not as fast in some platforms, then things are simple, = it will not be used in those platforms. The intention is to define salsa20 = to be used in the platforms that is faster than AES.
=C2=A0
> I don't quite understand that. Could you = elaborate on the particulars?
> Why do you think that the TLS GenericStreamCipher is vulnerable to
> side-channel attacks (and the GenericAEADCipher is not?). I believe > your comment is towards the general constructions (and more precisely<= br> > you mean the GenericBlockCipher) rather than this particular
> ciphersuite.
>
One of the important properties of a sound authenticated encryp= tion
scheme is that the decryption operation does not release any
(potentially invalid) plaintext data until the authentication check is
complete. =C2=A0The GenericStreamCipher does not require an implementation = to
have this property.

I believe that you have= misunderstood how the GenericStreamCipher operates in TLS. No TLS implemen= tation releases plaintext data that have not been authenticated in GenericS= treamCipher or any other mode. This was one of the initial goals in TLS, an= d that is the reason that (unlike IPSec) there aren't any ciphersuites = that do not provide authentication.

> Only if you can work in clean slate. Unfor= tunately that doesn't happen
> in practice. In practice one would add the ciphersuite in an existing<= br> > implementation that may not support TLS 1.2.

The point that I wa= nted to make is: instead of re-defining the
GenericStreamCipher and MAC algorithms for TLS v 1.0 and 1.1,
GenericAEADCipher can be added to those versions of the protocol. =C2=A0 Th= at
would enable a TLS implementation that supports the current version of
the protocol to use its GenericAEADCipher for all three versions, and
relieve that implementation of the need to support an updated definition for GenericStreamCipher and MAC.

That i= s a nice idea, and we can consider this option when this is done. However, = as you previously argued it would be good to have a GenericAEADCipher that = uses the TLS sequence numbers instead of another explicit nonce to save byt= es.

=C2=A0
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 The draft has no mechani= sm to allow multiple encrypters to
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 work in
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 parallel, such as is provided in Section 6= .2 of RFC5288.
> Actually RFC5288 needs this section because it uses a random nonce. No, RFC5288 uses a deterministic nonce.

As far as I understand RFC5288 doesn't use a deterministic nonce= . It allows the implementer to use any nonce he likes. It merely suggests (= with a MAY) to copy the TLS sequence number as nonce.
=C2=A0
> =C2=A0Since the salsa draft doesn't use a random nonce it doesn= 9;t require
> such a special provision for parallel encryptors. Parallel encryptors<= br> > come for free in the salsa20 draft.
No, each Salsa20 no= nce MUST be distinct, and the draft makes no
provision to ensure that they can be distinct when multiple encrypters
are in use. =C2=A0Rather than being "for free", the draft provide= s no way to
allow for an implementation to use parallel encryptors and to maintain
security.

I don't quite understand = your objection. Since each TLS record has a distinct and unique sequence nu= mber (and thus nonce), it is pretty straightforward to map each record on a= different CPUs for encryption. There is nothing non-obvious needed to clar= ify there (unless I don't understand your point).

regards,
Nikos

--089e01419b1c961cd104e503093b-- From housley@vigilsec.com Wed Aug 28 10:17:53 2013 Return-Path: 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 13A5121E804D for ; Wed, 28 Aug 2013 10:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Rm3acad3R5-x for ; Wed, 28 Aug 2013 10:17:48 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1A51E21F9C54 for ; Wed, 28 Aug 2013 10:17:48 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id DB976F240B4; Wed, 28 Aug 2013 13:17:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id Q3PgJlhL858l; Wed, 28 Aug 2013 13:17:37 -0400 (EDT) Received: from [192.168.38.134] (static-108-15-20-23.bltmmd.fios.verizon.net [108.15.20.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B01F9F240BB; Wed, 28 Aug 2013 13:17:49 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <1377688770.4027.258.camel@darkstar> Date: Wed, 28 Aug 2013 13:17:44 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <1377688770.4027.258.camel@darkstar> To: David McGrew X-Mailer: Apple Mail (2.1085) Cc: cfrg Subject: Re: [Cfrg] minutes from meeting at 87th IETF X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 17:17:53 -0000 The minutes have a formatting issue. Also, the minutes say: 1) The CFRG is a research group, supporting a hook for Randomized Hashing in future protocols amounts to little more than building in a2 octet TLV withe the length set to zero. If at some future time RH becomes necessary, the TLV, now with non-zero length, would support a rapid transition to Randomized Hashing. We looked at this for PKIX and S/MIME, and it is not that simple. When the hash is used as part of a signature scheme, the random value needs to be carried as a parameter to the signature algorithm. Russ On Aug 28, 2013, at 7:19 AM, David McGrew wrote: > http://www.ietf.org/proceedings/87/minutes/minutes-87-cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg