From jon@callas.org Fri Jul 1 15:27:37 2011 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 3A7D111E80FB for ; Fri, 1 Jul 2011 15:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToDDN6JOb-kc for ; Fri, 1 Jul 2011 15:27:35 -0700 (PDT) Received: from merrymeet.com (unknown [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 45F4811E8085 for ; Fri, 1 Jul 2011 15:27:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 9D3EB2E107 for ; Fri, 1 Jul 2011 15:28:11 -0700 (PDT) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 09750-01 for ; Fri, 1 Jul 2011 15:28:09 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 4381F2E101 for ; Fri, 1 Jul 2011 15:28:09 -0700 (PDT) Received: from ba0301b-dhcp217.apple.com ([17.193.15.217]) by keys.merrymeet.com (PGP Universal service); Fri, 01 Jul 2011 15:27:31 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 01 Jul 2011 15:27:31 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Jon Callas In-Reply-To: Date: Fri, 1 Jul 2011 15:27:30 -0700 Message-Id: <597874AF-C28E-43AE-AD8F-402D1A89C8E9@callas.org> References: To: "Severns-Williams, Christine E (Christine)" X-Mailer: Apple Mail (2.1084) X-PGP-Encoding-Format: MIME X-PGP-Encoding-Version: 2.0.2 Content-Type: multipart/signed; boundary="PGP_Universal_90FBED5B_ECF6AB71_D065C845_62C6BB0F"; protocol="application/pgp-signature"; micalg="pgp-sha1" X-Virus-Scanned: Maia Mailguard Cc: cfrg@irtf.org Subject: Re: [Cfrg] SRTP with SHA2? 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, 01 Jul 2011 22:27:37 -0000 --PGP_Universal_90FBED5B_ECF6AB71_D065C845_62C6BB0F Content-Type: multipart/alternative; boundary=Apple-Mail-39-539568374 --Apple-Mail-39-539568374 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 30, 2011, at 10:40 AM, Severns-Williams, Christine E (Christine) = wrote: > Hi All, > I=92m not sure this is really the right mail list for this question. = But I see SHA2 being added to many security protocols (IPsec, TLS, etc) = and discussion of other algorithms fading such as MD5. > =20 > I know SRTP supports AES-CM (128, 192, 256), AES-f8, and there is a = draft for AES-CCM and AES-GCM (128 and 256). > =20 > Has anyone considered or is looking at using/adding SHA2 to the SRTP = protocol? Just curious. > =20 > I know the digest size is larger but it could still be truncated.=20 You could, but there's no real need, and a number of reasons not to. SRTP uses HMAC-SHA1 for integrity, and even provides for truncated = integrity. If you believe that 80 bits of security is enough and that = lots of times 32 bits is fine, then SHA256 is overkill. HMACs don't have = the weaknesses that a straight hash does. You don't gain anything by = using a truncated SHA256, security-wise. (The truncated integrity is reasonable in many applications, = particularly those where the payload is simply media. If the media has = other integrity checks in it, even better. Suppose, for example, that = the total payload was audio on the X codec, and if the X codec gets = thrown into a bogus state, it will discard the packet. In this case, not = only does the codec supply secondary authentication, but should a bad = packet actually be inserted into the media stream, the only effect of = that is an audio glitch. Almost certainly that glitch will just be a = blip of noise.) However, SHA256 is slower than SHA1, and since you're using it in an = HMAC, you're having to do two hashes. That's big, from a performance = point of view. In many environments, the lion's share of the crypto cost for SRTP is = that SHA1 HMAC. It is often over 2/3 of the total cost. Switching to = SHA256 could bring the integrity cost to 80% or more of the total crypto = cost, as well as driving it up, not down. The real need for SRTP is to find an integrity check that's faster. = That's something that ZRTP (RFC 6189) does. (Full disclosure: I'm a ZRTP = co-author.) Some ZRTP implementations found that 75% of the cost of the = crypto was that HMAC. So ZRTP provides the option to use the one-pass = MAC feature of the Skein-512 hash function, which is one of the SHA3 = finalists. (Full disclosure: I'm a Skein co-author, as well.) Not only = is Skein-512 faster than SHA1, often running at 2/3 the speed of SHA1, = but the one-pass MAC means you're only doing one hash, not two. That = means that a Skein-MAC has only 1/3 the cost of HMAC-SHA1! It also has = at least as good security as SHA256, so you get both better security and = better performance. (In the name of the algorithm, the -512 refers to the internal state = size of Skein, not the output size. All three variants of Skein (256, = 512, 1024) can have any length output. When you might want whatever = internal state size is a long discussion that I could bore you at great = length on. I believe that Skein-512 is adequate for any reasonable use.) Jon --Apple-Mail-39-539568374 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi All,
 
I know SRTP = supports AES-CM (128, 192, 256), AES-f8, and there is a draft for = AES-CCM and AES-GCM (128 and 256).
Has anyone considered or is looking = at using/adding SHA2 to the SRTP protocol?     Just = curious.
 
I = know the digest size is larger but it could still be = truncated. 

You could, but there's no real need, and a number of reasons not = to.

SRTP uses HMAC-SHA1 for integrity, and even = provides for truncated integrity. If you believe that 80 bits of = security is enough and that lots of times 32 bits is fine, then SHA256 = is overkill. HMACs don't have the weaknesses that a straight hash does. = You don't gain anything by using a truncated SHA256, = security-wise.

(The truncated integrity is = reasonable in many applications, particularly those where the payload is = simply media. If the media has other integrity checks in it, even = better. Suppose, for example, that the total payload was audio on the X = codec, and if the X codec gets thrown into a bogus state, it will = discard the packet. In this case, not only does the codec supply = secondary authentication, but should a bad packet actually be inserted = into the media stream, the only effect of that is an audio glitch. = Almost certainly that glitch will just be a blip of = noise.)

However, SHA256 is slower than SHA1, = and since you're using it in an HMAC, you're having to do two hashes. = That's big, from a performance point of = view.

In many environments, the lion's share of = the crypto cost for SRTP is that SHA1 HMAC. It is often over 2/3 of the = total cost. Switching to SHA256 could bring the integrity cost to 80% or = more of the total crypto cost, as well as driving it up, not = down.

The real need for SRTP is to find an = integrity check that's faster. That's something that ZRTP (RFC 6189) = does. (Full disclosure: I'm a ZRTP co-author.) Some ZRTP implementations = found that 75% of the cost of the crypto was that HMAC. So ZRTP provides = the option to use the one-pass MAC feature of the Skein-512 hash = function, which is one of the SHA3 finalists. (Full disclosure: I'm a = Skein co-author, as well.) Not only is Skein-512 faster than SHA1, often = running at 2/3 the speed of SHA1, but the one-pass MAC means you're only = doing one hash, not two. That means that a Skein-MAC has only 1/3 the = cost of HMAC-SHA1! It also has at least as good security as SHA256, so = you get both better security and better = performance.

(In the name of the algorithm, the = -512 refers to the internal state size of Skein, not the output size. = All three variants of Skein (256, 512, 1024) can have any length output. = When you might want whatever internal state size is a long discussion = that I could bore you at great length on. I believe that Skein-512 is = adequate for any reasonable use.)

= Jon


= --Apple-Mail-39-539568374-- --PGP_Universal_90FBED5B_ECF6AB71_D065C845_62C6BB0F Content-Type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig Content-Disposition: attachment; filename=PGP.sig -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.10.0 (Build 554) iQA/AwUBTg5J07E3nVmTg94GEQK0KgCg3DPcJsL9Icfq8hHiKvnpNCFJ/WkAoKoM 4yMOnKwRW0k9e3nSsMs8+sKT =PmiU -----END PGP SIGNATURE----- --PGP_Universal_90FBED5B_ECF6AB71_D065C845_62C6BB0F-- From turners@ieca.com Wed Jul 6 10:13:17 2011 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 D269821F85C5 for ; Wed, 6 Jul 2011 10:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.576 X-Spam-Level: X-Spam-Status: No, score=-101.576 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxIBckFqkWBW for ; Wed, 6 Jul 2011 10:13:17 -0700 (PDT) Received: from nm1-vm0.bullet.mail.ne1.yahoo.com (nm1-vm0.bullet.mail.ne1.yahoo.com [98.138.91.74]) by ietfa.amsl.com (Postfix) with SMTP id E637421F85BC for ; Wed, 6 Jul 2011 10:13:16 -0700 (PDT) Received: from [98.138.90.51] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jul 2011 17:13:13 -0000 Received: from [98.138.89.244] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jul 2011 17:13:13 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 06 Jul 2011 17:13:13 -0000 X-Yahoo-Newman-Id: 745329.2793.bm@omp1058.mail.ne1.yahoo.com Received: (qmail 22420 invoked from network); 6 Jul 2011 17:13:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1309972393; bh=l6fP5DS33RJBdSkofGDhCaeOMU6j/LVj1+PdHNxQ9xw=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Forwarded-Message-Id:Content-Type:Content-Transfer-Encoding; b=NhjRYFCMs86OUtK8tbbdAS8FjWTJWIN5yFJ/IZP3pExqBUpO7feJs8eNp41KqPFFthWsLeqwhwM3I2yqAWDuC7qWAkRok5OHnM9w4Th8gyFxcPLEvugZWff7DT5g/UrRsndzEyrGP9H68ETpns9gjkqXY6m1T1MfOdo1BVDty1U= Received: from thunderfish.westell.com (turners@96.241.1.93 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 06 Jul 2011 10:13:12 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: .1Pr14MVM1nYzQar3ro3NANfa3i8F_dJ5wANHf4jy9.Knkr 08xfByOHVZUsGAvMZx__dy5tcwb8XEiyFL7Pv23AMx.p0KDHAiMdkY3xClqc PIn4QQsQRkxBu9O34Jvegw5meVv31nCX3qKR8CvqnpPzg1wrr7yLhbjpV8jI MdS.PAUPydpBwIfTVKL1WWC7AB6BSFMQTQgM9an.p80kX.3DI4G4pxrYe8IV cJnLQ8PficwKQOgK2Wu_OSiYTbILaZC9KttZabY8qMfRc91cQH.Jm.3eMrpz 9xaHm2Rx7ShDTQ7BUsHh4r90LlLJA_SE3MZhW7nYojMoVdkvTnVuTIE1zbdj YvvgGpkaSW9pMl_hr9nm5AFHPOaNJMM3v64oWNQBN X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E1497A7.6050802@ieca.com> Date: Wed, 06 Jul 2011 13:13:11 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: cfrg@irtf.org References: <20110706150842.3460.77968.idtracker@ietfa.amsl.com> In-Reply-To: <20110706150842.3460.77968.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110706150842.3460.77968.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Cfrg] Fwd: I-D Action: draft-kutylowski-mrsa-algorithm-00.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: Wed, 06 Jul 2011 17:13:18 -0000 This might be of interest to some on the list. spt -------- Original Message -------- Subject: I-D Action: draft-kutylowski-mrsa-algorithm-00.txt Date: Wed, 06 Jul 2011 08:08:42 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mediated RSA cryptography specification for additive private key splitting (mRSAA) Author(s) : Miroslaw Kutylowski Przemyslaw Kubiak Michal Tabor Daniel Wachnik Filename : draft-kutylowski-mrsa-algorithm-00.txt Pages : 58 Date : 2011-07-06 This document describes recommendations for the implementation of public key cryptography based on the mediated RSA algorithm. The Mediated RSA algorithm bases on fragmentation of a private key. As a result the signature process consists from multiple stages. The verification process is the same as in the case of RSA algorithm [RFC 3447]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kutylowski-mrsa-algorithm-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-kutylowski-mrsa-algorithm-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From mcgrew@cisco.com Tue Jul 12 14:34:47 2011 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 CD08F21F8C3C for ; Tue, 12 Jul 2011 14:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZbqjsuo8fj7 for ; Tue, 12 Jul 2011 14:34:43 -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 F340C21F8C76 for ; Tue, 12 Jul 2011 14:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=6384; q=dns/txt; s=iport; t=1310506483; x=1311716083; h=message-id:from:to:mime-version:subject:date:references; bh=N2ZjAHGjvKwPXC9zb5V98tyck9YDYb06yPOE39Rfs6s=; b=htvyfBTdhDkbwUgIUX10UotlFclTI5/xiQXxO3QJVb9u5wmGl4hQe6EO NKYHoIAg3ugsHNNLi1e9E0+JsTs9I11CuARGkAXWEHnFITZzNWyOunxVf qoJBVR3E/mG+vj9UoMsmbjs6D29k/0L/PAEoDRIs2BjqHllvMhpVwSyHd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4HAPm8HE6rRDoI/2dsb2JhbABTglOVZYZhAYgZd4h6pBaeBoVbXwSCTYUEiw+QbA X-IronPort-AV: E=Sophos;i="4.65,522,1304294400"; d="scan'208,217";a="2308075" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jul 2011 21:34:42 +0000 Received: from HAL.lasvegas.ciscolive2011.com ([10.86.244.204]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6CLYeD6023344 for ; Tue, 12 Jul 2011 21:34:41 GMT Message-Id: <3898F2FB-7A12-4B07-9ED5-A8CE9260B401@cisco.com> From: David McGrew To: cfrg@irtf.org Content-Type: multipart/alternative; boundary=Apple-Mail-17--660685530 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 12 Jul 2011 14:34:39 -0700 References: <1310505863690.971277.6439802.bulletin.csrc.nist@service.govdelivery.com> X-Mailer: Apple Mail (2.936) Subject: [Cfrg] Fwd: Special Publication 800-56C 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, 12 Jul 2011 21:34:47 -0000 --Apple-Mail-17--660685530 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, a document that may be of interest to you: second draft of NIST's "Recommendation for Key Derivation through Extraction-then-Expansion", which is compatible with RFC 5869 "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", which was discussed on this list a couple of years back. Comments period ends on August 11. http://csrc.nist.gov/news_events/index.html#july12 David Begin forwarded message: > From: NIST Computer Security Resource Center > > Date: July 12, 2011 2:25:06 PM PDT > To: nist-interest@cisco.com > Subject: NIST Released 2 Draft Special Publications: 800-126 Rev. 2 > and Special Publication 800-56C > Reply-To: NIST Computer Security Resource Center > > > Today, NIST Computer Security Division released 2 Draft Special > Publications. See below for the details. Each draft will have 2 > URLs - one will take you to the full announcement on the CSRC News > page and the second URL will take you to the same announcement on > the CSRC Drafts page. The announcement and link are the same > announcement for each draft. > > Draft #1: Second Draft Special Publication 800-56C, Recommendation > for Key Derivation through Extraction-then-Expansion > > CSRC News page for this Draft document: > http://csrc.nist.gov/news_events/index.html#july12 > - OR - > CSRC Drafts page for this Draft document: > http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-56-C > --Apple-Mail-17--660685530 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable http://csrc.ni= st.gov/news_events/index.html#july12

David

Begin forwarded message:

From: = NIST Computer Security Resource Center <csrc.nist@service.govdel= ivery.com>
Date: July 12, 2011 2:25:06 PM = PDT
Subject: NIST Released 2 Draft Special = Publications: 800-126 Rev. 2 and Special Publication = 800-56C
Reply-To: NIST Computer Security Resource Center = <csrc.nist@service.govdel= ivery.com>

Today, NIST Computer Security = Division released 2 Draft Special Publications.  See below for the = details.  Each draft will have 2 URLs - one will take you to the = full announcement on the CSRC News page and the second URL will take you = to the same announcement on the CSRC Drafts page.  The announcement = and link are the same announcement for each draft.

Draft #1: Second Draft Special = Publication 800-56C, Recommendation for Key Derivation through = Extraction-then-Expansion

CSRC News page for this = Draft document:
http://csrc.ni= st.gov/news_events/index.html#july12
- = OR -
CSRC Drafts page for this Draft = document:
htt= p://csrc.nist.gov/publications/PubsDrafts.html#SP-800-56-C

<= /div>

= --Apple-Mail-17--660685530-- From ted@krovetz.net Wed Jul 13 09:42:25 2011 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 3F2CA11E817A for ; Wed, 13 Jul 2011 09:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TutsqkorWiWt for ; Wed, 13 Jul 2011 09:42:24 -0700 (PDT) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 89A8411E8175 for ; Wed, 13 Jul 2011 09:42:24 -0700 (PDT) Received: by iwr19 with SMTP id 19so7367836iwr.13 for ; Wed, 13 Jul 2011 09:42:24 -0700 (PDT) Received: by 10.231.121.38 with SMTP id f38mr1167562ibr.26.1310575344041; Wed, 13 Jul 2011 09:42:24 -0700 (PDT) Received: from [192.168.11.149] (adsl-75-5-246-246.dsl.scrm01.sbcglobal.net [75.5.246.246]) by mx.google.com with ESMTPS id v3sm2011311ibh.50.2011.07.13.09.42.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jul 2011 09:42:23 -0700 (PDT) From: Ted Krovetz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2011 09:42:21 -0700 Message-Id: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> To: cfrg@irtf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Cfrg] Request For Comments: OCB Internet-Draft 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, 13 Jul 2011 16:43:21 -0000 I have just submitted an internet-draft for OCB to the IETF. http://datatracker.ietf.org/doc/draft-krovetz-ocb I'd appreciate any comments you may have on how to make the draft = better. OCB is a blockcipher-based authenticated-encryption scheme. It is = significantly faster than any other blockcipher-based AE scheme that I = am aware of. On Intel's current Sandy Bridge processors it encrypts and = authenticates 4K messages at 0.9 cpu cycles per byte of message, and = processes a weighted mix of message lengths at 1.3 cpb (5% 44B, 15% = 552B, 20% 576B, 60% 1500B). OCB has undegone refinements over the years to allow authentication of = associated data and improved performance. This is the second (and last) = revision. It was presented at FSE this year http://www.cs.ucdavis.edu/~rogaway/papers/ae.pdf Associated notes and performace data are at http://www.cs.ucdavis.edu/~rogaway/ocb/performance We intend to convert the internet-draft into an RFC and also submit OCB = to the NIST blockcipher modes-of-operation project. There are several patents that may apply to OCB. We are in the process = of trying to get all parties to pool their patents and liberalize their = use. Thank you, Ted Krovetz= From pgut001@login01.cs.auckland.ac.nz Wed Jul 13 20:49:00 2011 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 6458511E8178 for ; Wed, 13 Jul 2011 20:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9W3sQ7Vma8iH for ; Wed, 13 Jul 2011 20:48:58 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8907911E8134 for ; Wed, 13 Jul 2011 20:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1310615338; x=1342151338; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20cfrg@irtf.org,=20ted@krovetz.net|Subject:=20Re:=20 [Cfrg]=20Request=20For=20Comments:=20OCB=20Internet-Draft |In-Reply-To:=20<22798CA3-3D49-4652-A5DB-EC25ACCD245C@kro vetz.net>|Message-Id:=20|Date:=20Thu,=2014=20Jul=202011=2015:48:49 =20+1200; bh=N2ODscZzLg+8FVv/4S1IzBUjm0+pz8cYUmspqNV6Cfg=; b=QgoQ5iFem/vWn5S1Rr9hwUQaVs3B6DKZtmfxH9i2thEyUz+PiorPcyec GadWx9evamFOidf8BXsVVQOv8iGh9qYDPE+VikJn8DZYxXSctYht9ddbm pU6PbSFzN8mCAksGMhE18/+IQC44FVyPVXm+KefLv5v1qol2UFiMJZ0w0 0=; X-IronPort-AV: E=Sophos;i="4.65,527,1304251200"; d="scan'208";a="71694715" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Jul 2011 15:48:49 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QhCuv-0005Rn-If; Thu, 14 Jul 2011 15:48:49 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QhCuv-0004w6-O5; Thu, 14 Jul 2011 15:48:49 +1200 From: Peter Gutmann To: cfrg@irtf.org, ted@krovetz.net In-Reply-To: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> Message-Id: Date: Thu, 14 Jul 2011 15:48:49 +1200 Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 14 Jul 2011 03:49:00 -0000 Ted Krovetz writes: >I have just submitted an internet-draft for OCB to the IETF. OCB is a nice mode, I've always wanted to use it, but: >There are several patents that may apply to OCB. We are in the process of >trying to get all parties to pool their patents and liberalize their use. without the ability to use it without encumbrance I'll stick with CBC+HMAC or GCM. I know you can use OCB under the GPL but that's too much of a hassle to try and sort out for each user, it'd have to be completely unencumbered to make it useful. (I'm not saying this out of some rabid anti-patent position but purely an anti-headache position, since there are unencumbered, if less efficient, alternatives available I'll go with those and avoid the hassle). Peter. From simon@josefsson.org Thu Jul 14 01:00:57 2011 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 CA0D721F8B1E for ; Thu, 14 Jul 2011 01:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2J77JqUMR1T for ; Thu, 14 Jul 2011 01:00:56 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id 61B3A21F87B9 for ; Thu, 14 Jul 2011 01:00:56 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6E80ivi022903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Jul 2011 10:00:47 +0200 From: Simon Josefsson To: Ted Krovetz References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110714:ted@krovetz.net::LmwBelTXXr9TY1TP:1/3C X-Hashcash: 1:22:110714:cfrg@irtf.org::8dthKddPnStC7NPU:7PYP Date: Thu, 14 Jul 2011 10:00:44 +0200 In-Reply-To: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> (Ted Krovetz's message of "Wed, 13 Jul 2011 09:42:21 -0700") Message-ID: <87ipr5gukz.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: cfrg@irtf.org Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 14 Jul 2011 08:00:57 -0000 Ted Krovetz writes: > I have just submitted an internet-draft for OCB to the IETF. > > http://datatracker.ietf.org/doc/draft-krovetz-ocb > > I'd appreciate any comments you may have on how to make the draft better. It would help if you explained (in the security considerations) what happens if a nonce is repeated. The question of failure modes of authenticated encryption modes has come up in several different contexts. It turns out that different AEAD modes have different failure properties. In particular, you want to address whether repeat of a nonce leads to immediate key disclosure, or whether the key can be found after some computation faster than obvious attacks, or whether it can only lead to recovery of the plaintext, and/or whether it depends on the plaintext as well (e.g., something interesting happens if the plaintexts are related). > There are several patents that may apply to OCB. We are in the process > of trying to get all parties to pool their patents and liberalize > their use. Which patents? According to the patent disclosure search, only these have been disclosed: https://datatracker.ietf.org/ipr/559/ https://datatracker.ietf.org/ipr/560/ If you are aware of other patents (or applications) that applies, it would help if you send in a patent disclosure about it. Thanks, /Simon From yaronf.ietf@gmail.com Thu Jul 14 12:42:06 2011 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 9522F21F8C35 for ; Thu, 14 Jul 2011 12:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2drL0WJ16ci for ; Thu, 14 Jul 2011 12:42:02 -0700 (PDT) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 77BDB21F8C02 for ; Thu, 14 Jul 2011 12:42:02 -0700 (PDT) Received: by wwe6 with SMTP id 6so615316wwe.19 for ; Thu, 14 Jul 2011 12:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=oq3QPFBZzwOddnCeZoKCr8jx5J44CT/DDZ2gcInmIIo=; b=s7P5X2b0hGv9II72kqwRI3QYksfeqQ47ZCJlc87l4eTePQpVHFnxAemzmeiKrmL6kq FZvqPF4ZDJBp6C5jxY/cw3fXrCxraJt+FYyx7yx8xfQ1wRwybIei53Vp6kmDXaSoKsi7 y3ctZ04Za0WWhTgKbJxCmXegPli15dx/cYOb0= Received: by 10.227.157.75 with SMTP id a11mr2379302wbx.74.1310672521289; Thu, 14 Jul 2011 12:42:01 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-192-3.red.bezeqint.net [79.178.192.3]) by mx.google.com with ESMTPS id fc2sm474208wbb.52.2011.07.14.12.41.59 (version=SSLv3 cipher=OTHER); Thu, 14 Jul 2011 12:42:00 -0700 (PDT) Message-ID: <4E1F467C.8090702@gmail.com> Date: Thu, 14 Jul 2011 22:41:48 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: cfrg@irtf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Cfrg] Repeated one-time pad 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, 14 Jul 2011 19:42:06 -0000 Regarding "immediate key disclosure": is is well known that reuse of a stream cipher or a one-time pad with different plaintexts leads to immediate exposure of the plaintext (see e.g. http://en.wikipedia.org/wiki/One-time_pad#True_randomness). For a course I am teaching, I would appreciate pointers to the algorithms that are used for this cryptanalysis and/or source code that implements this attack. Thanks, Yaron Message: 2 Date: Thu, 14 Jul 2011 10:00:44 +0200 From: Simon Josefsson To: Ted Krovetz Cc: cfrg@irtf.org Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft Message-ID: <87ipr5gukz.fsf@latte.josefsson.org> Content-Type: text/plain Ted Krovetz writes: >> I have just submitted an internet-draft for OCB to the IETF. >> >> http://datatracker.ietf.org/doc/draft-krovetz-ocb >> >> I'd appreciate any comments you may have on how to make the draft better. > It would help if you explained (in the security considerations) what > happens if a nonce is repeated. The question of failure modes of > authenticated encryption modes has come up in several different > contexts. It turns out that different AEAD modes have different failure > properties. > > In particular, you want to address whether repeat of a nonce leads to > immediate key disclosure, or whether the key can be found after some > computation faster than obvious attacks, or whether it can only lead to > recovery of the plaintext, and/or whether it depends on the plaintext as > well (e.g., something interesting happens if the plaintexts are related). > From Kenny.Paterson@rhul.ac.uk Thu Jul 14 13:45:09 2011 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 54F2111E80B9 for ; Thu, 14 Jul 2011 13:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN2gK3O8re2b for ; Thu, 14 Jul 2011 13:45:05 -0700 (PDT) Received: from thb-mta-17.emailfiltering.com (thb-mta-17-tx.emailfiltering.com [194.116.199.149]) by ietfa.amsl.com (Postfix) with ESMTP id A400111E8076 for ; Thu, 14 Jul 2011 13:45:04 -0700 (PDT) Received: from exch-hub03.rhul.ac.uk ([134.219.208.197]) by thb-mta-17.emailfiltering.com with emfmta (version 4.8.2.32) by TLS id 2729483854 for cfrg@irtf.org;661b981000e3b098; Thu, 14 Jul 2011 21:45:03 +0100 Received: from EXCH-CAS02.cc.rhul.local (2002:86db:d06a::86db:d06a) by EXCH-HUB03.cc.rhul.local (2002:86db:d0c5::86db:d0c5) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 14 Jul 2011 21:45:02 +0100 Received: from EXCH-MB02.cc.rhul.local ([169.254.1.74]) by EXCH-CAS02.cc.rhul.local ([2002:86db:d06a::86db:d06a]) with mapi id 14.01.0289.001; Thu, 14 Jul 2011 21:45:02 +0100 From: "Paterson, Kenny" To: Yaron Sheffer , "cfrg@irtf.org" Thread-Topic: [Cfrg] Repeated one-time pad Thread-Index: AQHMQl4mKypVgrLX/ki5bnUr4jtHipTsOE2A Date: Thu, 14 Jul 2011 20:45:03 +0000 Message-ID: <932FB3B1-54C3-4568-B087-8836EAA66870@rhul.ac.uk> References: <4E1F467C.8090702@gmail.com> In-Reply-To: <4E1F467C.8090702@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.219.208.226] Content-Type: multipart/alternative; boundary="_000_932FB3B154C34568B0878836EAA66870rhulacuk_" MIME-Version: 1.0 Subject: Re: [Cfrg] Repeated one-time pad 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, 14 Jul 2011 20:45:09 -0000 --_000_932FB3B154C34568B0878836EAA66870rhulacuk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yaron, The paper you want is by Mason et al. from CCS a few years back: @inproceedings{DBLP:conf/ccs= /MasonWES06, author =3D {Joshua Mason and Kathryn Watkins and Jason Eisner and Adam Stubblefield}, title =3D {A natural language approach to automated cryptanalysis of two-time pads}, booktitle =3D {ACM Conference on Computer and Communications Security}, year =3D {2006}, pages =3D {235-244}, ee =3D {http://doi.acm.org/10.1145/1180405.1180435}, crossref =3D {DBLP:conf/ccs/2006usa}, bibsource =3D {DBLP, http://dblp.uni-trier.de} } I had a masters student re-implement the algorithms in this paper last summ= er - they performed very well, but not quite as well as the authors indicat= ed in their paper. Cheers Kenny On 14 Jul 2011, at 20:41, Yaron Sheffer wrote: Regarding "immediate key disclosure": is is well known that reuse of a stre= am cipher or a one-time pad with different plaintexts leads to immediate ex= posure of the plaintext (see e.g. http://en.wikipedia.org/wiki/One-time_pad= #True_randomness). For a course I am teaching, I would appreciate pointers = to the algorithms that are used for this cryptanalysis and/or source code t= hat implements this attack. Thanks, Yaron Message: 2 Date: Thu, 14 Jul 2011 10:00:44 +0200 From: Simon Josefsson > To: Ted Krovetz > Cc: cfrg@irtf.org Subjec= t: Re: [Cfrg] Request For Comments: OCB Internet-Draft Message-ID: <87ipr5g= ukz.fsf@latte.josefsson.org> Con= tent-Type: text/plain Ted Krovetz >= writes: I have just submitted an internet-draft for OCB to the IETF. http://datatracker.ietf.org/doc/draft-krovetz-ocb I'd appreciate any comments you may have on how to make the draft better. It would help if you explained (in the security considerations) what happens if a nonce is repeated. The question of failure modes of authenticated encryption modes has come up in several different contexts. It turns out that different AEAD modes have different failure properties. In particular, you want to address whether repeat of a nonce leads to immediate key disclosure, or whether the key can be found after some computation faster than obvious attacks, or whether it can only lead to recovery of the plaintext, and/or whether it depends on the plaintext as well (e.g., something interesting happens if the plaintexts are related). _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg --_000_932FB3B154C34568B0878836EAA66870rhulacuk_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Yaron,

The paper you want is by Mason et al. from CCS a few years back:

@inproceedings{DBLP:conf/ccs/MasonWE= S06,
  author    =3D {Joshua Mason and
               Kathryn Watkins and
               Jason Eisner and
               Adam Stubblefield},
  title     =3D {A natural language approach to automated cryptanalysis of
               two-time pads},
  booktitle =3D {ACM Conference on Computer and Communications Security},
  year      =3D {2006},
  pages     =3D {235-244},
  ee        =3D {http://doi.acm.org/10.1145/1180405.1180435},
  crossref  =3D {DBLP:conf/ccs/2006usa},
  bibsource =3D {DBLP, http://dblp.uni-trier.de}
}

I had a masters student re-implement the algorithms in this paper last= summer - they performed very well, but not quite as well as the authors in= dicated in their paper.

Cheers

Kenny


On 14 Jul 2011, at 20:41, Yaron Sheffer wrote:

Regarding "immediate key disclosure": is is well known that = reuse of a stream cipher or a one-time pad with different plaintexts leads = to immediate exposure of the plaintext (see e.g. http:= //en.wikipedia.org/wiki/One-time_pad#True_randomness). For a course I a= m teaching, I would appreciate pointers to the algorithms that are used for= this cryptanalysis and/or source code that implements this attack.

Thanks,
   Yaron

Message: 2 Date: Thu, 14 Jul 2011 10:00:44 +0200 From: Simon Josefsson = <simon@josefsson.org> To: = Ted Krovetz <ted@krovetz.net> = Cc: cfrg@irtf.org Subject: Re: [Cfrg] Requ= est For Comments: OCB Internet-Draft Message-ID: <87ipr5gukz.fsf@latte.josefsson.org> = Content-Type: text/plain Ted Krovetz <ted@krovetz.net> writes:
I have just submitted an internet-draft for OCB t= o the IETF.

  http://datatracker.ietf.org/doc/draft-krovetz-ocb<= /a>

I'd appreciate any comments you may have on how t= o make the draft better.
It would help if you explained (in the security c= onsiderations) what
happens if a nonce is repeated.  The questio= n of failure modes of
authenticated encryption modes has come up in sev= eral different
contexts.  It turns out that different AEAD = modes have different failure
properties.

In particular, you want to address whether repeat= of a nonce leads to
immediate key disclosure, or whether the key can = be found after some
computation faster than obvious attacks, or wheth= er it can only lead to
recovery of the plaintext, and/or whether it depe= nds on the plaintext as
well (e.g., something interesting happens if the = plaintexts are related).


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

--_000_932FB3B154C34568B0878836EAA66870rhulacuk_-- From marshall.eubanks@gmail.com Thu Jul 14 14:44:51 2011 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 BA26021F8B03 for ; Thu, 14 Jul 2011 14:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beI-v-2QCUTE for ; Thu, 14 Jul 2011 14:44:47 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by ietfa.amsl.com (Postfix) with ESMTP id EF0B821F8B00 for ; Thu, 14 Jul 2011 14:44:46 -0700 (PDT) Received: by yxl31 with SMTP id 31so369937yxl.13 for ; Thu, 14 Jul 2011 14:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Tff49MS5Gr3iLYwTKk0T7P92stCgz1D/7AqMUkFlbgQ=; b=BTdGBA61s3oyg1V1su3qLueAHGKDFSnHsJnqCBLQ1ZJX7xkrWkCpTcL6S2OvHLpdMY XOlHOHsFO0VKup54wlV1Dlle3U3lTqaxDqLXHapAH686g1bNL8EBjSi/pitTfWoStEKi s2bc7nS3LA82sJe9DOWE1o5FiIXilIfKoY5/4= MIME-Version: 1.0 Received: by 10.236.156.68 with SMTP id l44mr162975yhk.142.1310679886327; Thu, 14 Jul 2011 14:44:46 -0700 (PDT) Received: by 10.147.98.1 with HTTP; Thu, 14 Jul 2011 14:44:46 -0700 (PDT) In-Reply-To: <4E1F467C.8090702@gmail.com> References: <4E1F467C.8090702@gmail.com> Date: Thu, 14 Jul 2011 17:44:46 -0400 Message-ID: From: Marshall Eubanks To: Yaron Sheffer Content-Type: multipart/alternative; boundary=20cf303f680e09ee2304a80e71b0 Cc: cfrg@irtf.org Subject: Re: [Cfrg] Repeated one-time pad 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, 14 Jul 2011 21:44:51 -0000 --20cf303f680e09ee2304a80e71b0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 14, 2011 at 3:41 PM, Yaron Sheffer wrote: > Regarding "immediate key disclosure": is is well known that reuse of a > stream cipher or a one-time pad with different plaintexts leads to immediate > exposure of the plaintext (see e.g. http://en.wikipedia.org/wiki/** > One-time_pad#True_randomness). > For a course I am teaching, I would appreciate pointers to the algorithms > that are used for this cryptanalysis and/or source code that implements this > attack. > > The attack is pretty simple and can be done by hand. If (as was common in the spy world) the one time pad was just XORed (or summed) with the plain text, XOR'ing two of cipher-texts with the same "one-time" pad in the same phase yields an XOR of the two underlying plain-texts, which lends itself to plaintext cribs and a "crab-like" attack (i.e., if you can guess one word in one plain-text, it will, when XORed with the XOR of the two cipher-texts, reveal part of the other plain-text, which, when extended, then will reveal more of the first plain-text, and so on until both are decrypted. Even if the phase of the OTP isn't known (e.g., if there is filler text at the beginning), it should be easy to determine it using the index of coincidence (which should peak when the OTPs are aligned in phase). This is (from my understanding) how the Venona break was done. Sounds like a reasonable pen and paper exercise for your students for me. Now, what I have is always wondered is whether the non-randomness of the Russian OTPs used in their spy work was enough to have a break without reuse of the OTPs. (These were prepared by typists instructed to type randomly, and so weren't entirely random, for example letters were almost never doubled and a left hand letter was generally followed by a right hand letter. Not a lot of non-randomness, but a little can go a long way...) Regards Marshall > Thanks, > Yaron > > Message: 2 Date: Thu, 14 Jul 2011 10:00:44 +0200 From: Simon Josefsson < > simon@josefsson.org> To: Ted Krovetz Cc: cfrg@irtf.orgSubject: Re: [Cfrg] Request For Comments: OCB Internet-Draft Message-ID: < > 87ipr5gukz.fsf@latte.**josefsson.org <87ipr5gukz.fsf@latte.josefsson.org>> > Content-Type: text/plain Ted Krovetz writes: > >> I have just submitted an internet-draft for OCB to the IETF. >>> >>> http://datatracker.ietf.org/**doc/draft-krovetz-ocb >>> >>> I'd appreciate any comments you may have on how to make the draft better. >>> >> It would help if you explained (in the security considerations) what >> happens if a nonce is repeated. The question of failure modes of >> authenticated encryption modes has come up in several different >> contexts. It turns out that different AEAD modes have different failure >> properties. >> >> In particular, you want to address whether repeat of a nonce leads to >> immediate key disclosure, or whether the key can be found after some >> computation faster than obvious attacks, or whether it can only lead to >> recovery of the plaintext, and/or whether it depends on the plaintext as >> well (e.g., something interesting happens if the plaintexts are related). >> >> > ______________________________**_________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/**listinfo/cfrg > --20cf303f680e09ee2304a80e71b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 14, 2011 at 3:41 PM, Yaron S= heffer <yaron= f.ietf@gmail.com> wrote:
Regarding "immediate key disclosure": is is well known that reuse= of a stream cipher or a one-time pad with different plaintexts leads to im= mediate exposure of the plaintext (see e.g. http://en.wikipedi= a.org/wiki/One-time_pad#True_randomness). For a course I am teac= hing, I would appreciate pointers to the algorithms that are used for this = cryptanalysis and/or source code that implements this attack.

The attack is pretty simple and can be done by hand.= =A0

If (as was common in the spy world) the one ti= me pad was just XORed (or summed) with the plain text, XOR'ing two of c= ipher-texts with the same =A0"one-time" pad in the same phase yie= lds an XOR =A0of the two underlying plain-texts, which lends itself to plai= ntext cribs=A0and a "crab-like" attack=A0(i.e., if you can guess = one word in one plain-text, it=A0will, when XORed with the XOR of the two c= ipher-texts, reveal part of the other plain-text, which, when extended, the= n will =A0reveal more of the first plain-text, and so on until both are dec= rypted. Even if the phase of the OTP isn't known (e.g., if there is fil= ler text at the beginning), it should be easy to determine it using the ind= ex of coincidence (which should peak when the OTPs are aligned in phase).

This is (from my understanding) how the Venona break wa= s done.

Sounds like a reasonable pen and paper exe= rcise for your students for me.=A0

Now, what I hav= e is always wondered is whether the non-randomness of the Russian OTPs used= in their spy work was =A0enough to have a break without reuse of the OTPs.= (These were prepared by typists instructed to type randomly, and so weren&= #39;t entirely random, for example letters were almost never doubled and a = left hand letter was generally followed by a right=A0hand letter. Not a lot= of non-randomness, but a little can go a long way...)

Regards
Marshall



=A0
Thanks,
=A0 =A0Yaron

Message: 2 Date: Thu, 14 Jul 2011 10:00:44 +0200 From: Simon Josefsson <= simon@josefsson.or= g> To: Ted Krovetz <ted@krovetz.net> Cc: cfrg@irtf.org Subject: Re: [Cfrg] Request For Comments: OCB= Internet-Draft Message-ID: <87ipr5gukz.fsf@latte.josefsson.org&= gt; Content-Type: text/plain Ted Krovetz <ted@krovetz.net> writes:
I have just submitted an internet-draft for OCB to the IETF.

=A0 http://datatracker.ietf.org/doc/draft-krovetz-ocb
I'd appreciate any comments you may have on how to make the draft bette= r.
It would help if you explained (in the security considerations) what
happens if a nonce is repeated. =A0The question of failure modes of
authenticated encryption modes has come up in several different
contexts. =A0It turns out that different AEAD modes have different failure<= br> properties.

In particular, you want to address whether repeat of a nonce leads to
immediate key disclosure, or whether the key can be found after some
computation faster than obvious attacks, or whether it can only lead to
recovery of the plaintext, and/or whether it depends on the plaintext as well (e.g., something interesting happens if the plaintexts are related).

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


--20cf303f680e09ee2304a80e71b0-- From ted@krovetz.net Thu Jul 14 17:35:16 2011 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 DB61521F89A7 for ; Thu, 14 Jul 2011 17:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eEnu1xXEMqF for ; Thu, 14 Jul 2011 17:35:16 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5235A21F8888 for ; Thu, 14 Jul 2011 17:35:16 -0700 (PDT) Received: by iyb11 with SMTP id 11so890789iyb.13 for ; Thu, 14 Jul 2011 17:35:15 -0700 (PDT) Received: by 10.42.247.198 with SMTP id md6mr3087953icb.422.1310690115651; Thu, 14 Jul 2011 17:35:15 -0700 (PDT) Received: from [192.168.11.149] (adsl-75-5-246-246.dsl.scrm01.sbcglobal.net [75.5.246.246]) by mx.google.com with ESMTPS id c2sm474352ibd.39.2011.07.14.17.35.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jul 2011 17:35:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Ted Krovetz In-Reply-To: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> Date: Thu, 14 Jul 2011 17:35:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> To: cfrg@irtf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 15 Jul 2011 00:35:17 -0000 > It would help if you explained (in the security considerations) what = happens if a nonce is repeated. Nice suggestion. Security is lost if nonces are reused during = encryption. We've made this clearer in the ID and have resubmitted it as = draft-krovetz-ocb-02. > If you are aware of other patents (or applications) that applies, it = would help if you send in a patent disclosure about it. IBM and Virgil Gligor have AE patents which may or may not apply to OCB. = What we are trying to establish with them is a clear licensing picture = for OCB, hopefully with many free usage scenarios. Phil will update the = IETF IPR soon. Thanks, Ted= From simon@josefsson.org Fri Jul 15 00:54:32 2011 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 DDC0521F8777 for ; Fri, 15 Jul 2011 00:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o7+Yh9OqIIy for ; Fri, 15 Jul 2011 00:54:32 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id A509E21F876E for ; Fri, 15 Jul 2011 00:54:31 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6F7sOCR027704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2011 09:54:26 +0200 From: Simon Josefsson To: Ted Krovetz References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110715:cfrg@irtf.org::31wm9EvHKj0CeD9X:2/b3 X-Hashcash: 1:22:110715:ted@krovetz.net::ONbxt3PE4QyYqhV3:5/Gn Date: Fri, 15 Jul 2011 09:54:23 +0200 In-Reply-To: <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> (Ted Krovetz's message of "Thu, 14 Jul 2011 17:35:13 -0700") Message-ID: <87r55sc72o.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: cfrg@irtf.org Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 15 Jul 2011 07:54:33 -0000 Ted Krovetz writes: >> It would help if you explained (in the security considerations) what >> happens if a nonce is repeated. > > Nice suggestion. Security is lost if nonces are reused during > encryption. We've made this clearer in the ID and have resubmitted it > as draft-krovetz-ocb-02. Thank you! Are there any implications for the key if a nonce is repeated? Let's say I use the same nonce all the time, and the attacker can do known-plaintext attacks. Can the attacker recover the key faster than he would be able to if the nonces were not repeated? I'm trying to get AEAD cipher modes to say more than just "the security properties are lost" when talking about failure modes. "security properties are lost" can mean so many things, and it is useful to be able to rule out some unwanted side effects. /Simon From ted@krovetz.net Fri Jul 15 08:04:13 2011 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 68F9321F88D1 for ; Fri, 15 Jul 2011 08:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWXdhuej1fZg for ; Fri, 15 Jul 2011 08:04:12 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id C60C221F88CF for ; Fri, 15 Jul 2011 08:04:12 -0700 (PDT) Received: by iyb11 with SMTP id 11so1528398iyb.13 for ; Fri, 15 Jul 2011 08:04:12 -0700 (PDT) Received: by 10.42.83.194 with SMTP id i2mr3778742icl.305.1310742252121; Fri, 15 Jul 2011 08:04:12 -0700 (PDT) Received: from [192.168.11.149] (adsl-75-5-246-246.dsl.scrm01.sbcglobal.net [75.5.246.246]) by mx.google.com with ESMTPS id x11sm897061ibd.24.2011.07.15.08.04.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jul 2011 08:04:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Ted Krovetz In-Reply-To: <87r55sc72o.fsf@latte.josefsson.org> Date: Fri, 15 Jul 2011 08:04:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> <87r55sc72o.fsf@latte.josefsson.org> To: cfrg@irtf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 15 Jul 2011 15:04:13 -0000 > Are there any implications for the key if a nonce is repeated? Let's > say I use the same nonce all the time, and the attacker can do > known-plaintext attacks. Can the attacker recover the key faster than > he would be able to if the nonces were not repeated? No. The only place the OCB key is used is as the key for AES. So, if one = were able to recover OCB keys in the way you suggest, one would in = effect have an AES key-extraction method. Since we don't think AES is = susceptible to key-extraction, neither is OCB. > I'm trying to get AEAD cipher modes to say more than just "the = security > properties are lost" when talking about failure modes. "security > properties are lost" can mean so many things, and it is useful to be > able to rule out some unwanted side effects. In the ID we point out that if a nonce is reused during encryption, = "partial information about past plaintexts will be revealed and = subsequent forgeries will be possible". That seems specific enough for = an RFC, don't you think?= From simon@josefsson.org Fri Jul 15 08:09:11 2011 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 362EE21F875C for ; Fri, 15 Jul 2011 08:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lbv2PjIuqJek for ; Fri, 15 Jul 2011 08:09:10 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED7521F862E for ; Fri, 15 Jul 2011 08:09:10 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6FF91vM014383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2011 17:09:05 +0200 From: Simon Josefsson To: Ted Krovetz References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> <87r55sc72o.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110715:cfrg@irtf.org::lUXDVwTdtNXOCQ9d:8Xem X-Hashcash: 1:22:110715:ted@krovetz.net::9B9XBmcaMOlFwVzq:CSVl Date: Fri, 15 Jul 2011 17:09:01 +0200 In-Reply-To: (Ted Krovetz's message of "Fri, 15 Jul 2011 08:04:08 -0700") Message-ID: <87sjq760oi.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: cfrg@irtf.org Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 15 Jul 2011 15:09:11 -0000 Ted Krovetz writes: >> Are there any implications for the key if a nonce is repeated? Let's >> say I use the same nonce all the time, and the attacker can do >> known-plaintext attacks. Can the attacker recover the key faster than >> he would be able to if the nonces were not repeated? > > No. The only place the OCB key is used is as the key for AES. So, if > one were able to recover OCB keys in the way you suggest, one would in > effect have an AES key-extraction method. Since we don't think AES is > susceptible to key-extraction, neither is OCB. > >> I'm trying to get AEAD cipher modes to say more than just "the security >> properties are lost" when talking about failure modes. "security >> properties are lost" can mean so many things, and it is useful to be >> able to rule out some unwanted side effects. > > In the ID we point out that if a nonce is reused during encryption, > "partial information about past plaintexts will be revealed and > subsequent forgeries will be possible". That seems specific enough for > an RFC, don't you think? Yes, thank you very much for clarifying! /Simon From paul.hoffman@vpnc.org Fri Jul 15 08:35:39 2011 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 AD61F21F84C7 for ; Fri, 15 Jul 2011 08:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.651 X-Spam-Level: X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j1vN0m2vs2F for ; Fri, 15 Jul 2011 08:35:39 -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 3E1F021F88A5 for ; Fri, 15 Jul 2011 08:35:37 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6FFZQwe037194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jul 2011 08:35:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 15 Jul 2011 08:35:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4FB2F68A-8B84-4953-A7B1-87D3E9DCEA2D@vpnc.org> References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> <87r55sc72o.fsf@latte.josefsson.org> To: Ted Krovetz X-Mailer: Apple Mail (2.1084) Cc: cfrg@irtf.org Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 15 Jul 2011 15:35:39 -0000 On Jul 15, 2011, at 8:04 AM, Ted Krovetz wrote: > In the ID we point out that if a nonce is reused during encryption, = "partial information about past plaintexts will be revealed and = subsequent forgeries will be possible". That seems specific enough for = an RFC, don't you think? If you know how "partial" that is, it would be useful for the draft. One = repetition exposing one bit of a past plaintext is quite different than = one repetition exposing half the bits, even though both are bad. Also, = knowing what more two repetitions brings the attacker over one = repetition is also useful from an operational standpoint. --Paul Hoffman From prvs=617715d0e8=uri@ll.mit.edu Fri Jul 15 09:19:54 2011 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 5004721F874A for ; Fri, 15 Jul 2011 09:19:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+UM2CohFyLm for ; Fri, 15 Jul 2011 09:19:50 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC2921F84DB for ; Fri, 15 Jul 2011 09:19:49 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p6FGJkDi031138; Fri, 15 Jul 2011 12:19:46 -0400 From: "Blumenthal, Uri - 0668 - MITLL" To: "'paul.hoffman@vpnc.org'" , "'ted@krovetz.net'" Date: Fri, 15 Jul 2011 12:19:44 -0400 Thread-Topic: [Cfrg] Request For Comments: OCB Internet-Draft Thread-Index: AcxDBNuYEGb16Lk3SF+45evwcBGi0QABiaw8 In-Reply-To: <4FB2F68A-8B84-4953-A7B1-87D3E9DCEA2D@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-15_06:2011-07-15, 2011-07-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1107150122 Message-Id: <20110715161950.0CC2921F84DB@ietfa.amsl.com> Cc: "'cfrg@irtf.org'" Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 15 Jul 2011 16:19:54 -0000 Ted, I think you can be rather more specific.=20 -- Regards, Uri ----- Original Message ----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Friday, July 15, 2011 11:35 AM=0A= To: Ted Krovetz Cc: cfrg@irtf.org Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft On Jul 15, 2011, at 8:04 AM, Ted Krovetz wrote: > In the ID we point out that if a nonce is reused during encryption, "part= ial information about past plaintexts will be revealed and subsequent forge= ries will be possible". That seems specific enough for an RFC, don't you th= ink? If you know how "partial" that is, it would be useful for the draft. One re= petition exposing one bit of a past plaintext is quite different than one r= epetition exposing half the bits, even though both are bad. Also, knowing w= hat more two repetitions brings the attacker over one repetition is also us= eful from an operational standpoint. --Paul Hoffman _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg From ted@krovetz.net Fri Jul 15 09:45:12 2011 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 CB4C921F8B4D for ; Fri, 15 Jul 2011 09:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCJD9cyQwI8v for ; Fri, 15 Jul 2011 09:45:12 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 35A8D21F8B4C for ; Fri, 15 Jul 2011 09:45:09 -0700 (PDT) Received: by iyb11 with SMTP id 11so1628145iyb.13 for ; Fri, 15 Jul 2011 09:45:08 -0700 (PDT) Received: by 10.42.196.196 with SMTP id eh4mr4015428icb.2.1310748308814; Fri, 15 Jul 2011 09:45:08 -0700 (PDT) Received: from [192.168.11.149] (adsl-75-5-246-246.dsl.scrm01.sbcglobal.net [75.5.246.246]) by mx.google.com with ESMTPS id s2sm1572159icw.5.2011.07.15.09.45.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jul 2011 09:45:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Ted Krovetz In-Reply-To: <4FB2F68A-8B84-4953-A7B1-87D3E9DCEA2D@vpnc.org> Date: Fri, 15 Jul 2011 09:45:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> <87r55sc72o.fsf@latte.josefsson.org> <4FB2F68A-8B84-4953-A7B1-87D3E9DCEA2D@vpnc.org> To: cfrg@irtf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 15 Jul 2011 16:45:12 -0000 > If you know how "partial" that is, it would be useful for the draft. > Ted, I think you can be rather more specific.=20 In my opinion the point of the nonce-reuse warning is to impress upon = security engineers that catastrophe strikes if a nonce is reused during = encryption, and so they should make nonce reuse impossible. If nonce = reuse is impossible, then it is irrelevant how bad the damage is when = nonces are reused. RFC writers need to walk a fine line: RFCs are primarily a description = of technology, but should include enough high-level context to inform = against poor usage. I think the current warnings on nonce reuse do this, = but if you can suggest a scenario where the current advice is being = heeded and yet it is still useful to know how bad not heeding it would = be, I'm open to adding some quantifications. It may be worth adding a few paragraphs to the OCB paper describing and = quantifying the damage, but I'm a bit reluctant to do so in the ID.= From lloyd@randombit.net Fri Jul 15 10:38:40 2011 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 DC43221F8567 for ; Fri, 15 Jul 2011 10:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG4KFpV472Ri for ; Fri, 15 Jul 2011 10:38:40 -0700 (PDT) Received: from chihiro.randombit.net (chihiro.randombit.net [69.48.226.76]) by ietfa.amsl.com (Postfix) with ESMTP id D0E8921F8563 for ; Fri, 15 Jul 2011 10:38:36 -0700 (PDT) Received: by chihiro.randombit.net (Postfix, from userid 1000) id B9B9A2F0015E; Fri, 15 Jul 2011 13:38:35 -0400 (EDT) Date: Fri, 15 Jul 2011 13:38:35 -0400 From: Jack Lloyd To: cfrg@irtf.org Message-ID: <20110715173835.GI13721@randombit.net> References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> <87r55sc72o.fsf@latte.josefsson.org> <4FB2F68A-8B84-4953-A7B1-87D3E9DCEA2D@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-PGP-Key: http://www.randombit.net/pgpkey.html User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 15 Jul 2011 17:38:41 -0000 On Fri, Jul 15, 2011 at 09:45:06AM -0700, Ted Krovetz wrote: > In my opinion the point of the nonce-reuse warning is to impress > upon security engineers that catastrophe strikes if a nonce is > reused during encryption, and so they should make nonce reuse > impossible. If nonce reuse is impossible, then it is irrelevant how > bad the damage is when nonces are reused. I think part of the issue is that making something truly 'impossible' is quite a bit harder than it might sound, especially in the face of an active attacker who might well decide that the easiest way of breaking the system is to force it to reuse a nonce somehow (this seems especially likely in embedded systems, but a general system might well be susceptible). Some plausible failure modes, like VM state rollback [1], could even be attacked passively and opportunistically. Someone building or deploying a system (ie the sort of person who would read an i-d or RFC) might well want to understand exactly how fragile the system is when misused, which lets them make a realistic and informed judgement of the tradeoffs in choosing between different options. Regards, Jack [1] http://www.ietf.org/mail-archive/web/cfrg/current/msg01349.html From ggr@qualcomm.com Fri Jul 15 10:53:05 2011 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 BCF5F21F8BEB for ; Fri, 15 Jul 2011 10:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcsMj61VJM3z for ; Fri, 15 Jul 2011 10:53:05 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3154F21F8BB5 for ; Fri, 15 Jul 2011 10:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ggr@qualcomm.com; q=dns/txt; s=qcdkim; t=1310752385; x=1342288385; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-id: content-transfer-encoding:mime-version; z=From:=20"Rose,=20Greg"=20|To:=20Jack =20Lloyd=20|CC:=20"Rose,=20Greg"=20< ggr@qualcomm.com>,=20""=20 |Subject:=20Re:=20[Cfrg]=20Request=20For=20Comments:=20OC B=20Internet-Draft|Thread-Topic:=20[Cfrg]=20Request=20For =20Comments:=20OCB=20Internet-Draft|Thread-Index:=20AQHMQ sRp6eyaR4zlx0yk3udq5GiQtJTt8LQAgAAIyYCAABNsAIAADvKAgAADvo A=3D|Date:=20Fri,=2015=20Jul=202011=2017:51:59=20+0000 |Message-ID:=20<462E229B-F320-4431-8F7E-D5536A7386BC@qual comm.com>|References:=20<22798CA3-3D49-4652-A5DB-EC25ACCD 245C@krovetz.net>=0D=0A=20<2B90DB3F-327A-45B3-B1AE-C8D198 25CF31@krovetz.net>=0D=0A=20<87r55sc72o.fsf@latte.josefss on.org>=0D=0A=20=0D=0A=20<4FB2F68A-8B84-4953-A7B1-87D3E9DCEA2D@v pnc.org>=0D=0A=20=0D=0A=20<20110715173835.GI13721@randombit.net> |In-Reply-To:=20<20110715173835.GI13721@randombit.net> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[10.45.230.6]|Content-Type:=20text/plain=3B=20charset =3D"us-ascii"|Content-ID:=20<5828788BD78E5F4DBF34919DF4E8 33C2@qualcomm.com>|Content-Transfer-Encoding:=20quoted-pr intable|MIME-Version:=201.0; bh=CykBZE1mhSbn9XHGxfTQls8zBAkjOgB8qi7FZ+tEyvk=; b=F1H74Ld8++e4iQQP0cpPo1mHyEkvOvNmnIRs49Znb5GNDZYxy9xquJQM VoARmatWkupRMo+9ZnseYdiheBiUeQ24xwHdGav0SS757yuSNvDAzHLnQ n9J/ZEHwUCK5Mb3bMeD+kQXPX9YuoexyJ21b0YazL0MLMc+OCMRrheudo 8=; X-IronPort-AV: E=McAfee;i="5400,1158,6408"; a="103826051" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 15 Jul 2011 10:53:03 -0700 X-IronPort-AV: E=Sophos;i="4.65,535,1304319600"; d="scan'208";a="155106554" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 15 Jul 2011 10:53:03 -0700 Received: from NASANEXD01D.na.qualcomm.com ([fe80::4d64:11bc:743c:6fdb]) by nasanexhc04.na.qualcomm.com ([::1]) with mapi id 14.01.0323.000; Fri, 15 Jul 2011 10:52:00 -0700 From: "Rose, Greg" To: Jack Lloyd Thread-Topic: [Cfrg] Request For Comments: OCB Internet-Draft Thread-Index: AQHMQsRp6eyaR4zlx0yk3udq5GiQtJTt8LQAgAAIyYCAABNsAIAADvKAgAADvoA= Date: Fri, 15 Jul 2011 17:51:59 +0000 Message-ID: <462E229B-F320-4431-8F7E-D5536A7386BC@qualcomm.com> References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> <87r55sc72o.fsf@latte.josefsson.org> <4FB2F68A-8B84-4953-A7B1-87D3E9DCEA2D@vpnc.org> <20110715173835.GI13721@randombit.net> In-Reply-To: <20110715173835.GI13721@randombit.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: text/plain; charset="us-ascii" Content-ID: <5828788BD78E5F4DBF34919DF4E833C2@qualcomm.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rose, Greg" , "" Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 15 Jul 2011 17:53:05 -0000 On 2011 Jul 15, at 10:38 , Jack Lloyd wrote: > On Fri, Jul 15, 2011 at 09:45:06AM -0700, Ted Krovetz wrote: >=20 >> In my opinion the point of the nonce-reuse warning is to impress >> upon security engineers that catastrophe strikes if a nonce is >> reused during encryption, and so they should make nonce reuse >> impossible. If nonce reuse is impossible, then it is irrelevant how >> bad the damage is when nonces are reused. >=20 > I think part of the issue is that making something truly 'impossible' > is quite a bit harder than it might sound, especially in the face of > an active attacker who might well decide that the easiest way of > breaking the system is to force it to reuse a nonce somehow (this > seems especially likely in embedded systems, but a general system > might well be susceptible). Some plausible failure modes, like VM > state rollback [1], could even be attacked passively and > opportunistically. >=20 > Someone building or deploying a system (ie the sort of person who > would read an i-d or RFC) might well want to understand exactly how > fragile the system is when misused, which lets them make a realistic > and informed judgement of the tradeoffs in choosing between different > options. And don't forget that the attacker gets to reuse nonces all he wants (albei= t on presumably invalid packets). This is why there must be an absolute pro= hibition on using the decryption results of an invalid packet. I haven't ha= d time to read the draft; I trust this is mentioned somewhere. It's particu= larly important for a mode like OCB where the decryption is already done be= fore you know that the packet was bogus. The data should be cleared before = returning failure. Greg.= From ted@krovetz.net Fri Jul 15 15:08:08 2011 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 8BB7921F8B9C for ; Fri, 15 Jul 2011 15:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Difm7S1R7cd for ; Fri, 15 Jul 2011 15:08:08 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3CC21F8B99 for ; Fri, 15 Jul 2011 15:08:07 -0700 (PDT) Received: by iyb11 with SMTP id 11so1888252iyb.13 for ; Fri, 15 Jul 2011 15:08:07 -0700 (PDT) Received: by 10.43.49.66 with SMTP id uz2mr1304162icb.284.1310767687403; Fri, 15 Jul 2011 15:08:07 -0700 (PDT) Received: from [192.168.11.149] ([75.5.246.246]) by mx.google.com with ESMTPS id t6sm1771924icj.3.2011.07.15.15.08.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jul 2011 15:08:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Ted Krovetz In-Reply-To: <462E229B-F320-4431-8F7E-D5536A7386BC@qualcomm.com> Date: Fri, 15 Jul 2011 15:08:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <235D72A3-FFEC-4836-873B-A0BD5F655803@krovetz.net> References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> <87r55sc72o.fsf@latte.josefsson.org> <4FB2F68A-8B84-4953-A7B1-87D3E9DCEA2D@vpnc.org> <20110715173835.GI13721@randombit.net> <462E229B-F320-4431-8F7E-D5536A7386BC@qualcomm.com> To: cfrg@irtf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 15 Jul 2011 22:08:08 -0000 > there must be an absolute prohibition on using the decryption results = of an invalid packet Yes, that is made explicit in the ID. > I think part of the issue is that making something truly 'impossible' = is quite a bit harder than it might sound, especially in the face of an = active attacker who might well decide that the easiest way of breaking = the system is to force it to reuse a nonce somehow That's a problem. When using a scheme that demands nonce uniqueness, the = probability of nonce reuse becomes a lower bound on design strength. The = OCB ID suggests using a scheme (like SIV) that tollerates nonce reuse if = nonce uniqueness cannot be guaranteed. From jeremie.crenne@univ-ubs.fr Mon Jul 18 12:46:32 2011 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 72B9721F859E for ; Mon, 18 Jul 2011 12:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik6brRBrN8i2 for ; Mon, 18 Jul 2011 12:46:27 -0700 (PDT) Received: from storck.univ-ubs.fr (smtp-new.ipv6.univ-ubs.fr [IPv6:2001:660:7304:9:222:19ff:fe53:31d6]) by ietfa.amsl.com (Postfix) with ESMTP id E80A621F858A for ; Mon, 18 Jul 2011 12:46:26 -0700 (PDT) Received: from JeremiePC (ARennes-353-1-38-239.w92-135.abo.wanadoo.fr [92.135.245.239]) (authenticated bits=0) by storck.univ-ubs.fr (8.14.3/8.14.3) with ESMTP id p6IJkMRB001658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 18 Jul 2011 21:46:24 +0200 (CEST) (envelope-from jeremie.crenne@univ-ubs.fr) From: =?iso-8859-1?Q?J=E9r=E9mie_Crenne?= To: References: In-Reply-To: Date: Mon, 18 Jul 2011 21:46:20 +0200 Message-ID: <000001cc4583$5f371720$1da54560$@crenne@univ-ubs.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxFYkhbmnF3M5PzRRWL3WivUaPB3AAHzpRA Content-Language: fr Subject: [Cfrg] AES-GCM weakness 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, 18 Jul 2011 19:48:16 -0000 Hi everybody,=20 What is the feeling of the community about the recent potential AES-GCM weakness due to weak keys ? I'm still considering the usage of AES-GCM = to be an attractive mode for hardware implementations. I'm a little bit = concerned about this since the "new" proposition described here would require significant addition of logic. http://eprint.iacr.org/2011/202 http://eprint.iacr.org/2011/326 Thanks, J=E9r=E9mie From mcgrew@cisco.com Mon Jul 18 14:18:26 2011 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 1E77E21F86C7 for ; Mon, 18 Jul 2011 14:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.449 X-Spam-Level: X-Spam-Status: No, score=-104.449 tagged_above=-999 required=5 tests=[AWL=-2.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBEBb357mnaQ for ; Mon, 18 Jul 2011 14:18:22 -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 4EA7021F86C4 for ; Mon, 18 Jul 2011 14:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=3202; q=dns/txt; s=iport; t=1311023902; x=1312233502; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=/RUO/279Papb7tiaZJYCStJKrXJRbHsS9IU+CBiF5Og=; b=LHuNjEr+zr+cNvddlI8r/frq7ypRdd+wWjX81YC/RxErK2h/2p6awOeY b/qxKQJWym9SM+6v8/DhhTCjONKx+vLEHo5tw50luztExL1AwIJ2Trr1i z0v+ALWNYxr8vBhU3bmkseM+qp8Y2IfZ3gEcv+a4Sas0unGEt3dcegYFr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMChJE6rRDoG/2dsb2JhbABThANGozN3iHylLY0ckR2BK4QCMF8Eh1SLEpB2 X-IronPort-AV: E=Sophos;i="4.67,223,1309737600"; d="scan'208";a="4110287" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 18 Jul 2011 21:18:21 +0000 Received: from stealth-10-32-254-213.cisco.com (stealth-10-32-254-213.cisco.com [10.32.254.213]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6ILIKbm005494; Mon, 18 Jul 2011 21:18:20 GMT Message-Id: <4461B7BB-E7E4-47BA-89CA-936F41177F53@cisco.com> From: David McGrew To: =?ISO-8859-1?Q?J=E9r=E9mie_Crenne?= In-Reply-To: <000001cc4583$5f371720$1da54560$@crenne@univ-ubs.fr> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 18 Jul 2011 14:18:19 -0700 References: <000001cc4583$5f371720$1da54560$@crenne@univ-ubs.fr> X-Mailer: Apple Mail (2.936) Cc: cfrg@irtf.org Subject: Re: [Cfrg] AES-GCM weakness 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, 18 Jul 2011 21:18:26 -0000 Hi J=C3=A9r=C3=A9mie, http://eprint.iacr.org/2011/202 provides some interesting insights =20 into how polynomial hash based authentication works, but it does *not* =20= describe any way of attacking GCM that improves on what was known =20 before GCM was adopted. "GCM, GHASH and Weak Keys" describes a particular way of forging a =20 message, given a valid message, which works with probability of about =20= n/2^128 for messages that are n*128 bits long. Observation 1 reads: =20 "Let n be a number satisfying gcd(2^128 =E2=88=92 1, n) =3D n. Blindly = swapping =20 Xi and Xj , where i =E2=89=A1 j (mod n) will result in a successful = forgery =20 with probability of at least n/2^128." This corresponds to the original security analysis, from "The Security =20= and Performance of the Galois/Counter Mode (GCM) of =20 Operation" (Indocrypt 2004). Lemma 2 from that reference(GHASH is =20 almost xor universal) reads: "The function GHASH is (n + 1)/2^128 =20 almost xor universal when its second and third inputs are restricted =20 so that their lengths sum to n*128 or fewer bits ..." Here I have =20 set w=3D128 and l=3Dn*128 so that the notations are similar. The newer work does describe an optimal attack, which is interesting, =20= though see also the attacks described by Ferguson in his comments to =20 NIST [1], and [2]. But it does not describe a way to attack GCM that =20= works with higher chance of success than was previously known. SGCM, described in http://eprint.iacr.org/2011/326, I don't think is a =20= good idea, because it shares GCM's least desirable property (a broken =20= implementation that repeats IVs will give away its authentication key) =20= and it is not backwards compatible with GCM. If that algorithm is =20 extended, it would be much more worthwhile to have a different method =20= of encrypting the hash, as suggested by Joux (Section 5 of [3]) and as =20= done by the CWC authors [4]. It might be useful to have an additional =20= ECB encryption of the tag, which could be described as a post-=20 processing step for GCM as it is currently specified. regards, David [1] = http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferg= uson2.pdf [2] http://eprint.iacr.org/2005/161.pdf [3] = http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/Joux_comments.pdf [4] = http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/cwc/cwc= -spec.pdf On Jul 18, 2011, at 12:46 PM, J=C3=A9r=C3=A9mie Crenne wrote: > Hi everybody, > > What is the feeling of the community about the recent potential AES-=20= > GCM > weakness due to weak keys ? I'm still considering the usage of AES-=20 > GCM to be > an attractive mode for hardware implementations. I'm a little bit =20 > concerned > about this since the "new" proposition described here would require > significant addition of logic. > > http://eprint.iacr.org/2011/202 > http://eprint.iacr.org/2011/326 > > Thanks, > > J=C3=A9r=C3=A9mie > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From sfluhrer@cisco.com Mon Jul 18 15:14:31 2011 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 E967821F8880 for ; Mon, 18 Jul 2011 15:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjdmAUQNjliH for ; Mon, 18 Jul 2011 15:14:31 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E825221F880C for ; Mon, 18 Jul 2011 15:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=5560; q=dns/txt; s=iport; t=1311027271; x=1312236871; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=uSqeUbIPzWtVC5nYGJifZd9Pk/0uVWn7oNq/qR32XgU=; b=XFS9vW8zwPUB6BlVAwXwOx4YY6Rhk6cdAAWxWIPHFmeeL0/QO4mAaqD5 u7ryV/BmKaqZ5YRNXzOxOxOG84xNZyFCfcH/vHS6qIQY7z+/fjm1+Qxlt c6cgrcrvdUMaFYLGk6MGDU2XZa+m+uHNe8JUZhI8F1XV68pl9t6HGgg1u Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAFCvJE6rRDoH/2dsb2JhbABThANGkz2OTXd3iHylJo0ckRuBK4QCMF8Eh1SQHIts X-IronPort-AV: E=Sophos;i="4.67,224,1309737600"; d="scan'208";a="4128529" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jul 2011 22:14:29 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6IMEMWq010701; Mon, 18 Jul 2011 22:14:22 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Jul 2011 15:14:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 18 Jul 2011 15:14:17 -0700 Message-ID: In-Reply-To: <4461B7BB-E7E4-47BA-89CA-936F41177F53@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] AES-GCM weakness Thread-Index: AcxFkEl/NJKBIdpYRj+jE1yXsqkI/QABgDvQ References: <000001cc4583$5f371720$1da54560$@crenne@univ-ubs.fr> <4461B7BB-E7E4-47BA-89CA-936F41177F53@cisco.com> From: "Scott Fluhrer (sfluhrer)" To: "David McGrew (mcgrew)" , =?UTF-8?B?SsOpcsOpbWllIENyZW5uZQ==?= X-OriginalArrivalTime: 18 Jul 2011 22:14:21.0727 (UTC) FILETIME=[0B814AF0:01CC4598] Cc: cfrg@irtf.org Subject: Re: [Cfrg] AES-GCM weakness 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, 18 Jul 2011 22:14:32 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2ZyZy1ib3VuY2VzQGly dGYub3JnIFttYWlsdG86Y2ZyZy1ib3VuY2VzQGlydGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gRGF2 aWQgTWNHcmV3IChtY2dyZXcpDQo+IFNlbnQ6IE1vbmRheSwgSnVseSAxOCwgMjAxMSA1OjE4IFBN DQo+IFRvOiBKw6lyw6ltaWUgQ3Jlbm5lDQo+IENjOiBjZnJnQGlydGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbQ2ZyZ10gQUVTLUdDTSB3ZWFrbmVzcw0KPiANCj4gSGkgSsOpcsOpbWllLA0KPiANCj4g aHR0cDovL2VwcmludC5pYWNyLm9yZy8yMDExLzIwMiBwcm92aWRlcyBzb21lIGludGVyZXN0aW5n IGluc2lnaHRzDQo+IGludG8gaG93IHBvbHlub21pYWwgaGFzaCBiYXNlZCBhdXRoZW50aWNhdGlv biB3b3JrcywgYnV0IGl0IGRvZXMgKm5vdCoNCj4gZGVzY3JpYmUgYW55IHdheSBvZiBhdHRhY2tp bmcgR0NNIHRoYXQgaW1wcm92ZXMgb24gd2hhdCB3YXMga25vd24NCj4gYmVmb3JlIEdDTSB3YXMg YWRvcHRlZC4NCj4gDQo+ICJHQ00sIEdIQVNIIGFuZCBXZWFrIEtleXMiIGRlc2NyaWJlcyBhIHBh cnRpY3VsYXIgd2F5IG9mIGZvcmdpbmcgYQ0KPiBtZXNzYWdlLCBnaXZlbiBhIHZhbGlkIG1lc3Nh Z2UsIHdoaWNoIHdvcmtzIHdpdGggcHJvYmFiaWxpdHkgb2YgYWJvdXQNCj4gbi8yXjEyOCBmb3Ig bWVzc2FnZXMgdGhhdCBhcmUgbioxMjggYml0cyBsb25nLiAgT2JzZXJ2YXRpb24gMSByZWFkczoN Cj4gIkxldCBuIGJlIGEgbnVtYmVyIHNhdGlzZnlpbmcgZ2NkKDJeMTI4IOKIkiAxLCBuKSA9IG4u IEJsaW5kbHkgc3dhcHBpbmcNCj4gWGkgYW5kIFhqICwgd2hlcmUgaSDiiaEgaiAobW9kIG4pIHdp bGwgcmVzdWx0IGluIGEgc3VjY2Vzc2Z1bCBmb3JnZXJ5DQo+IHdpdGggcHJvYmFiaWxpdHkgb2Yg YXQgbGVhc3Qgbi8yXjEyOC4iDQo+IA0KPiBUaGlzIGNvcnJlc3BvbmRzIHRvIHRoZSBvcmlnaW5h bCBzZWN1cml0eSBhbmFseXNpcywgZnJvbSAiVGhlIFNlY3VyaXR5DQo+IGFuZCBQZXJmb3JtYW5j ZSBvZiB0aGUgR2Fsb2lzL0NvdW50ZXIgTW9kZSAoR0NNKSBvZg0KPiBPcGVyYXRpb24iIChJbmRv Y3J5cHQgMjAwNCkuICBMZW1tYSAyIGZyb20gdGhhdCByZWZlcmVuY2UoR0hBU0ggaXMNCj4gYWxt b3N0IHhvciB1bml2ZXJzYWwpIHJlYWRzOiAiVGhlIGZ1bmN0aW9uIEdIQVNIIGlzIChuICsgMSkv Ml4xMjgNCj4gYWxtb3N0IHhvciB1bml2ZXJzYWwgd2hlbiBpdHMgc2Vjb25kIGFuZCB0aGlyZCBp bnB1dHMgYXJlIHJlc3RyaWN0ZWQNCj4gc28gdGhhdCB0aGVpciBsZW5ndGhzIHN1bSB0byBuKjEy OCBvciBmZXdlciBiaXRzIC4uLiIgICBIZXJlIEkgaGF2ZQ0KPiBzZXQgdz0xMjggYW5kIGw9biox Mjggc28gdGhhdCB0aGUgbm90YXRpb25zIGFyZSBzaW1pbGFyLg0KPiANCj4gVGhlIG5ld2VyIHdv cmsgZG9lcyBkZXNjcmliZSBhbiBvcHRpbWFsIGF0dGFjaywgd2hpY2ggaXMgaW50ZXJlc3Rpbmcs DQo+IHRob3VnaCBzZWUgYWxzbyB0aGUgYXR0YWNrcyBkZXNjcmliZWQgYnkgRmVyZ3Vzb24gaW4g aGlzIGNvbW1lbnRzIHRvDQo+IE5JU1QgWzFdLCBhbmQgWzJdLiAgQnV0IGl0IGRvZXMgbm90IGRl c2NyaWJlIGEgd2F5IHRvIGF0dGFjayBHQ00gdGhhdA0KPiB3b3JrcyB3aXRoIGhpZ2hlciBjaGFu Y2Ugb2Ygc3VjY2VzcyB0aGFuIHdhcyBwcmV2aW91c2x5IGtub3duLg0KPiANCj4gU0dDTSwgZGVz Y3JpYmVkIGluIGh0dHA6Ly9lcHJpbnQuaWFjci5vcmcvMjAxMS8zMjYsIEkgZG9uJ3QgdGhpbmsg aXMgYQ0KPiBnb29kIGlkZWEsIGJlY2F1c2UgaXQgc2hhcmVzIEdDTSdzIGxlYXN0IGRlc2lyYWJs ZSBwcm9wZXJ0eSAoYSBicm9rZW4NCj4gaW1wbGVtZW50YXRpb24gdGhhdCByZXBlYXRzIElWcyB3 aWxsIGdpdmUgYXdheSBpdHMgYXV0aGVudGljYXRpb24ga2V5KQ0KPiBhbmQgaXQgaXMgbm90IGJh Y2t3YXJkcyBjb21wYXRpYmxlIHdpdGggR0NNLg0KDQpJbiBhZGRpdGlvbiwgU0dDTSBkb2Vzbid0 IGFkZHJlc3MgdGhlIHByb2JsZW0gdGhhdCdzIHVuZGVyIGRpc2N1c3Npb246IHRoYXQgYnkgbW9k aWZ5aW5nIGEgdmFsaWQgbi13b3JkIG1lc3NhZ2UsIHlvdSBjYW4gY3JlYXRlIGEgZm9yZ2VyeSB3 aXRoIHByb2JhYmlsaXR5IGNpcmNhIG4vMl4xMjguICBUaGUgc3BlY2lmaWMgYXR0YWNrIGRlc2Ny aWJlZCBpbiB0aGUgcGFwZXIgZG9lc24ndCB3b3JrLCBob3dldmVyIHRoZXJlIGFyZSBvdGhlciB3 YXlzIG9mIG1vZGlmeWluZyB0aGUgbWVzc2FnZSB0aGF0IHdpbGwgYWNoaWV2ZSB0aGlzIHByb2Jh YmlsaXR5IHdpdGggU0dDTS4NCg0KPiBJZiB0aGF0IGFsZ29yaXRobSBpcw0KPiBleHRlbmRlZCwg aXQgd291bGQgYmUgbXVjaCBtb3JlIHdvcnRod2hpbGUgdG8gaGF2ZSBhIGRpZmZlcmVudCBtZXRo b2QNCj4gb2YgZW5jcnlwdGluZyB0aGUgaGFzaCwgYXMgc3VnZ2VzdGVkIGJ5IEpvdXggKFNlY3Rp b24gNSBvZiBbM10pIGFuZCBhcw0KPiBkb25lIGJ5IHRoZSBDV0MgYXV0aG9ycyBbNF0uICBJdCBt aWdodCBiZSB1c2VmdWwgdG8gaGF2ZSBhbiBhZGRpdGlvbmFsDQo+IEVDQiBlbmNyeXB0aW9uIG9m IHRoZSB0YWcsIHdoaWNoIGNvdWxkIGJlIGRlc2NyaWJlZCBhcyBhIHBvc3QtDQo+IHByb2Nlc3Np bmcgc3RlcCBmb3IgR0NNIGFzIGl0IGlzIGN1cnJlbnRseSBzcGVjaWZpZWQuDQoNClRoYXQgd291 bGQgaGVscCBhZ2FpbnN0IGFjY2lkZW50YWwgcmV1c2Ugb2YgdGhlIG5vbmNlLiAgSG93ZXZlciwg aXQgZG9lc27igJl0IGFkZHJlc3MgZGVsaWJlcmF0ZSBmb3JnZXJ5IGF0dGVtcHRzIChiZWNhdXNl IHRoZSBmb3JnZXIgY2FuIGNob29zZSBub3QgdG8gbW9kaWZ5IHRoZSB0YWcpLg0KDQo+IA0KPiBy ZWdhcmRzLA0KPiANCj4gRGF2aWQNCj4gDQo+IFsxXSBodHRwOi8vY3NyYy5uaXN0Lmdvdi9ncm91 cHMvU1QvdG9vbGtpdC9CQ00vZG9jdW1lbnRzL2NvbW1lbnRzL0NXQy0NCj4gR0NNL0Zlcmd1c29u Mi5wZGYNCj4gDQo+IFsyXSBodHRwOi8vZXByaW50LmlhY3Iub3JnLzIwMDUvMTYxLnBkZg0KPiAN Cj4gWzNdDQo+IGh0dHA6Ly9jc3JjLm5pc3QuZ292L2dyb3Vwcy9TVC90b29sa2l0L0JDTS9kb2N1 bWVudHMvSm91eF9jb21tZW50cy5wZGYNCj4gDQo+IFs0XQ0KPiBodHRwOi8vY3NyYy5uaXN0Lmdv di9ncm91cHMvU1QvdG9vbGtpdC9CQ00vZG9jdW1lbnRzL3Byb3Bvc2VkbW9kZXMvY3djLw0KPiBj d2Mtc3BlYy5wZGYNCj4gDQo+IE9uIEp1bCAxOCwgMjAxMSwgYXQgMTI6NDYgUE0sIErDqXLDqW1p ZSBDcmVubmUgd3JvdGU6DQo+IA0KPiA+IEhpIGV2ZXJ5Ym9keSwNCj4gPg0KPiA+IFdoYXQgaXMg dGhlIGZlZWxpbmcgb2YgdGhlIGNvbW11bml0eSBhYm91dCB0aGUgcmVjZW50IHBvdGVudGlhbCBB RVMtDQo+ID4gR0NNDQo+ID4gd2Vha25lc3MgZHVlIHRvIHdlYWsga2V5cyA/IEknbSBzdGlsbCBj b25zaWRlcmluZyB0aGUgdXNhZ2Ugb2YgQUVTLQ0KPiA+IEdDTSB0byBiZQ0KPiA+IGFuIGF0dHJh Y3RpdmUgbW9kZSBmb3IgaGFyZHdhcmUgaW1wbGVtZW50YXRpb25zLiBJJ20gYSBsaXR0bGUgYml0 DQo+ID4gY29uY2VybmVkDQo+ID4gYWJvdXQgdGhpcyBzaW5jZSB0aGUgIm5ldyIgcHJvcG9zaXRp b24gZGVzY3JpYmVkIGhlcmUgd291bGQgcmVxdWlyZQ0KPiA+IHNpZ25pZmljYW50IGFkZGl0aW9u IG9mIGxvZ2ljLg0KPiA+DQo+ID4gaHR0cDovL2VwcmludC5pYWNyLm9yZy8yMDExLzIwMg0KPiA+ IGh0dHA6Ly9lcHJpbnQuaWFjci5vcmcvMjAxMS8zMjYNCj4gPg0KPiA+IFRoYW5rcywNCj4gPg0K PiA+IErDqXLDqW1pZQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBDZnJnIG1haWxpbmcgbGlzdA0KPiA+IENmcmdAaXJ0Zi5vcmcN Cj4gPiBodHRwOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZw0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ2ZyZyBtYWls aW5nIGxpc3QNCj4gQ2ZyZ0BpcnRmLm9yZw0KPiBodHRwOi8vd3d3LmlydGYub3JnL21haWxtYW4v bGlzdGluZm8vY2ZyZw0K From pgut001@login01.cs.auckland.ac.nz Mon Jul 18 22:02:38 2011 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 1D27621F856F for ; Mon, 18 Jul 2011 22:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLn7H-FLj-Z7 for ; Mon, 18 Jul 2011 22:02:34 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id E60CE21F856C for ; Mon, 18 Jul 2011 22:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311051754; x=1342587754; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20cfrg@irtf.org,=20jeremie.crenne@univ-ubs.fr |Subject:=20Re:=20[Cfrg]=20AES-GCM=20weakness |In-Reply-To:=20<000001cc4583$5f371720$1da54560$@crenne@u niv-ubs.fr>|Message-Id:=20|Date:=20Tue,=2019=20Jul=202011=2017:02:30 =20+1200; bh=FSIOn1z1OnERypJefSX8BUAeDRoI4HWV67xwafOp8Us=; b=N7Jogh/Ijpj7OSRuxCArMwxHppCyumdsb7IQY6tELj0YdWkoJwqYuDkY UenXQzo67BwNtgyBdu6wji56THkSEox5hNaRYvhXrVqvhj5oC9V/DNXrO in29DfQ4U8Mj7TuBJUFw7EH7MgBwyg5LuNOKMY8uwcBHUsr24ZnEuFAWs Q=; X-IronPort-AV: E=Sophos;i="4.67,226,1309694400"; d="scan'208";a="72525187" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Jul 2011 17:02:30 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qj2Ry-0002xB-HV; Tue, 19 Jul 2011 17:02:30 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qj2Ry-0002yg-CU; Tue, 19 Jul 2011 17:02:30 +1200 From: Peter Gutmann To: cfrg@irtf.org, jeremie.crenne@univ-ubs.fr In-Reply-To: <000001cc4583$5f371720$1da54560$@crenne@univ-ubs.fr> Message-Id: Date: Tue, 19 Jul 2011 17:02:30 +1200 Subject: Re: [Cfrg] AES-GCM weakness 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, 19 Jul 2011 05:02:38 -0000 =?iso-8859-1?Q?J=E9r=E9mie_Crenne?= writes: >What is the feeling of the community about the recent potential AES-GCM >weakness due to weak keys ? GCM's problem isn't the weak keys in AES-GCM, it's that it's a KSG rather than a standard block cipher. It's RC4 all over again, and we're going to see the same problems with GCM that we've already seen with RC4. There have been several already, and the only reason why we haven't seen more is that GCM isn't used that much (that is, it's used in a small number of widely-deployed applications, but hasn't become the universal algorithm of choice that RC4 was. Once, or if, it does, we'll see exactly the same problems that plagued RC4 throughout its effective lifetime). Peter. From mcgrew@cisco.com Tue Jul 19 06:22:57 2011 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 0946A21F85B1 for ; Tue, 19 Jul 2011 06:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.882 X-Spam-Level: X-Spam-Status: No, score=-103.882 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRFRz3m3txh4 for ; Tue, 19 Jul 2011 06:22:53 -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 2CC8F21F85A7 for ; Tue, 19 Jul 2011 06:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1711; q=dns/txt; s=iport; t=1311081773; x=1312291373; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=pDUhyKCLnQ94z0cvnesNe7Xq/dR6j+zyO6Ry7pTQPT0=; b=efg7SU1MOxdfGOQB16FpoEbSyTOQtWEIcUxIuCQExhyJ6VTm8PLZ9Wjd VSNtXT9DAZ+I80oW8ez820N2TlIzdjbYqc3wdhtY9IGr0SxJ1YcAIKKOf aI3hQraBzOGK6HeO2efvOpxchFj4sFfc/COqY4CMAFqc/EUmt9aPe5xPq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALKEJU6rRDoH/2dsb2JhbABUEKc7d60unkqFXV8Eh1SLE5AjVw X-IronPort-AV: E=Sophos;i="4.67,228,1309737600"; d="scan'208";a="4328123" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 19 Jul 2011 13:22:52 +0000 Received: from stealth-10-32-254-213.cisco.com (stealth-10-32-254-213.cisco.com [10.32.254.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6JDMoJt023481; Tue, 19 Jul 2011 13:22:51 GMT Message-Id: From: David McGrew To: Peter Gutmann In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 19 Jul 2011 06:22:46 -0700 References: X-Mailer: Apple Mail (2.936) Cc: cfrg@irtf.org Subject: [Cfrg] request for comments on "Generation of Deterministic Initialization Vectors (IVs) and Nonces" 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, 19 Jul 2011 13:22:57 -0000 Hi Peter, your note seems like a good introduction for this topic. I wrote up a draft describing how deterministic IVs should be generated, and reviewing how they are used in different protocols: http://tools.ietf.org/html//draft-mcgrew-iv-gen-00 Comments welcome. You have a lot of experience with the implementation of robust crypto software, so if you have additions or improvements to Section 5 that would be great. Side note: I was somewhat surprised that I was able to write a 24 page document on a topic as narrow as IV generation, and your reminder to everyone of how important a topic it is makes me feel a bit better :-) David On Jul 18, 2011, at 10:02 PM, Peter Gutmann wrote: > =?iso-8859-1?Q?J=E9r=E9mie_Crenne?= > writes: > >> What is the feeling of the community about the recent potential AES- >> GCM >> weakness due to weak keys ? > > GCM's problem isn't the weak keys in AES-GCM, it's that it's a KSG > rather than > a standard block cipher. It's RC4 all over again, and we're going > to see the > same problems with GCM that we've already seen with RC4. There have > been > several already, and the only reason why we haven't seen more is > that GCM > isn't used that much (that is, it's used in a small number of widely- > deployed > applications, but hasn't become the universal algorithm of choice > that RC4 > was. Once, or if, it does, we'll see exactly the same problems that > plagued > RC4 throughout its effective lifetime). > > Peter. > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From pgut001@login01.cs.auckland.ac.nz Tue Jul 19 08:36:34 2011 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 77E7921F8572 for ; Tue, 19 Jul 2011 08:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.646 X-Spam-Level: X-Spam-Status: No, score=-3.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMM0hcuXyZxD for ; Tue, 19 Jul 2011 08:36:30 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7759521F86A2 for ; Tue, 19 Jul 2011 08:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311089583; x=1342625583; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mcgrew@cisco.com,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20request=20for=20comments=20on=20"Genera tion=20of=20Deterministic=20Initialization=20Vectors=20(I Vs)=20and=20Nonces"|Cc:=20cfrg@irtf.org,=20jeremie.crenne @univ-ubs.fr|In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=2020=20Jul=202011=20 03:32:36=20+1200; bh=xgQli8OTpwXEgUJ8oboRApIEhZ9StQFNWqYjEg1BFOw=; b=Jfq5P4IyvXJfAxzmc7RwXt1ETazy/M2lKwVBCwVzI7tM6OBiFjjMS7II aMO85+XmmY8SluGD0sWc1rNFgKAI2iG1CjEdPETsNY1n6wphOWLiNecvw jSqbDEhRnm0sYDHvICjRS57G18HSFSGApf4Fu11XEUAsQEsUb1xUMbyt+ o=; X-IronPort-AV: E=Sophos;i="4.67,228,1309694400"; d="scan'208";a="72566541" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Jul 2011 03:32:37 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QjCHk-0004bY-HL; Wed, 20 Jul 2011 03:32:36 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QjCHk-00012k-Aw; Wed, 20 Jul 2011 03:32:36 +1200 From: Peter Gutmann To: mcgrew@cisco.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Wed, 20 Jul 2011 03:32:36 +1200 Cc: cfrg@irtf.org Subject: Re: [Cfrg] request for comments on "Generation of Deterministic Initialization Vectors (IVs) and Nonces" 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, 19 Jul 2011 15:36:34 -0000 David McGrew writes: >I wrote up a draft describing how deterministic IVs should be generated, and >reviewing how they are used in different protocols: > >http://tools.ietf.org/html//draft-mcgrew-iv-gen-00 >From a quick read, it looks good, with comprehensive coverage of all the issues. However (and you knew there was going to be a 'however' :-), it depends on who the target audience is. I'm concerned that, as with advice on the correct use of RC4, the people who will be reading this (security people) will probably be the ones who don't need it, and those who need it (J.Random software developer) won't be reading it, or even know that it exists. The problem is that CTR mode (and derived modes) don't work the way that (most) people think they do, and as 15-odd years of RC4 have shown, user education is unlikely to be effective in dealing with this. Developers don't even understand how to use IVs, with all-zero IVs being frighteningly popular when they're forced to use a mode like CBC ("I kept getting the first 8/16 bytes scrambled, but it's OK now, when you set the IV to zeroes everything works"). In CBC mode it's..., well not good, but also not instantly fatal like it is in CTR mode and derived modes. If the goal is to "fix the IV problem" then I think that the solution isn't to try and change the users to match the encryption (RC4 has shown that that doesn't work so well), but to change the encryption to match the users' expectations. So start by assuming that an all-zero IV will be used and design defensively around that. What we'd then need, when the cipher is used by non-cryptographers (which is what virtually all programmers are) is CBC or CFB instead of CTR, and GCFBM or GCBCM instead of GCM. Getting back to the draft, it'd be nice to recommend some single standard way of dealing with IVs (with an accompanying "AND STICK WITH IT!"). Did you notice, in Table 1, that every single protocol that uses them has invented their own incompatible way of handling them? Ugh. You can't even provide a standard implementation ("encrypt this message with AES-GCM") because each protocol has its own incompatible way of applying it. This also means that, for section 6, you're going to need test vectors not to exercise AES-GCM but to exercise AES-GCM as used in ESP, AES-GCM as used in IKE, AES-GCM as used in TLS, AES- GCM as used in ... Peter. From smb@cs.columbia.edu Tue Jul 19 09:55:31 2011 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 26C5A11E807E for ; Tue, 19 Jul 2011 09:55:31 -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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tybbFuOjgEts for ; Tue, 19 Jul 2011 09:55:24 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id BA2E411E8092 for ; Tue, 19 Jul 2011 09:55:22 -0700 (PDT) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p6JGtK6u022300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2011 12:55:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Tue, 19 Jul 2011 12:55:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <467FD947-3E53-443D-9975-902951F2A92E@cs.columbia.edu> References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> <87r55sc72o.fsf@latte.josefsson.org> <4FB2F68A-8B84-4953-A7B1-87D3E9DCEA2D@vpnc.org> To: Ted Krovetz X-Mailer: Apple Mail (2.1084) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: cfrg@irtf.org Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 19 Jul 2011 16:55:31 -0000 On Jul 15, 2011, at 12:45 06PM, Ted Krovetz wrote: >=20 >> If you know how "partial" that is, it would be useful for the draft. >=20 >> Ted, I think you can be rather more specific.=20 >=20 >=20 > In my opinion the point of the nonce-reuse warning is to impress upon = security engineers that catastrophe strikes if a nonce is reused during = encryption, and so they should make nonce reuse impossible. If nonce = reuse is impossible, then it is irrelevant how bad the damage is when = nonces are reused. >=20 > RFC writers need to walk a fine line: RFCs are primarily a description = of technology, but should include enough high-level context to inform = against poor usage. I think the current warnings on nonce reuse do this, = but if you can suggest a scenario where the current advice is being = heeded and yet it is still useful to know how bad not heeding it would = be, I'm open to adding some quantifications. >=20 > It may be worth adding a few paragraphs to the OCB paper describing = and quantifying the damage, but I'm a bit reluctant to do so in the ID. Also give a reference to a paper that gives more details. Beyond that, both this issue and the bound on plaintext suggest that this mode SHOULD NOT be used with manual key management. You should say that explicitly, perhaps with a reference to 4107. Devices that lose dynamic state on reboot -- and in particular, lose state about which nonces have been used -- are particularly vulnerable here; this merits an extra warning, especially because many WEP implementations have fallen victim to precisely this problem. See http://www.cs.berkeley.edu/~daw/papers/wep-mob01.pdf for details. --Steve Bellovin, https://www.cs.columbia.edu/~smb From dharkins@lounge.org Tue Jul 19 15:03:37 2011 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 7A3AB21F86BB for ; Tue, 19 Jul 2011 15:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 114PLJnPOY6T for ; Tue, 19 Jul 2011 15:03:33 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9344421F8587 for ; Tue, 19 Jul 2011 15:03:33 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A9348A88810C; Tue, 19 Jul 2011 15:03:32 -0700 (PDT) Received: from 204.15.0.66 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 19 Jul 2011 15:03:32 -0700 (PDT) Message-ID: <49fd928bf94d1d1920df676bb61fa198.squirrel@www.trepanning.net> In-Reply-To: References: Date: Tue, 19 Jul 2011 15:03:32 -0700 (PDT) From: "Dan Harkins" To: "Peter Gutmann" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: mcgrew@cisco.com, cfrg@irtf.org, pgut001@cs.auckland.ac.nz Subject: Re: [Cfrg] request for comments on "Generation of Deterministic Initialization Vectors (IVs) and Nonces" 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, 19 Jul 2011 22:03:37 -0000 On Tue, July 19, 2011 8:32 am, Peter Gutmann wrote: > David McGrew writes: > >>I wrote up a draft describing how deterministic IVs should be generated, >> and >>reviewing how they are used in different protocols: >> >>http://tools.ietf.org/html//draft-mcgrew-iv-gen-00 > > From a quick read, it looks good, with comprehensive coverage of all the > issues. However (and you knew there was going to be a 'however' :-), it > depends on who the target audience is. I'm concerned that, as with advice > on > the correct use of RC4, the people who will be reading this (security > people) > will probably be the ones who don't need it, and those who need it > (J.Random > software developer) won't be reading it, or even know that it exists. The > problem is that CTR mode (and derived modes) don't work the way that > (most) > people think they do, and as 15-odd years of RC4 have shown, user > education is > unlikely to be effective in dealing with this. Developers don't even > understand how to use IVs, with all-zero IVs being frighteningly popular > when > they're forced to use a mode like CBC ("I kept getting the first 8/16 > bytes > scrambled, but it's OK now, when you set the IV to zeroes everything > works"). > In CBC mode it's..., well not good, but also not instantly fatal like it > is in > CTR mode and derived modes. > > If the goal is to "fix the IV problem" then I think that the solution > isn't to > try and change the users to match the encryption (RC4 has shown that that > doesn't work so well), but to change the encryption to match the users' > expectations. So start by assuming that an all-zero IV will be used and > design defensively around that. What we'd then need, when the cipher is > used > by non-cryptographers (which is what virtually all programmers are) is CBC > or > CFB instead of CTR, and GCFBM or GCBCM instead of GCM. Let me remind everyone of SIV mode*. It's a CTR mode derivative but is resistant to nonce misuse. Unlike CBC, the nonce doesn't need to be unguessable. And it even provides a strong assurance of security if the nonce is reused. One of the drawbacks of CBC (as opposed to SIV) is that it does not do authenticated encryption and something like an HMAC-xxx is required. Now if the real problem is, as you suggest, that J.Random Software Developer won't be reading the literature he won't know whether he should be doing authenticate-then-encrypt or encrypt-then-authenticate or even encrypt-and-authenticate. With SIV it's all integrated. J.Random doesn't need to worry about any of that. And he doesn't need to worry about whether the nonce he's supplying is random, unguessable, or deterministic. regards, Dan. [*] http://www.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf [*] RFC 5297 From pgut001@login01.cs.auckland.ac.nz Wed Jul 20 00:50:20 2011 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 BFF4D21F873A for ; Wed, 20 Jul 2011 00:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.643 X-Spam-Level: X-Spam-Status: No, score=-3.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJkrZ2xv1Fi5 for ; Wed, 20 Jul 2011 00:50:16 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF4B21F872F for ; Wed, 20 Jul 2011 00:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311148217; x=1342684217; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dharkins@lounge.org,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[Cfrg]=20request=20for=20comments=20on =20"Generation=20of=20Deterministic=20Initialization=20Ve ctors=20(IVs)=20and=20Nonces"|Cc:=20cfrg@irtf.org,=20mcgr ew@cisco.com|In-Reply-To:=20<49fd928bf94d1d1920df676bb61f a198.squirrel@www.trepanning.net>|Message-Id:=20|Date:=20Wed,=2020 =20Jul=202011=2019:50:07=20+1200; bh=fupqVjnY9wqsXfjNcJSoTbDFVGuhRCe0YLrOoK/hYkc=; b=tVmjTXbseq3ZVL2FWwNPsQLv7Q97rWK+QAdGiWwDhqHvLSIqUFoxOXWM lm0TzSd+CyTBwEro0EGTvhn98YyG0SS0vBOVbAGj6MebramdOzxmBVI02 zkw+fbYF7o/TGqC1LJSwVN77hNEBHn42cz7ghYg87vbM5WfMsCqtejBWF U=; X-IronPort-AV: E=Sophos;i="4.67,233,1309694400"; d="scan'208";a="72896870" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Jul 2011 19:50:07 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QjRXj-0005YD-Hz; Wed, 20 Jul 2011 19:50:07 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QjRXj-0002HE-HM; Wed, 20 Jul 2011 19:50:07 +1200 From: Peter Gutmann To: dharkins@lounge.org, pgut001@cs.auckland.ac.nz In-Reply-To: <49fd928bf94d1d1920df676bb61fa198.squirrel@www.trepanning.net> Message-Id: Date: Wed, 20 Jul 2011 19:50:07 +1200 Cc: mcgrew@cisco.com, cfrg@irtf.org Subject: Re: [Cfrg] request for comments on "Generation of Deterministic Initialization Vectors (IVs) and Nonces" 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, 20 Jul 2011 07:50:20 -0000 "Dan Harkins" writes: >Let me remind everyone of SIV mode*. It's a CTR mode derivative but is >resistant to nonce misuse. Unlike CBC, the nonce doesn't need to be >unguessable. And it even provides a strong assurance of security if the nonce >is reused. Doesn't SIV require the entire message to be buffered, which makes it unusable in streaming implementations? [Checks] Unless I've misinterpreted some part of Fig.3 and Fig.8 of RFC 5297, this can't be used in a streaming implementation because the CMAC operation to create the IV has to make a complete pass over the message before you can start encrypting (this is also similar to a key-wrap mechanism that Colin Plumb and I came up with for RFC 3211, although it'd need a tweak to use a proper MAC for full integrity-protection, it was designed for non-expanding 512-byte disk sector encryption and dates from the early 1990s, so it predates pretty much all of the work that newer modes and mechanisms are built on). SIV is quite nice for something like 802.11, SRTP, DTLS, and others, but unfortunately won't work as a general-purpose mechanism. Are there any IP issues around SIV? Peter. From ietf@augustcellars.com Wed Jul 20 09:58:56 2011 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 3459321F8A6F for ; Wed, 20 Jul 2011 09:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7eSj68udbaK for ; Wed, 20 Jul 2011 09:58:52 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6D521F8A4F for ; Wed, 20 Jul 2011 09:58:51 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 3E1D76A455; Wed, 20 Jul 2011 09:58:51 -0700 (PDT) From: "Jim Schaad" To: "'Peter Gutmann'" , References: <49fd928bf94d1d1920df676bb61fa198.squirrel@www.trepanning.net> In-Reply-To: Date: Wed, 20 Jul 2011 09:57:52 -0700 Message-ID: <005f01cc46fe$2a89e760$7f9db620$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLHV9+CD1G1GB/r95qLlfH09HR6y5L/TH0Q Content-Language: en-us Cc: mcgrew@cisco.com, cfrg@irtf.org Subject: Re: [Cfrg] request for comments on "Generation of Deterministic Initialization Vectors (IVs) and Nonces" 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, 20 Jul 2011 16:58:56 -0000 That is completely correct. SIV requires two passes for the sender - but only one pass for the recipient. > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Peter Gutmann > Sent: Wednesday, July 20, 2011 12:50 AM > To: dharkins@lounge.org; pgut001@cs.auckland.ac.nz > Cc: mcgrew@cisco.com; cfrg@irtf.org > Subject: Re: [Cfrg] request for comments on "Generation of Deterministic > Initialization Vectors (IVs) and Nonces" > > "Dan Harkins" writes: > > >Let me remind everyone of SIV mode*. It's a CTR mode derivative but is > >resistant to nonce misuse. Unlike CBC, the nonce doesn't need to be > >unguessable. And it even provides a strong assurance of security if the > >nonce is reused. > > Doesn't SIV require the entire message to be buffered, which makes it > unusable in streaming implementations? > > [Checks] > > Unless I've misinterpreted some part of Fig.3 and Fig.8 of RFC 5297, this can't > be used in a streaming implementation because the CMAC operation to > create the IV has to make a complete pass over the message before you can > start encrypting (this is also similar to a key-wrap mechanism that Colin Plumb > and I came up with for RFC 3211, although it'd need a tweak to use a proper > MAC for full integrity-protection, it was designed for non-expanding 512- > byte disk sector encryption and dates from the early 1990s, so it predates > pretty much all of the work that newer modes and mechanisms are built on). > SIV is quite nice for something like 802.11, SRTP, DTLS, and others, but > unfortunately won't work as a general-purpose mechanism. > > Are there any IP issues around SIV? > > Peter. > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From dmjacobson@sbcglobal.net Wed Jul 20 10:45:04 2011 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 1628521F8ACC for ; Wed, 20 Jul 2011 10:45:04 -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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRGPzJ0uvs2E for ; Wed, 20 Jul 2011 10:45:00 -0700 (PDT) Received: from nm15.access.bullet.mail.mud.yahoo.com (nm15.access.bullet.mail.mud.yahoo.com [66.94.237.216]) by ietfa.amsl.com (Postfix) with SMTP id 3428721F8576 for ; Wed, 20 Jul 2011 10:45:00 -0700 (PDT) Received: from [66.94.237.198] by nm15.access.bullet.mail.mud.yahoo.com with NNFMP; 20 Jul 2011 17:44:56 -0000 Received: from [66.94.237.100] by tm9.access.bullet.mail.mud.yahoo.com with NNFMP; 20 Jul 2011 17:44:56 -0000 Received: from [127.0.0.1] by omp1005.access.mail.mud.yahoo.com with NNFMP; 20 Jul 2011 17:44:56 -0000 X-Yahoo-Newman-Id: 329523.10112.bm@omp1005.access.mail.mud.yahoo.com Received: (qmail 49121 invoked from network); 20 Jul 2011 17:44:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ps9AGy9p4Duse21SsWcXKKIllHaRsqpzXObkLG/ZOoSSDcm5ec37SqN61Z9VtNAKbUpycuWEnn9jx6DzcOdhhtewOrqsLjrBNHM+IH2mnqe+c5PPHrja/AI/EiIwf6s+btiyV9afscxQh9Gx4/TO8cgafqC9zHWHAkCXJh2EVc4= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1311183895; bh=+9E42iUwWl2wACTnand+XDi9opCT2zD5Ix2rPRJKIdY=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=1O55W66YBgfRs2/0WZWrJ+7Kxl7zlsVylV6knMQQq4UmqRjCY2MvuUqW3ivx/TsiDtpZt08jP1oaMO8Mv4H8xn1ibiWGKQfG2C3Qmowkjp0ShbScolAHlSfFKzlN2nLMYDinpkLeZe6wFafUUTiz+ptY3JzeJ0hBS5Nldx5m4ro= Received: from [192.168.1.66] (dmjacobson@99.120.98.171 with plain) by smtp105.sbc.mail.ne1.yahoo.com with SMTP; 20 Jul 2011 10:44:55 -0700 PDT X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g-- X-YMail-OSG: dLqHiLEVM1mfcV8lzfjL_eQTt1XNXaEB5B7uDsjyyJAS.4g uAQnFi3BeRq3Y150C.as4fJDYueJy397dgan.1rM11dm2f0jp7im4_bOTSDq n_VRJrTtIEwGnbJ0FUktbKl8kkXP53QscethMYKd3noTbPz.4xD27fZozY45 haJZI_SbSbBM3wrJRju7hC75xUHAT0S0L8OFbsX8vOAH5vuvQC48lIUJLWwA 0W6HMDoebNUGiWXE5Q6eHISfE13lw4_W8QkZs8YF8Yq2Wq9y2EupPgebcEIu Y3TGdVp4UC7EWWPRcoVDyZIe7LOSyZtPih22OcNTg0B9_gTpaCPiKm35nXr3 uRmWvM4h48lp.joFSXsJfaCY1S_RGj1APdzEXOerJKhI3JtNcsGixz7XYlSa KSMlUmYug_NOor82nwLjxPKA5ygWj.s8CCfIUmDtnRq0MmizQ11tnI4Nheew .ftXA_p4yir.doatbN52GctwWUwNt0Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E271418.3010404@sbcglobal.net> Date: Wed, 20 Jul 2011 10:44:56 -0700 From: David Jacobson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: cfrg@irtf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Cfrg] request for comments on "Generation of Deterministic Initialization Vectors (IVs) and Nonces" 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, 20 Jul 2011 17:45:04 -0000 I looked at David McGrew's IV draft. Here are some comments. Section 5 is about implementation. The scope is limited to deterministic IVs. One of the premises is that IV generation is a crypto operation that needs skill and care to be correct, and should not be left to application developers. Two methods are indicated: generate the IV in the crypto module, and (for backward compatibility) the application generates the IV, but the crypto module verifies that the supplied IVs satisfy the requirements. I'll address only the case of generating IVs in the crypto module. If IVs are generated without a source of random numbers, then there must be non-volatile memory if keys last across reboots or power cycles. Yet most designers of crypto modules want to stay away from as much system dependency as possible. In addition, many systems do not have reliable non-volatile memory with sufficiently fine grain. Suppose the system has just booted. It reads the counter from a file in the file system, increments it, writes it back, and then encrypts and transmits the first message using the new counter to derive the IV. Then power is lost or the system crashes. If the writes are buffered, the new counter value may not have made it to the storage medium. This illustrates that an entanglement between crypto and systems issues is difficult to avoid, and just putting the IV generation in the crypto module does not guarantee that everything is right. In addition, if the crypto module uses the file system to store the counter, then the crypto module must have code to access the file system (system dependent) and there must be a pre-agreed file name (more system dependency), or it must be some sort of parameter. In any case the file name has to be managed correctly so the file is not shared between different subsystems with their own encryption. One minor comment is that the proposed scheme shows the IV going back to the application. It is not obvious why the application needs to know the IV. Finally, the draft is limited to deterministic IVs. It might be good to address both deterministic and random IVs in the same document. Since random numbers are already needed for crypto, there should a facility inside the crypto module for getting them, and using it for IV generation would add almost no complexity. Addressing random IVs would allow you to educate the readers about the need to limit the number of messages to avoid collisions due to the birthday bound. --David Jacobson On 7/19/2011 6:22 AM, David McGrew wrote: > Hi Peter, > > your note seems like a good introduction for this topic. I wrote up a > draft describing how deterministic IVs should be generated, and > reviewing how they are used in different protocols: > > http://tools.ietf.org/html//draft-mcgrew-iv-gen-00 > > Comments welcome. You have a lot of experience with the > implementation of robust crypto software, so if you have additions or > improvements to Section 5 that would be great. > > Side note: I was somewhat surprised that I was able to write a 24 page > document on a topic as narrow as IV generation, and your reminder to > everyone of how important a topic it is makes me feel a bit better :-) > > David > > On Jul 18, 2011, at 10:02 PM, Peter Gutmann wrote: > >> =?iso-8859-1?Q?J=E9r=E9mie_Crenne?= writes: >> >>> What is the feeling of the community about the recent potential AES-GCM >>> weakness due to weak keys ? >> >> GCM's problem isn't the weak keys in AES-GCM, it's that it's a KSG >> rather than >> a standard block cipher. It's RC4 all over again, and we're going to >> see the >> same problems with GCM that we've already seen with RC4. There have >> been >> several already, and the only reason why we haven't seen more is that >> GCM >> isn't used that much (that is, it's used in a small number of >> widely-deployed >> applications, but hasn't become the universal algorithm of choice >> that RC4 >> was. Once, or if, it does, we'll see exactly the same problems that >> plagued >> RC4 throughout its effective lifetime). >> >> Peter. >> _______________________________________________ >> 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 > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1390 / Virus Database: 1518/3773 - Release Date: 07/18/11 > > From dharkins@lounge.org Wed Jul 20 11:36:51 2011 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 44E0321F87A4 for ; Wed, 20 Jul 2011 11:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxb+U8-Fcwfu for ; Wed, 20 Jul 2011 11:36:46 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E243B21F89BE for ; Wed, 20 Jul 2011 11:36:46 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6DE63A88810C; Wed, 20 Jul 2011 11:36:46 -0700 (PDT) Received: from 204.15.0.66 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 20 Jul 2011 11:36:46 -0700 (PDT) Message-ID: <53eef72039a16206be6256be21313802.squirrel@www.trepanning.net> In-Reply-To: References: Date: Wed, 20 Jul 2011 11:36:46 -0700 (PDT) From: "Dan Harkins" To: "Peter Gutmann" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: mcgrew@cisco.com, cfrg@irtf.org, pgut001@cs.auckland.ac.nz Subject: Re: [Cfrg] request for comments on "Generation of Deterministic Initialization Vectors (IVs) and Nonces" 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, 20 Jul 2011 18:36:51 -0000 Hi Peter, On Wed, July 20, 2011 12:50 am, Peter Gutmann wrote: > "Dan Harkins" writes: > >>Let me remind everyone of SIV mode*. It's a CTR mode derivative but is >>resistant to nonce misuse. Unlike CBC, the nonce doesn't need to be >>unguessable. And it even provides a strong assurance of security if the >> nonce >>is reused. > > Doesn't SIV require the entire message to be buffered, which makes it > unusable > in streaming implementations? > > [Checks] > > Unless I've misinterpreted some part of Fig.3 and Fig.8 of RFC 5297, this > can't be used in a streaming implementation because the CMAC operation to > create the IV has to make a complete pass over the message before you can > start encrypting (this is also similar to a key-wrap mechanism that Colin > Plumb and I came up with for RFC 3211, although it'd need a tweak to use a > proper MAC for full integrity-protection, it was designed for > non-expanding > 512-byte disk sector encryption and dates from the early 1990s, so it > predates > pretty much all of the work that newer modes and mechanisms are built on). > SIV is quite nice for something like 802.11, SRTP, DTLS, and others, but > unfortunately won't work as a general-purpose mechanism. You're correct. All the AAD and plaintext must be known prior to invocation of the encrypt function. > Are there any IP issues around SIV? Not that I know of. The inventors have made the following statement on the subject of IP. http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/siv/ip.pdf regards, Dan. From mcgrew@cisco.com Thu Jul 21 14:40:29 2011 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 4BC5E21F86D0 for ; Thu, 21 Jul 2011 14:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.561 X-Spam-Level: X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db9mwshHCf1R for ; Thu, 21 Jul 2011 14:40:28 -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 4E1E021F86AA for ; Thu, 21 Jul 2011 14:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=3117; q=dns/txt; s=iport; t=1311284428; x=1312494028; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=/wbB00EgQBC4NqXFCMq6GcUeiFcUIs6dW+mVUZ9c1jI=; b=b7Ji+tCLD9aRPGnCftn1TjmaZz2R9B1yU0onKy5S6iKdK3MeclXsbFUg rcGSqT7CV0a6xBlJPxn5f5ed+ibTHR7YbTkhbmYRBDQRx2wWAgeIWZKRQ g8PWPsHnXDPn5bzIvvLMuCvf4U3JE2xAEPmexivuRkwn4ZG1ujCtU7F+5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF6cKE6rRDoH/2dsb2JhbABTG6cnd4h8nQWeIIVgXwSHVYsZkH4 X-IronPort-AV: E=Sophos;i="4.67,243,1309737600"; d="scan'208";a="5273105" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-9.cisco.com with ESMTP; 21 Jul 2011 21:40:27 +0000 Received: from stealth-10-32-254-213.cisco.com (stealth-10-32-254-213.cisco.com [10.32.254.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6LLeQbD024185; Thu, 21 Jul 2011 21:40:26 GMT Message-Id: <495BCE7D-EA79-4E60-8D7B-0851FFE366CF@cisco.com> From: David McGrew To: Ted Krovetz In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 21 Jul 2011 14:40:25 -0700 References: <22798CA3-3D49-4652-A5DB-EC25ACCD245C@krovetz.net> <2B90DB3F-327A-45B3-B1AE-C8D19825CF31@krovetz.net> <87r55sc72o.fsf@latte.josefsson.org> <4FB2F68A-8B84-4953-A7B1-87D3E9DCEA2D@vpnc.org> X-Mailer: Apple Mail (2.936) Cc: cfrg@irtf.org Subject: Re: [Cfrg] Request For Comments: OCB Internet-Draft 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, 21 Jul 2011 21:40:29 -0000 Hi Ted, thanks for this contribution. I have not yet read it through, but after I do I'll send you my thoughts. I have a comment on the security considerations being discussed. This topic was already worked through for GCM and CCM, and it would be best to use similar language for OCB. On Jul 15, 2011, at 9:45 AM, Ted Krovetz wrote: > >> If you know how "partial" that is, it would be useful for the draft. > >> Ted, I think you can be rather more specific. > > > In my opinion the point of the nonce-reuse warning is to impress > upon security engineers that catastrophe strikes if a nonce is > reused during encryption, and so they should make nonce reuse > impossible. If nonce reuse is impossible, then it is irrelevant how > bad the damage is when nonces are reused. > > RFC writers need to walk a fine line: RFCs are primarily a > description of technology, but should include enough high-level > context to inform against poor usage. I think the current warnings > on nonce reuse do this, but if you can suggest a scenario where the > current advice is being heeded and yet it is still useful to know > how bad not heeding it would be, I'm open to adding some > quantifications. > > It may be worth adding a few paragraphs to the OCB paper describing > and quantifying the damage, but I'm a bit reluctant to do so in the > ID. The draft should include text like that of Section 5.1.1 of RFC 5116, ideally using the same wording where possible, ideally in a subsection entitled "Nonce Reuse". I think this text, adapted from that section, is appropriate: The inadvertent reuse of the same nonce by two invocations of the OCB encryption operation, with the same key, but with distinct plaintext values, undermines the confidentiality of the plaintexts protected in those two invocations, and undermines all of the authenticity and integrity protection provided by that key. For this reason, OCB should only be used whenever nonce uniqueness can be provided with assurance. Note that it is acceptable to input the same nonce value multiple times to the decryption operation. The security consequences are quite serious if an attacker observes two ciphertexts that were created using the same nonce and key values, unless the plaintext and AD values in both invocations of the encrypt operation were identical. First, a loss of confidentiality ensues because he will be able to infer relationships between the two plaintext values. Second, a loss of integrity ensues because the attacker will be able to recover secret information used to provide data integrity. Knowledge of this key makes subsequent forgeries trivial. Here I am assuming that the newer version of OCB is still vulnerable to Fergusen's collision attack (http://www.cs.ucdavis.edu/~rogaway/ocb/fe02.pdf ); please correct me if I'm wrong. David > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From mcgrew@cisco.com Wed Jul 27 08:24:22 2011 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 8848F11E8071 for ; Wed, 27 Jul 2011 08:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=-1.142, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRbxh1TSj3r9 for ; Wed, 27 Jul 2011 08:24:21 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9250611E8099 for ; Wed, 27 Jul 2011 08:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=15971; q=dns/txt; s=iport; t=1311780261; x=1312989861; h=message-id:from:to:mime-version:subject:date; bh=xx3XE2M5A8CnLoFH1yAwRk7JqiTeTgHWKCyHbqZwbz0=; b=EBLkr9FB298x++RkCgAZjKXH3KAflsuor59i1qxTI+qIw3rnMGNtwTGz 4TWDzH3KuCJvHYqIkaXUpAZ0B5Wq8bKA485NsdYntb2VjgIL4pnAWrLKu /yUAxsLe068J81eu/BzotfZSo03OQsCiuhUl3Kis/FzWFXWFOe48UsoEb 0=; X-Files: md5-stds-summary-01.csv : 11387 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYHAH4sME6rRDoH/2dsb2JhbABQAYFzgRaYGY4dZ3erQoEjnmqFYV8Eh1eLHpEC X-IronPort-AV: E=Sophos;i="4.67,276,1309737600"; d="csv'?scan'208";a="7024344" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jul 2011 15:24:20 +0000 Received: from dhcp-1783.meeting.ietf.org ([10.86.254.17]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6RFOJ98022739 for ; Wed, 27 Jul 2011 15:24:19 GMT Message-Id: From: David McGrew To: cfrg@irtf.org Content-Type: multipart/mixed; boundary=Apple-Mail-28-613093399 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jul 2011 08:24:18 -0700 X-Mailer: Apple Mail (2.936) Subject: [Cfrg] meeting at IETF 81 to discuss review of MD5 uses 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, 27 Jul 2011 15:24:22 -0000 --Apple-Mail-28-613093399 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi All, anyone interested in discussing the review of IETF drafts that use MD5 (and potentially other algos going forward) should meet me and Marshall at the IETF registration desk at 11:30 AM tomorrow (Thursday July 28). Marshall and Joachim and I triaged the ~ 50 current drafts that are standards track and reference MD5. A summary is in the attached spreadsheet, in case you are interested. Next step is to send a note to the authors for the 17 drafts that appear to need an addition or change. regards, David --Apple-Mail-28-613093399 Content-Disposition: attachment; filename=md5-stds-summary-01.csv Content-Type: application/octet-stream; x-unix-mode=0644; name="md5-stds-summary-01.csv" Content-Transfer-Encoding: quoted-printable ,"Title","WG=20(if=20any)","Status","Defines=20authentication=20= mechanisms=20recommend=20MD5=20over=20other=20algorithms=20or=20lack=20= options=20to=20use=20other=20algorithms","reference=20other=20= specifications=20that=20recommend=20MD5=20or=20that=20lack=20alternative=20= algorithms",=0A"draft-zorn-emu-team-02.txt","=20The=20Tunneled=20= Extensible=20Authentication=20Method=20(TEAM)",,,"X",,"=20= TLS_RSA_WITH_RC4_128_MD5=20is=20a=20SHOULD;=20why?=20=20=20Need=20to=20= recommend=20against=20MD5;=20should=20cite=206151"=0A= "draft-lu-fn-transport-01.txt","=20Transport=20of=20Fast=20Notification=20= Messages",,,"X",,"May=20have=20issues.=20MD5=20is=20the=20ONLY=20hash=20= used.=20No=20mention=20of=206151"=0A"draft-jennings-vipr-vap-00.txt","=20= Verification=20Involving=20PSTN=20Reachability:=20The=20ViPR=20Access=20= Protocol=20(VAP)",,,"X",,"this=20is=20a=20hmac=20use,=20but=20clearly=20= algorithm=20agility=20is=20needed;=20appears=20to=20use=20both=20MD5=20= and=20SHA-1"=0A"draft-ietf-rmt-flute-revised-12.txt","=20FLUTE=20-=20= File=20Delivery=20over=20Unidirectional=20Transport",,,"X",,"Uses=20HTTP=20= Content=20MD5.=20=C2=A0May=20have=20issues.=20MD5=20is=20the=20only=20= hash=20used.=20no=20Mention=20of=206151"=0A= "draft-ietf-mmusic-rfc2326bis-27.txt","=20M.=20Westerlund=20Ericsson=20= AB=20M.=20Stiemerling=20(Ed.)=20NEC=20March=209=202011","=20MMUSIC=20= Working=20Group",,"X",,"Since=20this=20is=20a=20major=20(not=20backwards=20= compatible)=20update=20of=20RSTP=20it=20should=20try=20and=20not=20use=20= MD5.=20We=20need=20to=20work=20with=20the=20authors=20to=20better=20= understand=20the=20usage=20of=20MD5=20in=20the=20protocol=20and=20why=20= MD5=20is=20used=20in=20the=20new=20version.=20=20"=0A= "draft-ietf-dime-rfc3588bis-26.txt","=20Diameter=20Base=20= Protocol",,,"X",,"uses=20TLS_RSA_WITH_RC4_128_MD5=20(which=20won't=20= work=20for=20DTLS,=20despite=20what=20the=20draft=20says)"=0A= "draft-ietf-dhc-forcerenew-nonce-01.txt","=20Forcerenew=20Nonce=20= Authentication",,,"X",,"Uses=20HMAC-MD5.=20=20Does=20not=20cite=20= RFC6151.=20=20This=20use=20of=20MD5=20is=20probably=20OK,=20but=20what=20= is=20not=20OK=20is=20that=20there=20is=20no=20crypto-agility;=20no=20= other=20MACs=20are=20cited.=20=20I=20suggest=20this=20draft=20add=20= HMAC-SHA-256=20as=20an=20option,=20and=20cite=20RFC6151."=0A= "draft-salgueiro-secure-state-management-04.txt","=20Securing=20HTTP=20= State=20Management=20Information",,,,"X","Could=20be=20better.=20MD5=20= is=20listed=20but=20not=20deprecated.=20This=20one=20says=20""Clients=20= MAY=20support=20any=20number=20of=20MAC=20functions,=20but=20MUST=20= support=20either=20HMAC=20with=20MD5=20[10]=20(""hmac-md5"")=20or=20HMAC=20= with=20SHA-1=20[9]=20(""hmac-sha-1"").=20Servers=20MUST=20support=20both=20= hmac-md5=20and=20hmac-sha-1=20and=20SHOULD=20support=20a=20wide=20= variety=20of=20popular=20MAC=20functions.""=20=C2=A0=20IMO=20if=20this=20= is=20new=20work=20it=20should=20just=20drop=20HMAC-MD5."=0A= "draft-mekking-dnsop-auto-cpsync-01.txt","=20Automated=20(DNSSEC)=20= Child=20Parent=20Synchronization=20using=20DNS=20= UPDATE",,,,"X","Mentions=20both=20HMAC-MD5=20and=20HMAC-SHA1,=20but=20no=20= other=20MACs.=20=20TSIG=20[RFC4635]=20requires=20HMAC-SHA-256=20as=20= well;=20I=20suggest=20this=20draft=20add=20a=20reference=20to=20that=20= MAC."=0A"draft-ietf-nfsv4-rfc3530bis-12.txt","=20Network=20File=20System=20= (NFS)=20Version=204=20Protocol",,,,"X","Can't=20change=20usage=20of=20= MD5,=20but=20should=20cite=20RFC6151=20and=20should=20comment=20on=20DES=20= deprecation."=0A"draft-ietf-msec-gdoi-update-08.txt","=20The=20Group=20= Domain=20of=20Interpretation","=20MSEC=20Working=20= Group",,,"X","Suggestion:=20Get=20the=20authors=20to=20include=20a=20= reference=20to=20RTC=206151=20as=20well=20as=20a=20short=20blurb.=20This=20= to=20add=20strength=20to=20footnote"=0A= "draft-ietf-isis-ieee-aq-05.txt","=20March=208=202011=20",,,,"X","It=20= looks=20like=20this=20one=20is=20referencing=20a=20use=20of=20HMAC-MD5=20= in=C2=A0802.1Q.=20=C2=A0The=20protocol=20should=20definitely=20add=20= algorithm=20agility,=20but=20it=20might=20be=20that=20the=20IEEE=20doc=20= is=20the=20spec=20that=20needs=20to=20change.=20=C2=A0"=0A= "draft-ietf-httpbis-p2-semantics-14.txt","=20HTTP/1.1=20part=202:=20= Message=20Semantics",,,,"X","=20should=20possibly=20be=20updated=20with=20= a=20note=20that=20the=20field=20will=20be=20removed"=0A= "draft-ietf-ftpext2-hash-01.txt","=20File=20Transfer=20Protocol=20HASH=20= Command=20for=20Cryptographic=20Hashes","=20FTPEXT2=20Working=20= Group",,,"X","=20The=20draft=20does=20not=20contain=20any=20discussions=20= on=20hash=20functions=20to=20use=20nor=20any=20recommendations=20or=20= reference=20to=20such=20recommendations.=20=20Should=20cite=20RFC=20= 6151,=20and=20discourage=20MD5=20use.=20=20"=0A= "draft-dickinson-dnsop-nameserver-control-02.txt","=20A=20name=20server=20= Data=20Model",,,,"X","Mentions=20both=20HMAC-MD5=20and=20HMAC-SHA1,=20= but=20no=20other=20MACs.=20=20TSIG=20[RFC4635]=20requires=20HMAC-SHA-256=20= as=20well;=20I=20suggest=20this=20draft=20add=20a=20reference=20to=20= that=20MAC."=0A"draft-cantor-ietf-kitten-saml-ec-01.txt","=20SAML=20= Enhanced=20Client=20SASL=20and=20GSS-API=20Mechanisms",,,,"X","Mentions=20= Digest-MD5.=20=20Ugh.=20=20Probably=20doesn't=20need=20to=20add=20= anything,=20but=20I'm=20not=20sure.=20=20I=20don't=20see=20anywhere=20= that=20the=20security=20considerations=20give=20the=20right=20= disclaimer."=0A"draft-zhou-emu-eap-fastv2-00.txt","=20Flexible=20= Authentication=20via=20Secure=20Tunneling=20Extensible=20Authentication=20= Protocol=20(EAP-FAST)=20Version=202","=20EMU=20Working=20= Group",,,,"Probably=20OK.=20Uses=20same=20text=20as=20= draft-zhou-emu-eap-fastv2-00.txt"=0A"draft-weis-gdoi-mac-tek-02.txt","=20= GDOI=20Generic=20Message=20Authentication=20Code=20Policy","=20MSEC=20= Working=20Group",,,,"=20Probably=20OK.=20MD5=20called=20weak,=206151=20= not=20referenced"=0A"draft-shen-traceroute-ping-ext-01.txt","=20= Traceroute=20and=20Ping=20Message=20Extension",,,,,"=20May=20be=20OK.=20= Could=20be=20better.=20No=20mention=20of=206151.=20Unclear=20what=20the=20= threat=20might=20be.=20"=0A"draft-pritikin-est-01.txt","=20Enrollment=20= over=20Secure=20Transport",,,,,"=20May=20be=20OK.=20MD5=20only=20= mentioned=20in=20passing.=20Individual=20submission=20in=20an=20early=20= state."=0A"draft-papneja-bgp-basic-dp-convergence-01.txt","=20Basic=20= BGP=20Convergence=20Benchmarking=20Methodology=20for=20Data=20Plane=20= Convergence","=20Benchmarking=20Working=20Group",,,,"=20OK.=20MD5=20is=20= mandated=20by=20underlying=20protocol.=20"=0A= "draft-nir-tls-eap-11.txt","=20TLS=20using=20EAP=20Authentication","=20= TLS=20Working=20Group",,,,"=20Unclear.=20MD5=20is=20barely=20mentioned.=20= Is=20this=20document=20setting=20a=20protocol=20standard=20?=20"=0A= "draft-kent-bgpsec-threats-01.txt","=20Threat=20Model=20for=20BGP=20Path=20= Security=20",,,,,"No=20direct=20problem.=20Inclear=20if=20MD5=20should=20= be=20added=20to=20threat=20model,=20as=20it=20is=20used=20by=20BGP"=0A= "draft-ietf-urnbis-rfc3188bis-nbn-urn-00.txt","=20Using=20National=20= Bibliography=20Numbers=20as=20Uniform=20Resource=20Names",,,,,"Could=20= be=20better.=20MD5=20is=20listed=20as=20possibility.=20Unclear=20if=20= there=20are=20any=20security=20issues=20here"=0A= "draft-ietf-tcpm-rfc1948bis-00.txt","=20Defending=20Against=20Sequence=20= Number=20Attacks",,,,,"Could=20be=20OK=20:"=0A= "draft-ietf-radext-radius-extensions-01.txt","=20Remote=20Authentication=20= Dial=20In=20User=20Service=20(RADIUS)=20Protocol=20= Extensions",,,,,"mentions=20the=20issue.=20OK"=0A= "draft-ietf-radext-crypto-agility-requirements-06.txt","=20= Crypto-Agility=20Requirements=20for=20Remote=20Dial-In=20User=20Service=20= (RADIUS)","=20RADEXT=20Working=20Group",,,,"Requirements=20document.=20= Deals=20with=20MD5=20appropriately"=0A= "draft-ietf-ospf-security-extension-manual-keying-00.txt","=20Security=20= Extension=20for=20OSPFv2=20when=20using=20Manual=20Key=20Management","=20= OSPF=20Working=20Group",,,,"it=20does=20talks=20about=20MD5=20having=20= security=20issues=20and=20might=20be=20used=20when=20updates=20to=20OSPF=20= is=20developed,=20it=20might=20be=20possible=20and=20worthwhile=20to=20= get=20the=20authors=20to=20add=20strength=20to=20their=20text=20by=20= pointing=20to=20RFC=206151.=20"=0A= "draft-ietf-krb-wg-gss-cb-hash-agility-07.txt","=20Kerberos=20Version=20= 5=20GSS-API=20Channel=20Binding=20Hash=20Agility",,,,,"shuld=20cite=20= RFC6151=20in=20support=20of=20moving=20away=20from=20MD5"=0A= "draft-ietf-kitten-sasl-saml-02.txt","=20A=20SASL=20and=20GSS-API=20= Mechanism=20for=20SAML",,,,,"=20Uses=20MD5=20as=20an=20example=20of=20= available=20server=20authentication=20mechanisms.=20=20Suggestion:=20= Could=20probably=20use=20another=20hash=20function=20as=20an=20example=20= and=20point=20to=20RFC=206151,=20but=20it=20is=20not=20critical.=20=20"=0A= "draft-ietf-karp-threats-reqs-02.txt","=20The=20Threat=20Analysis=20and=20= Requirements=20for=20Cryptographic=20Authentication=20of=20Routing=20= Protocols'=20Transports","=20KARP=20Working=20Group",,,,"Suggestion:=20= The=20conclusions=20drawn=20and=20thus=20recommendations=20would=20= probably=20be=20better=20if=20RFC=206151=20would=20be=20referenced=20and=20= its=20content=20referred."=0A"draft-ietf-karp-crypto-key-table-01.txt","=20= Database=20of=20Long-Lived=20Symmetric=20Cryptographic=20Keys","problem=20= (marshall)",,,,"Suggestion:=20Since=20it=20a=20security=20related=20= draft=20for=20standards=20track=20it=20should=20point=20to=20RFC=206151=20= and=20add=20a=20simple=20statement=20regarding=20the=20state=20of=20MD5=20= (and=20other=20algorithms).=20"=0A= "draft-ietf-httpbis-p3-payload-14.txt","=20HTTP/1.1=20part=203:=20= Message=20Payload=20and=20Content=20Negotiation",,,,,"This=20draft=20= does=20the=20correct=20thing=20and=20no=20further=20attention=20needed.=20= "=0A"draft-ietf-httpbis-p1-messaging-14.txt","=20HTTP/1.1=20part=201:=20= URIs",,,,,"This=20draft=20is=20probably=20not=20the=20correct=20document=20= to=20infer=20a=20change=20of=20hash=20function=20to=20use=20for=20= content=20authentication"=0A"draft-ietf-emu-eap-tunnel-method-00.txt","=20= Flexible=20Authentication=20via=20Secure=20Tunneling=20Extensible=20= Authentication=20Protocol=20(EAP-FAST)=20Version=202","=20EMU=20Working=20= Group",,,,"Needs=20no=20further=20attention.=20Possibly=20getting=20them=20= to=20point=20to=20RFC=206151=20just=20to=20support=20their=20point.=20"=0A= "draft-ietf-emu-chbind-07.txt","=20Channel=20Binding=20Support=20for=20= EAP=20Methods","=20EMU=20Working=20Group",,,,"Possibly=20getting=20them=20= to=20point=20to=20RFC=206151=20just=20to=20add=20clarification.=20"=0A= "draft-ietf-dnsext-dnssec-registry-fixes-08.txt","=20Applicability=20= Statement:=20DNS=20Security=20(DNSSEC)=20DNSKEY=20Algorithm=20IANA=20= Registry","=20DNS=20Extensions=20Working=20Group",,,,"Suggestion:=20= Needs=20no=20further=20attention.=20Possibly=20getting=20them=20to=20= point=20to=20RFC=206151=20just=20to=20add=20clarification."=0A= "draft-ietf-dime-rfc4005bis-04.txt","=20Diameter=20Network=20Access=20= Server=20Application",,,,,"uses=20CHAP-MD5.=20=C2=A0"=0A= "draft-gutmann-cms-hmac-enc-03.txt","=20Using=20MAC-authenticated=20= Encryption=20in=20the=20Cryptographic=20Message=20Syntax=20(CMS)","=20= S/MIME=20Working=20Group",,,,"Mentions=20HMAC-MD5=20as=20an=20example.=20= =20Could=20cite=20RFC6151.=20=20This=20draft=20should=20cite=20= references=20for=20the=20authenticate-then-encrypt=20method.=20=20(I=20= can=20probably=20dig=20that=20up.)"=0A= "draft-gont-tcpm-rfc1948bis-00.txt","=20Defending=20Against=20Sequence=20= Number=20Attacks",,,,,"Mentions=20MD5=20only=20in=20the=20context=20that=20= it=20has=20been=20replaced=20by=20SHA-256.=20=20No=20change=20needed."=0A= "draft-bryan-metalinkhttp-22.txt","=20Metalink/HTTP:=20Mirrors=20and=20= Hashes",,,,,"Only=20a=20passing=20reference;=20MD5=20is=20mentioned=20in=20= the=20document=20history=20section."=0A"draft-bittau-tcp-crypt-00.txt","=20= Cryptographic=20protection=20of=20TCP=20Streams=20= (tcpcrypt)",,,,,"Passing=20reference;=20MD5=20is=20mentioned=20as=20one=20= of=20the=20TCP=20options."=0A"draft-bierman-netmod-system-mgmt-00.txt","=20= YANG=20Data=20Model=20for=20System=20Management",,,,,"Uses=20= crypt-hash-MD5.=20=20It=20is=20not=20clear=20if=20the=20draft=20is=20= talking=20about=20managing=20authentication=20data,=20or=20= authenticating=20management,=20but=20I=20think=20it=20is=20the=20former.=20= Probably=20doesn't=20need=20changes."=0A= "draft-bhz-karp-inter-session-replay-00.txt","=20A=20Generic=20Mechanism=20= to=20solve=20Inter-Session=20Replay=20Attacks=20for=20Routing=20and=20= Signaling=20Protocols",,,,,"Discusses=20MD5=20uses=20in=20some=20common=20= routing=20protocol=20security=20mechanism.=20=20I=20suggest=20that=20= RFC6151=20be=20cited."=0A"draft-bhatia-zhang-karp-bfd-analysis-01.txt","=20= Analysis=20of=20Bidirectional=20Forwarding=20Detection=20(BFD)=20= Security=20According=20to=20KARP=20Design=20Guide",,,,,"Same=20as=20= above;=20should=20cite=20RFC6151."=0A= "draft-bhatia-karp-ospf-ip-layer-protection-03.txt","=20Security=20= Extension=20for=20OSPFv2=20when=20using=20Manual=20Key=20Management","=20= KARP=20Working=20Group",,,,"Similar=20to=20above;=20would=20be=20good=20= to=20cite=20RFC6151."=0A,,,,,,=0A,"=20",,,,,=0A,,,,,,=0A= "draft-twine-ftpmd5-00",,,,,,"This=20draft=20should=20definitely=20point=20= to=20RFC=206151=20and=20include=20some=20comments=20regarding=20= algorithms=20and=20their=20strengths=20and=20weaknesses."=0A= "draft-dbider-sha2-mac-for-ssh-02","SHA-2=20Data=20Integrity=20= Verification=20for=20the=20Secure=20Shell=20(SSH)=20Transport=20Layer=20= Protocol",,,,,"This=20draft=20is=20about=20adding=20HMAC-SHA-2=20= algorithms=20to=20SSH,=20and=20it=20mentions=20MD5=20only=20in=20= passing.=20=20It=20should=20cite=20RFC6151=20to=20support=20its=20claims=20= that=20there=20are=20concerns=20with=20MD5."=0A= "draft-ietf-opsawg-management-stds-00.txt","=20An=20Overview=20of=20the=20= IETF=20Network=20Management=20Standards","=20Informational",,,,"=20Leave=20= as=20is.=20"=0A"draft-ersue-opsawg-management-fw-03.txt","=20An=20= Overview=20of=20the=20IETF=20Network=20Management=20Standards","=20= Informational",,,,"Mentions=20MD5=20in=20passing:=20""=20The=20RADIUS=20= protocol=20uses=20a=20shared=20secret=20along=20with=20the=20MD5=20= hashing=20algorithm=20to=20secure=20passwords.""=20=20Could=20cite=20= RFC6151."=0A,,,,,,=0A,,,,,,=0A,,,,,,=0A,,,,,,=0A"Legend",,,,,,=0A"E=20=3D=20= email=20sent",,,,,,=0A= --Apple-Mail-28-613093399 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-28-613093399-- From mcgrew@cisco.com Wed Jul 27 16:02:00 2011 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 748A821F87C2 for ; Wed, 27 Jul 2011 16:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.916 X-Spam-Level: X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSWpHb5d7OMG for ; Wed, 27 Jul 2011 16:01:59 -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 A956621F87BC for ; Wed, 27 Jul 2011 16:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2182; q=dns/txt; s=iport; t=1311807719; x=1313017319; h=message-id:from:to:content-transfer-encoding: mime-version:subject:date:references; bh=iGAwIIx38+aU2UORlSS2UI7envpNw67x5aXHCNWcoP4=; b=TkCVAXfswDqGOT7M4e+lK4H/KmDqTzo7/4PlckHlXJS/YBAMqCa2C+W+ AU54YcDyfe+LO2YAwfdkzgU3I8EYPS4SQOBDLHti2UiHWhLV7yfmqI7ZE kHBDN81J2WJ1YKSJfae8a+ZRmhGjHmE7Xxhtg+g3FRLEIlA7UpIo01+h7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcHAB2YME6rRDoJ/2dsb2JhbAA0AQEBAQIBAQEBEQEpAjoQDB0DAQI7FBgvAggeJ5gijwR3iHwEozKeVoVhXwSHV4sehQeLew X-IronPort-AV: E=Sophos;i="4.67,279,1309737600"; d="scan'208";a="7170268" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jul 2011 23:01:59 +0000 Received: from [172.16.53.52] ([10.86.254.175]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6RN1vkL022146 for ; Wed, 27 Jul 2011 23:01:58 GMT Message-Id: <8D333B38-1809-4CBE-B71D-836DC4B41608@cisco.com> From: David McGrew To: cfrg@irtf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jul 2011 16:01:57 -0700 References: X-Mailer: Apple Mail (2.936) Subject: [Cfrg] Fwd: [saag] Draft 800-56C is posted for the second public comments 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, 27 Jul 2011 23:02:00 -0000 FYI. A side question: how many people on this mail list are *not* also on the IETF security area advisory group mail list? If the lists have many people in common, then I won't bother forwarding in the future. David Begin forwarded message: > From: "Polk, William T." > Date: July 27, 2011 11:02:49 AM PDT > To: "saag@ietf.org" > Subject: [saag] Draft 800-56C is posted for the second public comments > > A new draft NIST publication is available that may be of interest to > the IETF. This document is related to, and inspired in part by, RFC > 5869 "HMAC-based Extract-and-Expand Key Derivation Function > (HKDF)". Since I failed to forward the announcement of the first > public comment period (sorry folks!) I wanted to be sure people were > aware of the second public comment period. The NIST announcement > follows: > > Second draft of 800-56C: Recommendation for Key Derivation through > Extraction-then-Expansion is posted for public comments. The initial > draft was released in September 2010. This second version > incorporates resolutions to the comments received during the first > comment period. > > This Recommendation specifies techniques for the derivation of > keying material from a shared secret established during a key > establishment scheme defined in NIST Special Publications 800-56A or > 800-56B through an extraction-then-expansion procedure. NIST is in > the process of modifying SP 800-56A and SP 800-56B to include the > extraction-then-expansion key derivation procedure specified in this > draft Recommendation (800-56C). You can find the second draft of > NIST SP 800-56C at http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-56-C > . > > Please submit comments to 800-56Ccomments@nist.gov with "Comments on > SP 800-56C" in the subject line. The comment period closes on August > 11, 2011. > > Your comments would certainly be appreciated! > > Thanks, > > Tim Polk > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag