From exim@www1.ietf.org Mon Feb 9 00:49:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18972 for ; Mon, 9 Feb 2004 00:49:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq4Hm-0006ET-G0 for cfrg-archive@odin.ietf.org; Mon, 09 Feb 2004 00:48:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i195mkAB023951 for cfrg-archive@odin.ietf.org; Mon, 9 Feb 2004 00:48:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq4Hm-0006EE-C9 for cfrg-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 00:48:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18927 for ; Mon, 9 Feb 2004 00:48:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq4Hj-0003AL-00 for cfrg-web-archive@ietf.org; Mon, 09 Feb 2004 00:48:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq4Gl-00034S-00 for cfrg-web-archive@ietf.org; Mon, 09 Feb 2004 00:47:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq4Fp-0002zi-00 for cfrg-web-archive@ietf.org; Mon, 09 Feb 2004 00:46:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq4F8-00060A-Fb; Mon, 09 Feb 2004 00:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq4Ez-0005yn-FP for cfrg@optimus.ietf.org; Mon, 09 Feb 2004 00:45:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18851 for ; Mon, 9 Feb 2004 00:45:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq4Ew-0002vd-00 for cfrg@ietf.org; Mon, 09 Feb 2004 00:45:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq4E3-0002r2-00 for cfrg@ietf.org; Mon, 09 Feb 2004 00:44:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aq4Dd-0002mB-00 for cfrg@ietf.org; Mon, 09 Feb 2004 00:44:29 -0500 Received: from garie.qualcomm.com ([203.30.171.17]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aq4De-0001F3-TJ for cfrg@ietf.org; Mon, 09 Feb 2004 00:44:31 -0500 Received: from grose1.qualcomm.com (pat-ras.qualcomm.com [129.46.54.33]) by garie.qualcomm.com (8.12.8/8.12.1/1.0) with ESMTP id i195hpak025826; Mon, 9 Feb 2004 16:43:54 +1100 Message-Id: <6.0.0.22.2.20040209162103.03b23400@203.30.171.17> X-Sender: ggr2@203.30.171.17 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 09 Feb 2004 16:43:49 +1100 To: cfrg@ietf.org From: Greg Rose Cc: ggr@qualcomm.com, mwp@qualcomm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Cfrg] SOBER-128 draft rfc Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 http://www.ietf.org/internet-drafts/draft-paddon-sober128-01.txt is a draft RFC for the newest member of our SOBER family of stream ciphers: SOBER-128 is a fast software-oriented stream cipher based on simple 32 bit operations. Keys and optional nonces of arbitrary length are supported. Enumeration of keys is thought to be the most efficient attack for key lengths of 128 bits or less. SOBER-128 may be configured to calculate an arbitrary length Message Authentication Code (MAC) as part of the encryption or decryption process. Source code for SOBER-128 is freely available, and use of this source code, or independent implementations, is permitted for any purpose under a fee free license. The design documents and implementations in C and Java are at our website, http://www.qualcomm.com.au . But I'll try to hit the high points: . SOBER-128 is a very small evolution of SOBER-t32, basically tweaks to add efficiency and address the known cryptanalysis results of -t32. No attack better than 2^128 is known for -t32. The family of ciphers has been extensively analysed over a period of 6 years. I can say, with a straight face, that we believe SOBER-128 to be significantly stronger than its design target. . SOBER-128 was designed to "drop in" to IPsec. (Expect an RFC for that soon.) In that mode, various benchmarks show that it significantly outperforms the AES/HMAC-SHA-1 combo by a factor of 3-8 depending on platforms, packet sizes, and so on. Comments are, of course, welcome. Greg. Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Mon Feb 9 19:55:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07337 for ; Mon, 9 Feb 2004 19:55:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMAn-0007tE-Mj for cfrg-archive@odin.ietf.org; Mon, 09 Feb 2004 19:54:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A0sjwm030327 for cfrg-archive@odin.ietf.org; Mon, 9 Feb 2004 19:54:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMAn-0007t3-IK for cfrg-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 19:54:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07267 for ; Mon, 9 Feb 2004 19:54:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqMAl-0004Nx-00 for cfrg-web-archive@ietf.org; Mon, 09 Feb 2004 19:54:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqM9m-0004Ec-00 for cfrg-web-archive@ietf.org; Mon, 09 Feb 2004 19:53:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqM8w-000470-00 for cfrg-web-archive@ietf.org; Mon, 09 Feb 2004 19:52:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqM89-0007Zu-TU; Mon, 09 Feb 2004 19:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqM2n-0007LU-0R for cfrg@optimus.ietf.org; Mon, 09 Feb 2004 19:46:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06708 for ; Mon, 9 Feb 2004 19:46:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqM2l-0003Is-00 for cfrg@ietf.org; Mon, 09 Feb 2004 19:46:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqM1L-0002y0-00 for cfrg@ietf.org; Mon, 09 Feb 2004 19:45:01 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqLzC-0002Yb-00 for cfrg@ietf.org; Mon, 09 Feb 2004 19:42:46 -0500 Received: from garie.qualcomm.com ([203.30.171.17]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqLzB-0003vF-VP for cfrg@ietf.org; Mon, 09 Feb 2004 19:42:46 -0500 Received: from grose1.qualcomm.com ([1.1.1.1]) by garie.qualcomm.com (8.12.8/8.12.1/1.0) with ESMTP id i1A0g0ak031656; Tue, 10 Feb 2004 11:42:02 +1100 Message-Id: <6.0.0.22.2.20040210112515.03b206b0@203.30.171.17> X-Sender: ggr2@203.30.171.17 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 10 Feb 2004 11:41:59 +1100 To: John Viega From: Greg Rose Subject: Re: [Cfrg] SOBER-128 draft rfc Cc: Greg Rose , cfrg@ietf.org, mwp@qualcomm.com, phawkes@qualcomm.com In-Reply-To: <20040209233618.GA27496@zork.org> References: <6.0.0.22.2.20040209162103.03b23400@203.30.171.17> <20040209233618.GA27496@zork.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 06:36 PM 2/9/2004 -0500, John Viega wrote: >Greg, > >In FSE there was a MAC forgery attack that succeeded with very high >probability. Should something with such an attack really be an RFC, >or was the attack actually incorrect? I did see the talk and it >seemed to make sense. Clearly there is a timing problem; I was unable to attend FSE, and was unaware of this attack. (When we have attacks on other people's ciphers, we tell them... I wish others would show us the same courtesy.) (I assume you mean: fse048 Title: A MAC forgery attack on SOBER-128 Authors: Dai Watanabe and Soichi Furuya which I only just found based on your comment. The other paper we were aware of and disagree with the complexity of the attack (and informed the authors), but we haven't seen the published version; that one didn't worry us.) I have no answer at the moment. I'll go find out more and get back to the list. >Also, I was wondering, what are the applications for new stream >ciphers? What I mean by this is that the speed difference between an >authenticated encryption with AES and with something like SOBER-128 >is, in software, only about 2.5, which doesn't make a significant >difference for any application I've ever seen. I believe that efficiency always matters. Assuming that it doesn't, leads to things like bloated Windows. There are two particular cases where efficiency matters, and these are at opposite ends of the spectrum. Encryption from the high end, where the bits are being pushed out at high gigabit rates, and hardware acceleration costs real money; doing more with less translates to real dollars. And at the low end, where a small microprocessor running at a low clock rate doesn't have the cycles to do everything it wants to. I don't disagree with any of the other advantages you cite for block cipher based mechanisms, but I don't think we should stop research either. regards, Greg. > And, there are other >advantages: > >- Provable security based on a much better studied cryptographic >primitive. As a field, we know quite a lot more about making good >block ciphers, but clearly are not nearly as good with stream ciphers, >as shown by the fact that NESSIE accepted no stream ciphers (Though, I >will agree that the best attacks against some of the primitives were >not very worrisome, but they are, individually, also far less studied >than, say, AES). > >- The ability to use cheap off-the-shelf AES components in hardware. > >- Parallelizable modes that exist now can enable high-speed hardware, >and still be interoperable with low-speed operations. > >The speed of block-based symmetric primitives is clearly becoming far >less of an issue even in embedded systems. For example, 3GPP's >authenticated encryption mode is based on a block cipher. My very >first palm pilot had no problems with symmetric crypto (e.g., the SSH >protocol), nearly six years ago. > >I certainly think that designing a good, dedicated stream cipher is an >interesting and worthy challenge, and the SOBER family has done much >to advance these primitives. I'm just trying to figure out the >practical use cases so that I know when to recommend considering them. > >John > >On Mon, Feb 09, 2004 at 04:43:49PM +1100, Greg Rose wrote: > > http://www.ietf.org/internet-drafts/draft-paddon-sober128-01.txt > > > > is a draft RFC for the newest member of our SOBER family of stream ciphers: > > > > SOBER-128 is a fast software-oriented stream cipher based on simple > > 32 bit operations. Keys and optional nonces of arbitrary length are > > supported. Enumeration of keys is thought to be the most efficient > > attack for key lengths of 128 bits or less. SOBER-128 may be > > configured to calculate an arbitrary length Message Authentication > > Code (MAC) as part of the encryption or decryption process. Source > > code for SOBER-128 is freely available, and use of this source code, > > or independent implementations, is permitted for any purpose under a > > fee free license. > > > > The design documents and implementations in C and Java are at our website, > > http://www.qualcomm.com.au . But I'll try to hit the high points: > > > > . SOBER-128 is a very small evolution of SOBER-t32, basically tweaks to > add > > efficiency and address the known cryptanalysis results of -t32. No attack > > better than 2^128 is known for -t32. The family of ciphers has been > > extensively analysed over a period of 6 years. I can say, with a straight > > face, that we believe SOBER-128 to be significantly stronger than its > > design target. > > > > . SOBER-128 was designed to "drop in" to IPsec. (Expect an RFC for that > > soon.) In that mode, various benchmarks show that it significantly > > outperforms the AES/HMAC-SHA-1 combo by a factor of 3-8 depending on > > platforms, packet sizes, and so on. > > > > Comments are, of course, welcome. > > > > Greg. > > > > Greg Rose INTERNET: ggr@qualcomm.com > > Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 > > Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ > > Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C > > > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@ietf.org > > https://www1.ietf.org/mailman/listinfo/cfrg Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Mon Feb 9 19:55:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07340 for ; Mon, 9 Feb 2004 19:55:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMAo-0007tb-5Y for cfrg-archive@odin.ietf.org; Mon, 09 Feb 2004 19:54:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A0skmw030345 for cfrg-archive@odin.ietf.org; Mon, 9 Feb 2004 19:54:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMAo-0007tM-2N for cfrg-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 19:54:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07270 for ; Mon, 9 Feb 2004 19:54:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqMAm-0004O2-00 for cfrg-web-archive@ietf.org; Mon, 09 Feb 2004 19:54:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqM9n-0004Ek-00 for cfrg-web-archive@ietf.org; Mon, 09 Feb 2004 19:53:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqM8w-000471-00 for cfrg-web-archive@ietf.org; Mon, 09 Feb 2004 19:52:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqM8A-0007a2-CC; Mon, 09 Feb 2004 19:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqL4l-0004f4-CL for cfrg@optimus.ietf.org; Mon, 09 Feb 2004 18:44:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01085 for ; Mon, 9 Feb 2004 18:44:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqL4i-0002CB-00 for cfrg@ietf.org; Mon, 09 Feb 2004 18:44:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqL3i-00025w-00 for cfrg@ietf.org; Mon, 09 Feb 2004 18:43:22 -0500 Received: from strongbadia.list.org ([206.131.226.62]) by ietf-mx with esmtp (Exim 4.12) id 1AqL2p-0001xj-00 for cfrg@ietf.org; Mon, 09 Feb 2004 18:42:27 -0500 Received: by strongbadia.list.org (Postfix, from userid 1002) id F3E34130E84; Mon, 9 Feb 2004 18:36:38 -0500 (EST) Date: Mon, 9 Feb 2004 18:36:38 -0500 From: John Viega To: Greg Rose Cc: cfrg@ietf.org, mwp@qualcomm.com Subject: Re: [Cfrg] SOBER-128 draft rfc Message-ID: <20040209233618.GA27496@zork.org> References: <6.0.0.22.2.20040209162103.03b23400@203.30.171.17> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.22.2.20040209162103.03b23400@203.30.171.17> User-Agent: Mutt/1.5.5.1i Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Greg, In FSE there was a MAC forgery attack that succeeded with very high probability. Should something with such an attack really be an RFC, or was the attack actually incorrect? I did see the talk and it seemed to make sense. Also, I was wondering, what are the applications for new stream ciphers? What I mean by this is that the speed difference between an authenticated encryption with AES and with something like SOBER-128 is, in software, only about 2.5, which doesn't make a significant difference for any application I've ever seen. And, there are other advantages: - Provable security based on a much better studied cryptographic primitive. As a field, we know quite a lot more about making good block ciphers, but clearly are not nearly as good with stream ciphers, as shown by the fact that NESSIE accepted no stream ciphers (Though, I will agree that the best attacks against some of the primitives were not very worrisome, but they are, individually, also far less studied than, say, AES). - The ability to use cheap off-the-shelf AES components in hardware. - Parallelizable modes that exist now can enable high-speed hardware, and still be interoperable with low-speed operations. The speed of block-based symmetric primitives is clearly becoming far less of an issue even in embedded systems. For example, 3GPP's authenticated encryption mode is based on a block cipher. My very first palm pilot had no problems with symmetric crypto (e.g., the SSH protocol), nearly six years ago. I certainly think that designing a good, dedicated stream cipher is an interesting and worthy challenge, and the SOBER family has done much to advance these primitives. I'm just trying to figure out the practical use cases so that I know when to recommend considering them. John On Mon, Feb 09, 2004 at 04:43:49PM +1100, Greg Rose wrote: > http://www.ietf.org/internet-drafts/draft-paddon-sober128-01.txt > > is a draft RFC for the newest member of our SOBER family of stream ciphers: > > SOBER-128 is a fast software-oriented stream cipher based on simple > 32 bit operations. Keys and optional nonces of arbitrary length are > supported. Enumeration of keys is thought to be the most efficient > attack for key lengths of 128 bits or less. SOBER-128 may be > configured to calculate an arbitrary length Message Authentication > Code (MAC) as part of the encryption or decryption process. Source > code for SOBER-128 is freely available, and use of this source code, > or independent implementations, is permitted for any purpose under a > fee free license. > > The design documents and implementations in C and Java are at our website, > http://www.qualcomm.com.au . But I'll try to hit the high points: > > . SOBER-128 is a very small evolution of SOBER-t32, basically tweaks to add > efficiency and address the known cryptanalysis results of -t32. No attack > better than 2^128 is known for -t32. The family of ciphers has been > extensively analysed over a period of 6 years. I can say, with a straight > face, that we believe SOBER-128 to be significantly stronger than its > design target. > > . SOBER-128 was designed to "drop in" to IPsec. (Expect an RFC for that > soon.) In that mode, various benchmarks show that it significantly > outperforms the AES/HMAC-SHA-1 combo by a factor of 3-8 depending on > platforms, packet sizes, and so on. > > Comments are, of course, welcome. > > Greg. > > Greg Rose INTERNET: ggr@qualcomm.com > Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 > Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ > Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Tue Feb 10 08:51:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18567 for ; Tue, 10 Feb 2004 08:51:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYI0-0004St-Mt for cfrg-archive@odin.ietf.org; Tue, 10 Feb 2004 08:51:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ADp0Wa017159 for cfrg-archive@odin.ietf.org; Tue, 10 Feb 2004 08:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYI0-0004Sg-In for cfrg-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 08:51:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18561 for ; Tue, 10 Feb 2004 08:50:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqYHz-00022L-00 for cfrg-web-archive@ietf.org; Tue, 10 Feb 2004 08:50:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqYH5-0001wx-00 for cfrg-web-archive@ietf.org; Tue, 10 Feb 2004 08:50:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqYGn-0001rJ-00 for cfrg-web-archive@ietf.org; Tue, 10 Feb 2004 08:49:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYG5-0004Ix-7m; Tue, 10 Feb 2004 08:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSWg-0003TF-6o for cfrg@optimus.ietf.org; Tue, 10 Feb 2004 02:41:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04143 for ; Tue, 10 Feb 2004 02:41:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqSWc-0003tn-00 for cfrg@ietf.org; Tue, 10 Feb 2004 02:41:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqSVn-0003ol-00 for cfrg@ietf.org; Tue, 10 Feb 2004 02:40:52 -0500 Received: from mail.securesoftware.com ([206.131.226.4]) by ietf-mx with esmtp (Exim 4.12) id 1AqSVK-0003jU-00 for cfrg@ietf.org; Tue, 10 Feb 2004 02:40:22 -0500 Received: from [192.168.0.102] (unknown [12.109.142.30]) by mail.securesoftware.com (Postfix) with ESMTP id 82BF0249; Tue, 10 Feb 2004 02:38:09 -0500 (EST) In-Reply-To: <6.0.0.22.2.20040210112515.03b206b0@203.30.171.17> References: <6.0.0.22.2.20040209162103.03b23400@203.30.171.17> <20040209233618.GA27496@zork.org> <6.0.0.22.2.20040210112515.03b206b0@203.30.171.17> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4784C58B-5B9C-11D8-A231-000A959CFBBA@securesoftware.com> Content-Transfer-Encoding: 7bit Cc: phawkes@qualcomm.com, cfrg@ietf.org, mwp@qualcomm.com From: John Viega Subject: Re: [Cfrg] SOBER-128 draft rfc Date: Tue, 10 Feb 2004 02:39:38 -0500 To: Greg Rose X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Feb 9, 2004, at 7:41 PM, Greg Rose wrote: > At 06:36 PM 2/9/2004 -0500, John Viega wrote: >> Greg, >> >> In FSE there was a MAC forgery attack that succeeded with very high >> probability. Should something with such an attack really be an RFC, >> or was the attack actually incorrect? I did see the talk and it >> seemed to make sense. > > Clearly there is a timing problem; I was unable to attend FSE, and was > unaware of this attack. (When we have attacks on other people's > ciphers, we tell them... I wish others would show us the same > courtesy.) Indeed, it's surprising they did not tell you! > > (I assume you mean: > fse048 > Title: A MAC forgery attack on SOBER-128 > Authors: Dai Watanabe and Soichi Furuya > which I only just found based on your comment. The other paper we were > aware of and disagree with the complexity of the attack (and informed > the authors), but we haven't seen the published version; that one > didn't worry us.) Yes, that's the paper. The other paper you're talking about was also published at FSE, correct? That talk didn't leave me believing they had a significant attack, either. In fact, I think that the authors revised their complexity bounds upward at the conference, probably due to your feedback. > > I have no answer at the moment. I'll go find out more and get back to > the list. > >> Also, I was wondering, what are the applications for new stream >> ciphers? What I mean by this is that the speed difference between an >> authenticated encryption with AES and with something like SOBER-128 >> is, in software, only about 2.5, which doesn't make a significant >> difference for any application I've ever seen. > > I believe that efficiency always matters. Assuming that it doesn't, > leads to things like bloated Windows. > > There are two particular cases where efficiency matters, and these are > at opposite ends of the spectrum. Encryption from the high end, where > the bits are being pushed out at high gigabit rates, and hardware > acceleration costs real money; doing more with less translates to real > dollars. And at the low end, where a small microprocessor running at a > low clock rate doesn't have the cycles to do everything it wants to. Thanks for the perspective. I certainly agree that efficiency matters quite a bit. There's a good reason why RC4 was so popular back when 3DES was the block cipher of choice, and it has even remained somewhat popular in the face of some fairly serious attacks. The gap is starting to get quite small, though! > > I don't disagree with any of the other advantages you cite for block > cipher based mechanisms, but I don't think we should stop research > either. Nor do I, especially because I think that block cipher design and stream cipher design can share ideas quite well, particularly in large s-box design. One of the most impressive talks at FSE was Shamir's talk on t-functions, which have definite applications in this area. Thanks, John > > regards, > Greg. > >> And, there are other >> advantages: >> >> - Provable security based on a much better studied cryptographic >> primitive. As a field, we know quite a lot more about making good >> block ciphers, but clearly are not nearly as good with stream ciphers, >> as shown by the fact that NESSIE accepted no stream ciphers (Though, I >> will agree that the best attacks against some of the primitives were >> not very worrisome, but they are, individually, also far less studied >> than, say, AES). >> >> - The ability to use cheap off-the-shelf AES components in hardware. >> >> - Parallelizable modes that exist now can enable high-speed hardware, >> and still be interoperable with low-speed operations. >> >> The speed of block-based symmetric primitives is clearly becoming far >> less of an issue even in embedded systems. For example, 3GPP's >> authenticated encryption mode is based on a block cipher. My very >> first palm pilot had no problems with symmetric crypto (e.g., the SSH >> protocol), nearly six years ago. >> >> I certainly think that designing a good, dedicated stream cipher is an >> interesting and worthy challenge, and the SOBER family has done much >> to advance these primitives. I'm just trying to figure out the >> practical use cases so that I know when to recommend considering them. >> >> John >> >> On Mon, Feb 09, 2004 at 04:43:49PM +1100, Greg Rose wrote: >> > http://www.ietf.org/internet-drafts/draft-paddon-sober128-01.txt >> > >> > is a draft RFC for the newest member of our SOBER family of stream >> ciphers: >> > >> > SOBER-128 is a fast software-oriented stream cipher based on >> simple >> > 32 bit operations. Keys and optional nonces of arbitrary length >> are >> > supported. Enumeration of keys is thought to be the most >> efficient >> > attack for key lengths of 128 bits or less. SOBER-128 may be >> > configured to calculate an arbitrary length Message >> Authentication >> > Code (MAC) as part of the encryption or decryption process. >> Source >> > code for SOBER-128 is freely available, and use of this source >> code, >> > or independent implementations, is permitted for any purpose >> under a >> > fee free license. >> > >> > The design documents and implementations in C and Java are at our >> website, >> > http://www.qualcomm.com.au . But I'll try to hit the high points: >> > >> > . SOBER-128 is a very small evolution of SOBER-t32, basically >> tweaks to add >> > efficiency and address the known cryptanalysis results of -t32. No >> attack >> > better than 2^128 is known for -t32. The family of ciphers has been >> > extensively analysed over a period of 6 years. I can say, with a >> straight >> > face, that we believe SOBER-128 to be significantly stronger than >> its >> > design target. >> > >> > . SOBER-128 was designed to "drop in" to IPsec. (Expect an RFC for >> that >> > soon.) In that mode, various benchmarks show that it significantly >> > outperforms the AES/HMAC-SHA-1 combo by a factor of 3-8 depending on >> > platforms, packet sizes, and so on. >> > >> > Comments are, of course, welcome. >> > >> > Greg. >> > >> > Greg Rose INTERNET: >> ggr@qualcomm.com >> > Qualcomm Australia VOICE: +61-2-9817 4188 FAX: >> +61-2-9817 5199 >> > Level 3, 230 Victoria Road, >> http://people.qualcomm.com/ggr/ >> > Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F >> 1081 A37C >> > >> > >> > _______________________________________________ >> > Cfrg mailing list >> > Cfrg@ietf.org >> > https://www1.ietf.org/mailman/listinfo/cfrg > > > Greg Rose INTERNET: > ggr@qualcomm.com > Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 > 5199 > Level 3, 230 Victoria Road, > http://people.qualcomm.com/ggr/ > Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 > A37C > > ---- John Viega CTO, Secure Software, Inc. 703-814-4402 Secure Programming Cookbook: http://secureprogramming.com Building Secure Software: http://buildingsecuresoftware.com _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Fri Feb 13 20:25:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18447 for ; Fri, 13 Feb 2004 20:25:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AroXw-0005LC-36 for cfrg-archive@odin.ietf.org; Fri, 13 Feb 2004 20:24:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1E1OeGN020524 for cfrg-archive@odin.ietf.org; Fri, 13 Feb 2004 20:24:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AroXv-0005Kp-Ti for cfrg-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 20:24:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18429 for ; Fri, 13 Feb 2004 20:24:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AroXt-0000up-00 for cfrg-web-archive@ietf.org; Fri, 13 Feb 2004 20:24:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AroWx-0000pE-00 for cfrg-web-archive@ietf.org; Fri, 13 Feb 2004 20:23:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AroWA-0000k9-00 for cfrg-web-archive@ietf.org; Fri, 13 Feb 2004 20:22:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AroVN-0004tW-3Y; Fri, 13 Feb 2004 20:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AroUh-0004sk-Ag for cfrg@optimus.ietf.org; Fri, 13 Feb 2004 20:21:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18311 for ; Fri, 13 Feb 2004 20:21:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AroUf-0000da-00 for cfrg@ietf.org; Fri, 13 Feb 2004 20:21:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AroTh-0000aI-00 for cfrg@ietf.org; Fri, 13 Feb 2004 20:20:19 -0500 Received: from mailgw1.technion.ac.il ([132.68.238.34]) by ietf-mx with esmtp (Exim 4.12) id 1AroT8-0000XZ-00 for cfrg@ietf.org; Fri, 13 Feb 2004 20:19:42 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw1.technion.ac.il (Postfix) with ESMTP id EFBF6FFC19 for ; Sat, 14 Feb 2004 03:19:35 +0200 (IST) Received: from mailgw1.technion.ac.il ([127.0.0.1]) by localhost (mailgw1.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02788-01-84 for ; Sat, 14 Feb 2004 03:19:35 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw1.technion.ac.il (Postfix) with ESMTP id F27C5FFADD for ; Sat, 14 Feb 2004 03:19:34 +0200 (IST) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.2+Sun/8.12.2) with ESMTP id i1E1L3LF013458; Sat, 14 Feb 2004 03:21:03 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.2+Sun/8.12.2/Submit) with ESMTP id i1E1L0Sj013455; Sat, 14 Feb 2004 03:21:00 +0200 (IST) Date: Sat, 14 Feb 2004 03:21:00 +0200 (IST) From: Hugo Krawczyk To: "Theodore Ts'o" Cc: IPsec WG , , , Ran Canetti In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at technion.ac.il Subject: [Cfrg] Re: Changing the key deriveration Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This msg is being sent to both ipsec and cfrg (apologies for all those -- like me -- that will get this by duplicate) Some background (for the cfrg audience): In a msg from earlier today (appended below) to the ipsec WG and cfrg chairs (David and Ran), Ted Tso (IPsec WG chair) proposed to bring up before the cfrg forum a crypto design issue in ikev2 that was raised over the ipsec list. I recommend that you read Ted's note. David (McGrew) answered that I should send this note to cfrg with an explanation of the issues. So this is what I am doing. "Executive summary:" ikev2 currently specifies the use of two different algorithms (or "transforms") with the same key. The IPsec chairs ask the cfrg to provide expert opinion on the need to change this specification (as I propose below). Now, a page long expansion of this summary for those who want more details. But before, let me say that I am really glad to see that this issue is being brought to the attention of the cfrg. I hope this is the first of an eventually long tradition of using this forum for validating (or de-validating) cryptographic designs needed/proposed/used by other WGs in the ietf. Specifically, Ted refers to a point I raised, in a msg to the ipsec list from Jan 13th, regarding a specification issue in ikev2. That msg is appended at the end of Ted's note (below). I consider the problem a no-brainer but the fact that it was not immediately accepted as an obvious and easy fix requires some explanation. Here is a succint statement of the problem. The current IKEv2 draft (ready for last call draft-ietf-ipsec-ikev2-12.txt) specifies the use of two DIFFERENT transforms, prf and integrity-algorithm, but also specifies keying them with the SAME key! The prf is used for key derivation as well as for the "mac" that the SIGMA design (SIGn-and-MAc) requires and for an additional mac in ikev2's password-based (or EAP-based) protocol. The second transform, the integrity-algorithm, is used for integrity purposes and is always computed on top of encrypted data (ciphertext); its functionality is to provide authenticated encryption (and CCA security). The obvious fix to this problem is to derive different keys for the different algorithms. Fortunately, this is easy in ikev2 which has a very modular key derivation procedure. All is needed is to derive two more keys (in addition to the 5 derived now) which will be used to key the prf (two keys to be consistent with "uni-directionality" of other keys in ikev2). This frees the already specified "authentication keys" (SK_ai and SK_ar) for exclusive use by the integrity algorithm. I am sure that I do not need to explain to the cfrg-fans the dangers of the (fundamentally wrong) practice of using the same key for two different algorithms. Nor do I think that the ipsec audience will disagree with that either. So the only question is whether there is any real cost associated with the proposed change. In this case, however, there is zero cost. No real specification or implementation complexity. No performance issue at all. No delay in advancing the document (a two-minute change to the draft). And no damage to implementations of ikev2 running in the marketplace since there are none (certainly not "standard-compliant" ones as this standard is not finalized). Finally, other solutions (such as unifying the prf and mac into a single transform) have more drawbacks than the trivial solutions of extracting two more keys in the key derivation process (currently there are 5 keys derived by this process). I do buy, however, Ted's argument that making last minute changes, especially to the cryptography is dangerous. This is why I welcome this request for advise from the cfrg. For those that follow the ipsec discussions there is enough material in that list about the issue. And for those that do not follow ipsec, then the problem does not require more description than what I wrote above (and further described in the appended message). In any case, just to make the point clear let me re-re-iterate the issue with some more detail: (1) The "integrity algorithm" and "prf" are different transforms in ikev2 (see section 3.3 of ikev2), and as such they are negotiated separately and therefore may be set to different algorithms. (2) In two applications of the prf function in ikev2 (sections 2.14 and 2.16) the prf function is keyed with a key (called SK_a) that is defined as a key to the integrity algorithm, not to the prf algorithm. (3) I propose that in addition to the 5 keys currently derived by the protocol (see sec 2.14), namely SK_d,SK_ai,SK_ar,SK_ei,SK_er, two more keys will be derived (called SK_pi,SK_pr) that will be used exclusively to key the prf in the above two applications. Let me also add: not only is the use of different algorithms with the same key an obvious cryptographic flaw, but also raises an operational issue since the keys required by the integrity and prf algorithms may have different size. FOR those who care: If all you have to say is that the need for this change is OBVIOUS, it may still be worth saying it (over the list). Hugo On Fri, 13 Feb 2004, Theodore Ts'o wrote: > > In a recent message, Steve Kent made the following statement: > > >When I last spoke with Russ, he indicated that he was prepared to > >tolerate another delay on the IKE v2 document to incorporate the > >change that Hugo suggested, to incorporate bits from an key-based EAP > >method into the PRF for the keys used for encryption & integrity. > > This presumably is referring to Hugo's proposal of January 13th, which > I've included below.On a recent concall of the IPSEC management team, > we discussed on how to handle this, given that (a) there has been no > response or discussion to Hugo's proposal on the mailing list to date, > and (b) a number of us get hives with the thought of making changes to > something as critical as IKEv2's cryptographic core at the last minute > without some adequate and thoughtful review. > > So we propose the following path forward.First, that we ask the Hugo > to clarify his objection.It appears to be mainly a certificational > weakness in that it may make it harder to prove correctness at least > when using normal crypto algorithms.Is this a fair characterization, > or is there a fundamental problem in normal usage? > > Secondly, we'd like to ask the Crypto Forum Research Group in the IRTF, > whose charter it is to provide a resource to IETF working group to > review uses of cryptographic mechanisms if they might be willing to give > us review of the current key agreement mechanisms found in sections > 2.14, 2.15, and 2.16 of draft-ietf-ipsec-ikev2-12.txt as well as the > proposed change by Hugo.Ran and David: Is this a good use of the CFRG, > and would you be willing to ask them to engage in this review? > > Based on the answers from Hugo and the CFRG, the working group will > hopefully have sufficient information in order to quickly come to > consensus about whether we need to make any changes to ikev2-12. > > Does this seem a reasonable way forward?I don't want to unduly prolong > an already very long process, but it seems to us that it is better to > put examine this issue and put it to rest now, instead of waiting until > Russ finishes reviewing the document (it is in his queue) and starts > IETF last call. > > - Ted > > ------------------ > > Date: Tue, 13 Jan 2004 22:10:50 +0200 (IST) > From: Hugo Krawczyk > Subject: Keing the prf > To: Theodore Ts'o > cc: Russ Housley , byfraser@cisco.com, > Charlie Kaufman , > IPsec WG > > There is one issue that was subject of discussion in the last weeks and I > believe requires a better resolution. I refer to the problem that ikev2 > (including -12) defines two uses of the prf function (in sections 2.15 and > 2.16)where the prf is keyed with SK_a. This is problematic since SK_a is > defined as a key to the "integrity algorithm" which may be different than > the prf. Indeed the integrity algorithm and prf have different transform > types (#3 and #2) respectively, and then are negotiated independetly (in > particular they may usedifferent algorihms). > > Why is this a problem? > > First, because the two transforms may require keys of different lengths, > in particular SK_a may be too short to key the prf. > > Second, it is a wrong cryptographic practice to use the same key with two > different algorithms. This may or may not translate into actual attacks, > but it certainly spoils the otherwise sound design of the protocol. > It will also invite "attacks" from future formal analysts (beyond the > operational issues referred to in the first item). > > I believe that the problem is best solved by deriving an additional pair > of keys from SKEYSEED (call them SK_pi and SK_pr) for keying the prf in the > above two cases. It is certainly easy to specify and to implement > (and easier than to justify why this wasn't done). > > Specifically add the pair SK_pi, SK_pr to the key derivation formula in > 2.14. Change prf(SK_ar,IDr') to prf(SK_pr,IDr') and prf(SK_ai,IDr') to > prf(SK_pi,IDr') in section 2.15. Change "SK_ai and SK_ar" in the next to > last paragraph of section 2.16 with "SK_pi and SK_pr" > > I suggest that this be solved before the official last call (otherwise you > can see this as a comment provided in the last call phase). > > Hugo > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Fri Feb 13 21:39:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21314 for ; Fri, 13 Feb 2004 21:39:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arphd-0003N6-OD for cfrg-archive@odin.ietf.org; Fri, 13 Feb 2004 21:38:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1E2cjLR012954 for cfrg-archive@odin.ietf.org; Fri, 13 Feb 2004 21:38:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arphd-0003Mr-K6 for cfrg-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 21:38:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21302 for ; Fri, 13 Feb 2004 21:38:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arpha-0006QW-00 for cfrg-web-archive@ietf.org; Fri, 13 Feb 2004 21:38:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arpgj-0006Kl-00 for cfrg-web-archive@ietf.org; Fri, 13 Feb 2004 21:37:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arpg5-0006FP-00 for cfrg-web-archive@ietf.org; Fri, 13 Feb 2004 21:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arpez-0002uP-3w; Fri, 13 Feb 2004 21:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArpeN-0002sQ-0K for cfrg@optimus.ietf.org; Fri, 13 Feb 2004 21:35:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21194 for ; Fri, 13 Feb 2004 21:35:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArpeK-0006AP-00 for cfrg@ietf.org; Fri, 13 Feb 2004 21:35:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArpdN-00067I-00 for cfrg@ietf.org; Fri, 13 Feb 2004 21:34:23 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1Arpca-00064R-00 for cfrg@ietf.org; Fri, 13 Feb 2004 21:33:32 -0500 Received: from platinum.qualcomm.com (platinum.qualcomm.com [129.46.51.243]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1E2XNnp002013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2004 18:33:24 -0800 (PST) Received: from grose1.qualcomm.com (vpn-10-50-16-75.qualcomm.com [10.50.16.75]) by platinum.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id i1E2XK5f008734; Fri, 13 Feb 2004 18:33:20 -0800 (PST) Message-Id: <6.0.0.22.2.20040214131159.03b13d00@203.30.171.17> X-Sender: ggr2@203.30.171.17 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 14 Feb 2004 13:32:23 +1100 To: Hugo Krawczyk From: Greg Rose Subject: Re: [Cfrg] Re: Changing the key deriveration Cc: "Theodore Ts'o" , IPsec WG , , , Ran Canetti In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 FWIW, I strongly agree that the change should be made. Three reasons: In 3GPP2 (CDMA2000 mobile phones) we have adopted as a working principal that no key should be used in two ways. This has been a rule of thumb for a long time now. It is just good practise. That the primitives might accept keys of different lengths should also instantly raise flags. Suppose they are of (different) lengths A and B, where wlog we assume A>B. Then either A's key must be padded from B's, in which case it has less entropy than A would imply, or B's must be truncated from A's. But this means that A's key can be attacked (classic divide-and-conquer) by brute-forcing B's, then brute forcing (the rest of) A's. So instead of having strength O(2^A), it now only has strength O(2^(max(B, A-B)). In other words, in both cases, you've reduced the strength of both primitives to that of the weaker. Thirdly, any provability of security of the overall system almost certainly includes an assumption of independence of the cryptographic transforms. If they have the same keys, such an assumption might still be true in the real world, but a priori you just can't rely on it. Hope that helps... Greg. At 03:21 AM 2/14/2004 +0200, Hugo Krawczyk wrote: >This msg is being sent to both ipsec and cfrg (apologies for all those -- >like me -- that will get this by duplicate) > >Some background (for the cfrg audience): In a msg from earlier today >(appended below) to the ipsec WG and cfrg chairs (David and Ran), >Ted Tso (IPsec WG chair) proposed to bring up before the cfrg forum a >crypto design issue in ikev2 that was raised over the ipsec list. >I recommend that you read Ted's note. David (McGrew) answered that I >should send this note to cfrg with an explanation of the issues. >So this is what I am doing. > >"Executive summary:" ikev2 currently specifies the use of two different >algorithms (or "transforms") with the same key. The IPsec chairs ask the >cfrg to provide expert opinion on the need to change this specification >(as I propose below). > >Now, a page long expansion of this summary for those who want more >details. > >But before, let me say that I am really glad to see that this issue is >being brought to the attention of the cfrg. I hope this is the first of an >eventually long tradition of using this forum for validating (or >de-validating) cryptographic designs needed/proposed/used by other WGs in >the ietf. > >Specifically, Ted refers to a point I raised, in a msg to the ipsec list >from Jan 13th, regarding a specification issue in ikev2. That msg is >appended at the end of Ted's note (below). I consider the problem a >no-brainer but the fact that it was not immediately accepted as an obvious >and easy fix requires some explanation. Here is a succint statement of the >problem. > >The current IKEv2 draft (ready for last call >draft-ietf-ipsec-ikev2-12.txt) specifies the use of two DIFFERENT >transforms, prf and integrity-algorithm, but also specifies >keying them with the SAME key! >The prf is used for key derivation as well as for the "mac" that the SIGMA >design (SIGn-and-MAc) requires and for an additional mac in ikev2's >password-based (or EAP-based) protocol. >The second transform, the integrity-algorithm, is used for integrity >purposes and is always computed on top of encrypted data (ciphertext); its >functionality is to provide authenticated encryption (and CCA security). > >The obvious fix to this problem is to derive different keys for the >different algorithms. Fortunately, this is easy in ikev2 which has a very >modular key derivation procedure. All is needed is to derive two more keys >(in addition to the 5 derived now) which will be used to key the prf (two >keys to be consistent with "uni-directionality" of other keys in ikev2). >This frees the already specified "authentication keys" (SK_ai and SK_ar) >for exclusive use by the integrity algorithm. > >I am sure that I do not need to explain to the cfrg-fans the dangers of >the (fundamentally wrong) practice of using the same key for two different >algorithms. Nor do I think that the ipsec audience will disagree with that >either. So the only question is whether there is any real cost associated >with the proposed change. In this case, however, there is zero cost. No >real specification or implementation complexity. No performance issue at >all. No delay in advancing the document (a two-minute change to the >draft). And no damage to implementations of ikev2 running in the >marketplace since there are none (certainly not "standard-compliant" ones >as this standard is not finalized). Finally, other solutions (such as >unifying the prf and mac into a single transform) have more drawbacks than >the trivial solutions of extracting two more keys in the key derivation >process (currently there are 5 keys derived by this process). > >I do buy, however, Ted's argument that making last minute changes, >especially to the cryptography is dangerous. This is why I welcome this >request for advise from the cfrg. For those that follow the ipsec >discussions there is enough material in that list about the issue. >And for those that do not follow ipsec, then the problem does not require >more description than what I wrote above (and further described in the >appended message). > >In any case, just to make the point clear let me re-re-iterate the issue >with some more detail: > >(1) The "integrity algorithm" and "prf" are different transforms in ikev2 >(see section 3.3 of ikev2), and as such they are negotiated separately and >therefore may be set to different algorithms. > >(2) In two applications of the prf function in ikev2 (sections 2.14 and >2.16) the prf function is keyed with a key (called SK_a) that is defined >as a key to the integrity algorithm, not to the prf algorithm. > >(3) I propose that in addition to the 5 keys currently derived by the >protocol (see sec 2.14), namely SK_d,SK_ai,SK_ar,SK_ei,SK_er, two more keys >will be derived (called SK_pi,SK_pr) that will be used exclusively to key >the prf in the above two applications. > >Let me also add: not only is the use of different algorithms with the same >key an obvious cryptographic flaw, but also raises an operational issue >since the keys required by the integrity and prf algorithms may have >different size. > >FOR those who care: If all you have to say is that the need for this >change is OBVIOUS, it may still be worth saying it (over the list). > >Hugo > >On Fri, 13 Feb 2004, Theodore Ts'o wrote: > > > > > In a recent message, Steve Kent made the following statement: > > > > >When I last spoke with Russ, he indicated that he was prepared to > > >tolerate another delay on the IKE v2 document to incorporate the > > >change that Hugo suggested, to incorporate bits from an key-based EAP > > >method into the PRF for the keys used for encryption & integrity. > > > > This presumably is referring to Hugo's proposal of January 13th, which > > I've included below.On a recent concall of the IPSEC management team, > > we discussed on how to handle this, given that (a) there has been no > > response or discussion to Hugo's proposal on the mailing list to date, > > and (b) a number of us get hives with the thought of making changes to > > something as critical as IKEv2's cryptographic core at the last minute > > without some adequate and thoughtful review. > > > > So we propose the following path forward.First, that we ask the Hugo > > to clarify his objection.It appears to be mainly a certificational > > weakness in that it may make it harder to prove correctness at least > > when using normal crypto algorithms.Is this a fair characterization, > > or is there a fundamental problem in normal usage? > > > > Secondly, we'd like to ask the Crypto Forum Research Group in the IRTF, > > whose charter it is to provide a resource to IETF working group to > > review uses of cryptographic mechanisms if they might be willing to give > > us review of the current key agreement mechanisms found in sections > > 2.14, 2.15, and 2.16 of draft-ietf-ipsec-ikev2-12.txt as well as the > > proposed change by Hugo.Ran and David: Is this a good use of the CFRG, > > and would you be willing to ask them to engage in this review? > > > > Based on the answers from Hugo and the CFRG, the working group will > > hopefully have sufficient information in order to quickly come to > > consensus about whether we need to make any changes to ikev2-12. > > > > Does this seem a reasonable way forward?I don't want to unduly prolong > > an already very long process, but it seems to us that it is better to > > put examine this issue and put it to rest now, instead of waiting until > > Russ finishes reviewing the document (it is in his queue) and starts > > IETF last call. > > > > - Ted > > > > ------------------ > > > > Date: Tue, 13 Jan 2004 22:10:50 +0200 (IST) > > From: Hugo Krawczyk > > Subject: Keing the prf > > To: Theodore Ts'o > > cc: Russ Housley , byfraser@cisco.com, > > Charlie Kaufman , > > IPsec WG > > > > There is one issue that was subject of discussion in the last weeks and I > > believe requires a better resolution. I refer to the problem that ikev2 > > (including -12) defines two uses of the prf function (in sections 2.15 and > > 2.16)where the prf is keyed with SK_a. This is problematic since SK_a is > > defined as a key to the "integrity algorithm" which may be different than > > the prf. Indeed the integrity algorithm and prf have different transform > > types (#3 and #2) respectively, and then are negotiated independetly (in > > particular they may usedifferent algorihms). > > > > Why is this a problem? > > > > First, because the two transforms may require keys of different lengths, > > in particular SK_a may be too short to key the prf. > > > > Second, it is a wrong cryptographic practice to use the same key with two > > different algorithms. This may or may not translate into actual attacks, > > but it certainly spoils the otherwise sound design of the protocol. > > It will also invite "attacks" from future formal analysts (beyond the > > operational issues referred to in the first item). > > > > I believe that the problem is best solved by deriving an additional pair > > of keys from SKEYSEED (call them SK_pi and SK_pr) for keying the prf in the > > above two cases. It is certainly easy to specify and to implement > > (and easier than to justify why this wasn't done). > > > > Specifically add the pair SK_pi, SK_pr to the key derivation formula in > > 2.14. Change prf(SK_ar,IDr') to prf(SK_pr,IDr') and prf(SK_ai,IDr') to > > prf(SK_pi,IDr') in section 2.15. Change "SK_ai and SK_ar" in the next to > > last paragraph of section 2.16 with "SK_pi and SK_pr" > > > > I suggest that this be solved before the official last call (otherwise you > > can see this as a comment provided in the last call phase). > > > > Hugo > > > > > > >_______________________________________________ >Cfrg mailing list >Cfrg@ietf.org >https://www1.ietf.org/mailman/listinfo/cfrg Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Mon Feb 16 15:30:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18272 for ; Mon, 16 Feb 2004 15:30:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspMy-0000cZ-Bf for cfrg-archive@odin.ietf.org; Mon, 16 Feb 2004 15:29:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKTWOD002381 for cfrg-archive@odin.ietf.org; Mon, 16 Feb 2004 15:29:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspMy-0000cK-71 for cfrg-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 15:29:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18233 for ; Mon, 16 Feb 2004 15:29:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspMw-0001SI-00 for cfrg-web-archive@ietf.org; Mon, 16 Feb 2004 15:29:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspM4-0001OV-00 for cfrg-web-archive@ietf.org; Mon, 16 Feb 2004 15:28:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AspLG-0001Kx-00 for cfrg-web-archive@ietf.org; Mon, 16 Feb 2004 15:27:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspKX-0000IN-3B; Mon, 16 Feb 2004 15:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspK2-0000B6-Lt for cfrg@optimus.ietf.org; Mon, 16 Feb 2004 15:26:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18086 for ; Mon, 16 Feb 2004 15:26:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspK1-0001Fp-00 for cfrg@ietf.org; Mon, 16 Feb 2004 15:26:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspJ5-0001DR-00 for cfrg@ietf.org; Mon, 16 Feb 2004 15:25:32 -0500 Received: from mail.esmartstart.com ([66.119.143.50] helo=mail.radioburst.com) by ietf-mx with esmtp (Exim 4.12) id 1AspIw-0001Ah-00 for cfrg@ietf.org; Mon, 16 Feb 2004 15:25:22 -0500 Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i1GKOFHV023792; Mon, 16 Feb 2004 13:24:16 -0700 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i1GKIWtt015039; Mon, 16 Feb 2004 13:18:32 -0700 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i1GKIU97015035; Mon, 16 Feb 2004 13:18:30 -0700 Date: Mon, 16 Feb 2004 13:18:30 -0700 Message-Id: <200402162018.i1GKIU97015035@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: hugo@ee.technion.ac.il Cc: cfrg@ietf.org, ipsec@lists.tislabs.com In-reply-to: Yourmessage Subject: Re: [Cfrg] Re: Changing the key deriveration X-esmartscan-MailScanner: Found to be clean Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Sat, 14 Feb 2004 at 03:21:00 +0200 (IST) Hugo Krawczyk commented: > In this case, however, there is zero cost. No > real specification or implementation complexity. No performance issue at > all. No delay in advancing the document (a two-minute change to the > draft). I've spent more than 15 minutes trying to find out exactly where the objectionable material resides. Previous messages have referred to sections 2.14, 2.15, and 2.16. In draft-ietf-ipsec-ikev2-12.txt, the only case of the cross-algorithm keying seems to be in section 2.15, "Authentication of the IKE_SA", first paragraph. In defense of the mechanism, we see that the value never appears on the wire. It's unlikely to create any problems. Against it, we see that (as Greg Rose pointed out), the key was created for one algorithm and might not have enough entropy to be used safely for another. And, as Hugo points out, it is needlessly unclean. In fact, wouldn't it be better to use SK_d for the purpose of generating the not-on-the-wire authenticating value? This would avoid having to generate two additional keys --- given that the additional keys would be generated with the prf and SK_d anyway, the security analysis seems a toss-up. I don't see any misuse of keys in section 2.16, "Extended Authentication Protocol Methods", though it might be implicit in a formula and I'm just not seeing it. Hilarie _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Tue Feb 17 15:01:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00361 for ; Tue, 17 Feb 2004 15:01:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBOU-0008Sf-ME for cfrg-archive@odin.ietf.org; Tue, 17 Feb 2004 15:00:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HK0Y8L032511 for cfrg-archive@odin.ietf.org; Tue, 17 Feb 2004 15:00:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBOU-0008SH-98 for cfrg-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 15:00:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00324 for ; Tue, 17 Feb 2004 15:00:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBOR-0007A3-00 for cfrg-web-archive@ietf.org; Tue, 17 Feb 2004 15:00:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBNS-000742-00 for cfrg-web-archive@ietf.org; Tue, 17 Feb 2004 14:59:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtBMk-0006zg-00 for cfrg-web-archive@ietf.org; Tue, 17 Feb 2004 14:58:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBM1-0006pa-NV; Tue, 17 Feb 2004 14:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtBLO-0006lr-Nq for cfrg@optimus.ietf.org; Tue, 17 Feb 2004 14:57:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00196 for ; Tue, 17 Feb 2004 14:57:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtBLL-0006tM-00 for cfrg@ietf.org; Tue, 17 Feb 2004 14:57:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtBKQ-0006qc-00 for cfrg@ietf.org; Tue, 17 Feb 2004 14:56:22 -0500 Received: from mailgw3.technion.ac.il ([132.68.238.35]) by ietf-mx with esmtp (Exim 4.12) id 1AtBJx-0006nY-00 for cfrg@ietf.org; Tue, 17 Feb 2004 14:55:53 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw3.technion.ac.il (Postfix) with ESMTP id 22F881677FB for ; Tue, 17 Feb 2004 21:55:46 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw3.technion.ac.il ([127.0.0.1]) by localhost (mailgw3.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18569-01-72 for ; Tue, 17 Feb 2004 21:55:45 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw3.technion.ac.il (Postfix) with ESMTP id F259E16776B for ; Tue, 17 Feb 2004 21:55:44 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.2+Sun/8.12.2) with ESMTP id i1HJvELF007989; Tue, 17 Feb 2004 21:57:14 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.2+Sun/8.12.2/Submit) with ESMTP id i1HJvDm5007986; Tue, 17 Feb 2004 21:57:13 +0200 (IST) Date: Tue, 17 Feb 2004 21:57:13 +0200 (IST) From: Hugo Krawczyk To: "The Purple Streak, Hilarie Orman" Cc: cfrg@ietf.org, Subject: Re: [Cfrg] Re: Changing the key deriveration In-Reply-To: <200402162018.i1GKIU97015035@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at technion.ac.il Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, 16 Feb 2004, The Purple Streak, Hilarie Orman wrote: > > In defense of the mechanism, we see that the value never appears on > the wire.It's unlikely to create any problems. > > Against it, we see that (asGreg Rose pointed out), the key was > created for one algorithm and might not have enough entropy to be used > safely for another.And, as Hugo points out, it is needlessly > unclean.In fact, wouldn't it be better to use SK_d for the purpose of > generating the not-on-the-wire authenticating value?This would avoid > having to generate two additional keys --- given that the additional > keys would be generated with the prf and SK_d anyway, the security > analysis seems a toss-up. > > I don't see any misuse of keys in section 2.16, "Extended > Authentication Protocol Methods", though it might be implicit in a > formula and I'm just not seeing it. I cannot blame you. The usage of prf with SK_a is "hidden" in section 2.16 under the following text: If EAP methods that do not generate a shared key are used, the AUTH payloads in messages 5 and 6 MUST be generated using SK_ai and SK_ar respectively. Now, the AUTH payload with a shared key (which is the case here) is defined in Section 2.15 as AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) Thus combining the above two definitions we get the use of prf(SK_a,...) in section 2.16. I hope it is crystal clear now, isn't it? :) Anyway, replacing SK_ai and SK_ar in the above text (as well as in 2.15, first paragraph) with SK_d does resolve the problem of using two algorithms (prf and integrity) with the same key, and it is much better than what is done now. I would still prefer the cleaner (from the point of view of design and analysis) solution that uses different keys for two essentially different applications of the prf function (as key derivation and as MAC), and I also prefer to use "directional keys" (i.e. SK_pi and SK_pr). (The latter may not be essential here but makes the defense against reflection attacks simpler to argue.) Yet, Hilarie's suggestion may be an acceptable "compromise" for those who feel that deriving two more keys is too onerous. Hugo > > Hilarie > > > > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Thu Feb 19 19:16:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05746 for ; Thu, 19 Feb 2004 19:16:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyKL-0004ua-Iw for cfrg-archive@odin.ietf.org; Thu, 19 Feb 2004 19:15:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K0FXLl018874 for cfrg-archive@odin.ietf.org; Thu, 19 Feb 2004 19:15:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyKL-0004uL-EX for cfrg-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 19:15:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05725 for ; Thu, 19 Feb 2004 19:15:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtyKJ-0005bt-00 for cfrg-web-archive@ietf.org; Thu, 19 Feb 2004 19:15:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtyJN-0005Yt-00 for cfrg-web-archive@ietf.org; Thu, 19 Feb 2004 19:14:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtyIi-0005WG-00 for cfrg-web-archive@ietf.org; Thu, 19 Feb 2004 19:13:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyHr-0004hJ-Kh; Thu, 19 Feb 2004 19:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyHO-0004dL-4K for cfrg@optimus.ietf.org; Thu, 19 Feb 2004 19:12:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05664 for ; Thu, 19 Feb 2004 19:12:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtyHM-0005TL-00 for cfrg@ietf.org; Thu, 19 Feb 2004 19:12:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtyGS-0005RP-00 for cfrg@ietf.org; Thu, 19 Feb 2004 19:11:33 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AtyG9-0005P9-00 for cfrg@ietf.org; Thu, 19 Feb 2004 19:11:13 -0500 Received: from platinum.qualcomm.com (platinum.qualcomm.com [129.46.51.243]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1K0B6vf013842; Thu, 19 Feb 2004 16:11:06 -0800 (PST) Received: from grose1.qualcomm.com (dhcp84.qualcomm.com [129.46.77.121]) by platinum.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id i1K0B15f001481; Thu, 19 Feb 2004 16:11:01 -0800 (PST) Message-Id: <6.0.0.22.2.20040220055003.039d1cc8@203.30.171.17> X-Sender: ggr2@203.30.171.17 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 20 Feb 2004 11:11:01 +1100 To: cfrg@ietf.org From: Greg Rose Subject: Re: [Cfrg] SOBER-128 draft rfc Cc: Greg Rose , phawkes@qualcomm.com, mwp@qualcomm.com, Dai Watanabe , Soichi Furuya Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 06:36 PM 2/9/2004 -0500, John Viega wrote: >In FSE there was a MAC forgery attack that succeeded with very high >probability. Should something with such an attack really be an RFC, >or was the attack actually incorrect? I did see the talk and it >seemed to make sense. I wrote: >(I assume you mean: >fse048 >Title: A MAC forgery attack on SOBER-128 >Authors: Dai Watanabe and Soichi Furuya Well, this is one of those very hard things to write... The attack certainly works, although the authors didn't make it very clear that it only works when MACing unencrypted material. For those who haven't seen it, here's my one-paragraph synopsys: you flip the 0x100 bit of one input word, the same bit of the word two words later, the 0x001 bit of the word 13 words later, and the 0x100 bit again of the word 17 words later. (These correspond to the LFSR feedback stages.) Then, with p=1/32, the MAC doesn't change. I'm very embarrassed, because it falls into the category of things I/we should have though of. Which is not to detract from Watanabe and Furuya 's work, which is neat. If it was obvious, I like to think we would have seen it. In a way, we did see it, because we extensively analysed the MAC function in combination with encryption. The reason that plaintext was input to the MAC feedback function was to ensure that differences in plaintexts would appropriately change the keystream output, thus leveraging the stronger nonlinearity of the keystream NLF. (That was a handwaving description of something I think we express more clearly in the design document.) I failed to take into account that this left us potentially vulnerable in the plaintext-only scenario; after all, we were designing a cipher, right? Is this problem fixable? Without sacrificing too much performance? As it happens, yes... there's a simple fix to this problem that we'd already considered in the design phase (that the authors above missed). Feed back ciphertext, not plaintext, when not encrypting. We originally didn't do this purely for the efficiency of not generating the unneeded keystream, not realizing that we'd opened up the same problem we'd already avoided once. To clarify: The input to the MAC feedback function now uses ciphertext bits when transmitting plaintext, and plaintext bits when transmitting ciphertext. These can be mingled at the level of individual bits, although our reference code only supports a byte-at-a-time interface. This mirrors our PEMI (Partial Encryption with Message Integrity) enhancement of Jutla's IAPM parallel encryption-and-MAC mode, which has been proven secure. The good outcome of this is that we might even be able to develop a proof of security for the MAC functionality based on the assumption of security for the stream cipher; but that's in the future. In the meantime, at least the fix is "pre-analyzed", because we are confident that duality applies and the MAC function now has the same security in both directions, and we believe that to be quite strong, although time will tell. While adapting the RFC we also noticed another "D'oh" moment. We hadn't fully specified how the MAC behaved when not using entire words, and allowed extension of partial words with zero bits to have the same MAC. We fixed this along the way. New versions of the reference (C and Java) source code, an updated design document, and updated RFC will be available on our website www.qualcomm.com.au approximately contemporaneously with this message. Note that the only behaviour that has changed has to do with MACing unencrypted plaintext. The keystream generator hasn't changed, and the result of MACing entirely encrypted plaintext hasn't changed. So we're not making a big change to the name of the cipher, just adding a version number for clarity to the various code and document names. Please bear in mind that our goal here is to produce a practical and usable cipher that has had lots of cryptanalysis applied to it. So we've done a lot of the development, historically, in public (and taken the necessary hits) and have been trying evolutionary, not revolutionary, changes. We consider this to be another step along that path, albeit an embarrassing one. Greg. Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Thu Feb 19 21:42:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12800 for ; Thu, 19 Feb 2004 21:42:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0bf-0000KY-6F for cfrg-archive@odin.ietf.org; Thu, 19 Feb 2004 21:41:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K2fZtO001266 for cfrg-archive@odin.ietf.org; Thu, 19 Feb 2004 21:41:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0be-0000KL-Tv for cfrg-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 21:41:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12762 for ; Thu, 19 Feb 2004 21:41:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au0bb-0000gB-00 for cfrg-web-archive@ietf.org; Thu, 19 Feb 2004 21:41:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au0al-0000cQ-00 for cfrg-web-archive@ietf.org; Thu, 19 Feb 2004 21:40:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au0Zs-0000ZT-00 for cfrg-web-archive@ietf.org; Thu, 19 Feb 2004 21:39:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0ZB-0008Uf-Am; Thu, 19 Feb 2004 21:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0Yn-0008RI-SH for cfrg@optimus.ietf.org; Thu, 19 Feb 2004 21:38:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12669 for ; Thu, 19 Feb 2004 21:38:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au0Yk-0000T9-00 for cfrg@ietf.org; Thu, 19 Feb 2004 21:38:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au0Xu-0000QP-00 for cfrg@ietf.org; Thu, 19 Feb 2004 21:37:43 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Au0XH-0000Ks-00 for cfrg@ietf.org; Thu, 19 Feb 2004 21:37:03 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2004 18:46:27 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1K2aU4U000916; Thu, 19 Feb 2004 18:36:31 -0800 (PST) Received: from [128.107.163.35] (dhcp-128-107-163-35.cisco.com [128.107.163.35]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQL59816; Thu, 19 Feb 2004 18:36:29 -0800 (PST) In-Reply-To: <6.0.0.22.2.20040220055003.039d1cc8@203.30.171.17> References: <6.0.0.22.2.20040220055003.039d1cc8@203.30.171.17> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <94C1080E-634D-11D8-8BA3-0003935495EC@cisco.com> Content-Transfer-Encoding: 7bit Cc: phawkes@qualcomm.com, mwp@qualcomm.com, cfrg@ietf.org, Soichi Furuya , Dai Watanabe From: "David A. McGrew" Subject: Re: [Cfrg] SOBER-128 draft rfc Date: Thu, 19 Feb 2004 18:36:26 -0800 To: Greg Rose X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greg, thanks for the update. No embarrassment, this happens to everyone in the business at one point or another, and evolution is certainly an important process here. I have one quick question: the attack is only on the MAC component, right? Is exhaustive search still the best known attack against the keystream generator? thanks, David On Feb 19, 2004, at 4:11 PM, Greg Rose wrote: > At 06:36 PM 2/9/2004 -0500, John Viega wrote: >> In FSE there was a MAC forgery attack that succeeded with very high >> probability. Should something with such an attack really be an RFC, >> or was the attack actually incorrect? I did see the talk and it >> seemed to make sense. > > I wrote: >> (I assume you mean: >> fse048 >> Title: A MAC forgery attack on SOBER-128 >> Authors: Dai Watanabe and Soichi Furuya > > Well, this is one of those very hard things to write... > > The attack certainly works, although the authors didn't make it very > clear that it only works when MACing unencrypted material. > > For those who haven't seen it, here's my one-paragraph synopsys: you > flip the 0x100 bit of one input word, the same bit of the word two > words later, the 0x001 bit of the word 13 words later, and the 0x100 > bit again of the word 17 words later. (These correspond to the LFSR > feedback stages.) Then, with p=1/32, the MAC doesn't change. > > I'm very embarrassed, because it falls into the category of things > I/we should have though of. Which is not to detract from Watanabe and > Furuya 's work, which is neat. If it was obvious, I like to think we > would have seen it. In a way, we did see it, because we extensively > analysed the MAC function in combination with encryption. The reason > that plaintext was input to the MAC feedback function was to ensure > that differences in plaintexts would appropriately change the > keystream output, thus leveraging the stronger nonlinearity of the > keystream NLF. (That was a handwaving description of something I think > we express more clearly in the design document.) I failed to take into > account that this left us potentially vulnerable in the plaintext-only > scenario; after all, we were designing a cipher, right? > > Is this problem fixable? Without sacrificing too much performance? As > it happens, yes... there's a simple fix to this problem that we'd > already considered in the design phase (that the authors above > missed). Feed back ciphertext, not plaintext, when not encrypting. We > originally didn't do this purely for the efficiency of not generating > the unneeded keystream, not realizing that we'd opened up the same > problem we'd already avoided once. > > To clarify: The input to the MAC feedback function now uses ciphertext > bits when transmitting plaintext, and plaintext bits when transmitting > ciphertext. These can be mingled at the level of individual bits, > although our reference code only supports a byte-at-a-time interface. > > This mirrors our PEMI (Partial Encryption with Message Integrity) > enhancement of Jutla's IAPM parallel encryption-and-MAC mode, which > has been proven secure. The good outcome of this is that we might even > be able to develop a proof of security for the MAC functionality based > on the assumption of security for the stream cipher; but that's in the > future. In the meantime, at least the fix is "pre-analyzed", because > we are confident that duality applies and the MAC function now has the > same security in both directions, and we believe that to be quite > strong, although time will tell. > > While adapting the RFC we also noticed another "D'oh" moment. We > hadn't fully specified how the MAC behaved when not using entire > words, and allowed extension of partial words with zero bits to have > the same MAC. We fixed this along the way. > > New versions of the reference (C and Java) source code, an updated > design document, and updated RFC will be available on our website > www.qualcomm.com.au approximately contemporaneously with this > message. Note that the only behaviour that has changed has to do with > MACing unencrypted plaintext. The keystream generator hasn't changed, > and the result of MACing entirely encrypted plaintext hasn't changed. > So we're not making a big change to the name of the cipher, just > adding a version number for clarity to the various code and document > names. > > Please bear in mind that our goal here is to produce a practical and > usable cipher that has had lots of cryptanalysis applied to it. So > we've done a lot of the development, historically, in public (and > taken the necessary hits) and have been trying evolutionary, not > revolutionary, changes. We consider this to be another step along that > path, albeit an embarrassing one. > > Greg. > > Greg Rose INTERNET: > ggr@qualcomm.com > Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 > 5199 > Level 3, 230 Victoria Road, > http://people.qualcomm.com/ggr/ > Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 > A37C > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Fri Feb 20 01:46:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21180 for ; Fri, 20 Feb 2004 01:46:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4Px-0000xo-NA for cfrg-archive@odin.ietf.org; Fri, 20 Feb 2004 01:45:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K6jjjc003700 for cfrg-archive@odin.ietf.org; Fri, 20 Feb 2004 01:45:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4Px-0000xb-HC for cfrg-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 01:45:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21000 for ; Fri, 20 Feb 2004 01:45:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au4Pt-00014Z-00 for cfrg-web-archive@ietf.org; Fri, 20 Feb 2004 01:45:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au4MF-0000Hw-00 for cfrg-web-archive@ietf.org; Fri, 20 Feb 2004 01:41:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Au4L6-0000CV-03 for cfrg-web-archive@ietf.org; Fri, 20 Feb 2004 01:40:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Au4HN-0000M0-5k for cfrg-web-archive@ietf.org; Fri, 20 Feb 2004 01:36:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4GX-0000Kb-RC; Fri, 20 Feb 2004 01:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4GG-0000KF-80 for cfrg@optimus.ietf.org; Fri, 20 Feb 2004 01:35:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20806 for ; Fri, 20 Feb 2004 01:35:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au4GD-0007mG-00 for cfrg@ietf.org; Fri, 20 Feb 2004 01:35:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au4FI-0007k8-00 for cfrg@ietf.org; Fri, 20 Feb 2004 01:34:44 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1Au4F3-0007i7-00 for cfrg@ietf.org; Fri, 20 Feb 2004 01:34:29 -0500 Received: from platinum.qualcomm.com (platinum.qualcomm.com [129.46.51.243]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1K6YLvf028016; Thu, 19 Feb 2004 22:34:21 -0800 (PST) Received: from grose1.qualcomm.com (vpn-10-50-16-68.qualcomm.com [10.50.16.68]) by platinum.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id i1K6YG5f014783; Thu, 19 Feb 2004 22:34:17 -0800 (PST) Message-Id: <6.0.0.22.2.20040220172937.03c78928@203.30.171.17> X-Sender: ggr2@203.30.171.17 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 20 Feb 2004 17:34:16 +1100 To: "David A. McGrew" From: Greg Rose Subject: Re: [Cfrg] SOBER-128 draft rfc Cc: Greg Rose , phawkes@qualcomm.com, mwp@qualcomm.com, cfrg@ietf.org In-Reply-To: <94C1080E-634D-11D8-8BA3-0003935495EC@cisco.com> References: <6.0.0.22.2.20040220055003.039d1cc8@203.30.171.17> <94C1080E-634D-11D8-8BA3-0003935495EC@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 06:36 PM 2/19/2004 -0800, David A. McGrew wrote: >I have one quick question: the attack is only on the MAC component, >right? Is exhaustive search still the best known attack against the >keystream generator? Yes. The keystream generator is completely bulletproof, unless someone comes up with an entirely new kind of attack. There was also a paper at FSE that claimed (when submitted) a distinguishing attack, but they got the complexity way wrong and retracted the result at the conference. Nothing comes even close to 2^128, that we know of. Greg. Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Mon Feb 23 12:33:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07896 for ; Mon, 23 Feb 2004 12:33:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJwb-0001QR-U6 for cfrg-archive@odin.ietf.org; Mon, 23 Feb 2004 12:32:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NHWbvQ005475 for cfrg-archive@odin.ietf.org; Mon, 23 Feb 2004 12:32:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJwb-0001QE-P9 for cfrg-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 12:32:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07888 for ; Mon, 23 Feb 2004 12:32:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJwa-0000Vt-00 for cfrg-web-archive@ietf.org; Mon, 23 Feb 2004 12:32:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJvf-0000Qs-00 for cfrg-web-archive@ietf.org; Mon, 23 Feb 2004 12:31:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvJv9-0000LC-00 for cfrg-web-archive@ietf.org; Mon, 23 Feb 2004 12:31:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJu8-00015I-2s; Mon, 23 Feb 2004 12:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvJtX-00012e-8Q for cfrg@optimus.ietf.org; Mon, 23 Feb 2004 12:29:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07726 for ; Mon, 23 Feb 2004 12:29:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvJtV-0000F0-00 for cfrg@ietf.org; Mon, 23 Feb 2004 12:29:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvJse-0000BG-00 for cfrg@ietf.org; Mon, 23 Feb 2004 12:28:33 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1AvJsF-00006f-00 for cfrg@ietf.org; Mon, 23 Feb 2004 12:28:07 -0500 Received: from platinum.qualcomm.com (platinum.qualcomm.com [129.46.51.243]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1NHS5np016467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2004 09:28:05 -0800 (PST) Received: from grose1.qualcomm.com (vpn-10-50-16-64.qualcomm.com [10.50.16.64]) by platinum.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id i1NHRx5f015395; Mon, 23 Feb 2004 09:27:59 -0800 (PST) Message-Id: <6.0.0.22.2.20040224042445.03bd2308@203.30.171.17> X-Sender: ggr2@203.30.171.17 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Tue, 24 Feb 2004 04:27:58 +1100 To: Greg Rose From: Greg Rose Subject: Re: [Cfrg] SOBER-128 draft rfc Cc: cfrg@ietf.org, phawkes@qualcomm.com, mwp@qualcomm.com, Dai Watanabe , Soichi Furuya In-Reply-To: <6.0.0.22.2.20040220055003.039d1cc8@203.30.171.17> References: <6.0.0.22.2.20040220055003.039d1cc8@203.30.171.17> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 So... Based on Watanabe & Furuya's work, even with the new scheme, there is a differential cryptanalysis MAC forgery attack on SOBER-128, whether encrypting or not. We're evaluating it, deciding what to do. This will not be a quick thing, though, so we're not publishing the updated RFC yet. To the best of our knowledge, the keystream generator is still very solid. Greg. At 11:11 AM 2/20/2004 +1100, Greg Rose wrote: >At 06:36 PM 2/9/2004 -0500, John Viega wrote: >>In FSE there was a MAC forgery attack that succeeded with very high >>probability. Should something with such an attack really be an RFC, >>or was the attack actually incorrect? I did see the talk and it >>seemed to make sense. > >I wrote: >>(I assume you mean: >>fse048 >>Title: A MAC forgery attack on SOBER-128 >>Authors: Dai Watanabe and Soichi Furuya > >Well, this is one of those very hard things to write... > >The attack certainly works, although the authors didn't make it very clear >that it only works when MACing unencrypted material. > >For those who haven't seen it, here's my one-paragraph synopsys: you flip >the 0x100 bit of one input word, the same bit of the word two words later, >the 0x001 bit of the word 13 words later, and the 0x100 bit again of the >word 17 words later. (These correspond to the LFSR feedback stages.) Then, >with p=1/32, the MAC doesn't change. > >I'm very embarrassed, because it falls into the category of things I/we >should have though of. Which is not to detract from Watanabe and Furuya 's >work, which is neat. If it was obvious, I like to think we would have seen >it. In a way, we did see it, because we extensively analysed the MAC >function in combination with encryption. The reason that plaintext was >input to the MAC feedback function was to ensure that differences in >plaintexts would appropriately change the keystream output, thus >leveraging the stronger nonlinearity of the keystream NLF. (That was a >handwaving description of something I think we express more clearly in the >design document.) I failed to take into account that this left us >potentially vulnerable in the plaintext-only scenario; after all, we were >designing a cipher, right? > >Is this problem fixable? Without sacrificing too much performance? As it >happens, yes... there's a simple fix to this problem that we'd already >considered in the design phase (that the authors above missed). Feed back >ciphertext, not plaintext, when not encrypting. We originally didn't do >this purely for the efficiency of not generating the unneeded keystream, >not realizing that we'd opened up the same problem we'd already avoided once. > >To clarify: The input to the MAC feedback function now uses ciphertext >bits when transmitting plaintext, and plaintext bits when transmitting >ciphertext. These can be mingled at the level of individual bits, although >our reference code only supports a byte-at-a-time interface. > >This mirrors our PEMI (Partial Encryption with Message Integrity) >enhancement of Jutla's IAPM parallel encryption-and-MAC mode, which has >been proven secure. The good outcome of this is that we might even be able >to develop a proof of security for the MAC functionality based on the >assumption of security for the stream cipher; but that's in the future. In >the meantime, at least the fix is "pre-analyzed", because we are confident >that duality applies and the MAC function now has the same security in >both directions, and we believe that to be quite strong, although time >will tell. > >While adapting the RFC we also noticed another "D'oh" moment. We hadn't >fully specified how the MAC behaved when not using entire words, and >allowed extension of partial words with zero bits to have the same MAC. We >fixed this along the way. > >New versions of the reference (C and Java) source code, an updated design >document, and updated RFC will be available on our website >www.qualcomm.com.au approximately contemporaneously with this message. >Note that the only behaviour that has changed has to do with MACing >unencrypted plaintext. The keystream generator hasn't changed, and the >result of MACing entirely encrypted plaintext hasn't changed. So we're not >making a big change to the name of the cipher, just adding a version >number for clarity to the various code and document names. > >Please bear in mind that our goal here is to produce a practical and >usable cipher that has had lots of cryptanalysis applied to it. So we've >done a lot of the development, historically, in public (and taken the >necessary hits) and have been trying evolutionary, not revolutionary, >changes. We consider this to be another step along that path, albeit an >embarrassing one. > >Greg. > >Greg Rose INTERNET: ggr@qualcomm.com >Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 >Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ >Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C Greg Rose INTERNET: ggr@qualcomm.com Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/ Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Mon Feb 23 16:34:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21066 for ; Mon, 23 Feb 2004 16:34:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNih-0003XU-RH for cfrg-archive@odin.ietf.org; Mon, 23 Feb 2004 16:34:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NLYVMC013603 for cfrg-archive@odin.ietf.org; Mon, 23 Feb 2004 16:34:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNih-0003XK-Jo for cfrg-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 16:34:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21020 for ; Mon, 23 Feb 2004 16:34:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvNif-0005qr-00 for cfrg-web-archive@ietf.org; Mon, 23 Feb 2004 16:34:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvNho-0005lt-00 for cfrg-web-archive@ietf.org; Mon, 23 Feb 2004 16:33:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvNh4-0005iB-00 for cfrg-web-archive@ietf.org; Mon, 23 Feb 2004 16:32:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNgH-0003P7-9E; Mon, 23 Feb 2004 16:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMbw-00012p-8L for cfrg@optimus.ietf.org; Fri, 20 Feb 2004 21:11:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28052 for ; Fri, 20 Feb 2004 21:11:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuMbt-00016a-00 for cfrg@ietf.org; Fri, 20 Feb 2004 21:11:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuMb0-00014O-00 for cfrg@ietf.org; Fri, 20 Feb 2004 21:10:23 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AuMao-00011d-00 for cfrg@ietf.org; Fri, 20 Feb 2004 21:10:10 -0500 Received: from [63.202.92.153] (adsl-63-202-92-153.dsl.snfc21.pacbell.net [63.202.92.153]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i1L29sjj044558; Fri, 20 Feb 2004 18:09:54 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Fri, 20 Feb 2004 18:09:58 -0800 To: cfrg@ietf.org, , Charlie Kaufman From: Paul Hoffman / VPNC Subject: Re: [Cfrg] Re: Changing the key deriveration Cc: Hugo Krawczyk , "The Purple Streak, Hilarie Orman" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL autolearn=no version=2.60 At 9:57 PM +0200 2/17/04, Hugo Krawczyk wrote: >Anyway, replacing SK_ai and SK_ar in the above text (as well as in 2.15, >first paragraph) with SK_d does resolve the problem of using two >algorithms (prf and integrity) with the same key, and it is much better >than what is done now. There have been no more comments on this, and the ADs are still waiting for a final draft of this document so they can move all three IKEv2 documents to IETF last call. Charlie: are you OK with this solution? If so, can you get the new draft out soon, such as when the Internet Drafts window opens? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Mon Feb 23 19:24:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04635 for ; Mon, 23 Feb 2004 19:24:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQMM-0004zH-KG for cfrg-archive@odin.ietf.org; Mon, 23 Feb 2004 19:23:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O0NcHx019165 for cfrg-archive@odin.ietf.org; Mon, 23 Feb 2004 19:23:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQMM-0004z2-76 for cfrg-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 19:23:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04524 for ; Mon, 23 Feb 2004 19:23:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvQMJ-0007Xp-00 for cfrg-web-archive@ietf.org; Mon, 23 Feb 2004 19:23:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvQLS-0007S5-00 for cfrg-web-archive@ietf.org; Mon, 23 Feb 2004 19:22:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvQKa-0007OU-00 for cfrg-web-archive@ietf.org; Mon, 23 Feb 2004 19:21:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQJp-0004s9-Ow; Mon, 23 Feb 2004 19:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQJN-0004rY-TD for cfrg@optimus.ietf.org; Mon, 23 Feb 2004 19:20:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04243 for ; Mon, 23 Feb 2004 19:20:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvQJM-0007HY-00 for cfrg@ietf.org; Mon, 23 Feb 2004 19:20:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvQIQ-0007EC-00 for cfrg@ietf.org; Mon, 23 Feb 2004 19:19:34 -0500 Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx with esmtp (Exim 4.12) id 1AvQII-0007BC-00 for cfrg@ietf.org; Mon, 23 Feb 2004 19:19:26 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i1O0InF20876; Mon, 23 Feb 2004 19:18:49 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i1O0Im754436; Mon, 23 Feb 2004 19:18:49 -0500 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i1O0ImI16348; Mon, 23 Feb 2004 19:18:48 -0500 Date: Mon, 23 Feb 2004 19:18:47 -0500 (EST) From: canetti To: Paul Hoffman / VPNC cc: cfrg@ietf.org, ipsec@lists.tislabs.com, Charlie Kaufman , Hugo Krawczyk , "The Purple Streak, Hilarie Orman" Subject: Re: [Cfrg] Re: Changing the key deriveration In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sorry for the delayed reaction. Let me try to be concise: 1. I strongly support the move to change the spec. Using the same key to two different algorithms is a big "no no" that, on top of other drawbacks, does not allow mathematical proofs of security to go through. (Not being amenable to analysis is a considerable *practical* weakness, even if do not see how to turn the weakness into an explicit attack...) 2. Both the solution suggested by Hugo (to derive two more keys from SEEDKEY, to be used for the PRF by the sender/responder, respectively), and the solution suggested by Hilarie (to use SK_d, the key meant for deriving the IPSEC keying material as the key to the PRF) are in principle sound. However, Hugo's solution seems somewhat more robust: It seems preferable to keep the ``virginity'' of the derivation key, SK_d, and refrain from using it inside the protocol. This feeling is compounded by the fact that in the password-based authentication mode the PRF is applied to messages of a generic password-based protocol, so the door may be open to "oracle attacks" that use the parties to obtain values of PRF(SK_d,...) on desired values. So, in conclusion, if we're already changing the spec for better analyzability/provability, then I think we should play it safe and derive two extra keys from SEEDKEY, rather than use SK_d. (The difference in performance and complexity between the two options seems minimal.) Ran On Fri, 20 Feb 2004, Paul Hoffman / VPNC wrote: > At 9:57 PM +0200 2/17/04, Hugo Krawczyk wrote: > >Anyway, replacing SK_ai and SK_ar in the above text (as well as in 2.15, > >first paragraph) with SK_d does resolve the problem of using two > >algorithms (prf and integrity) with the same key, and it is much better > >than what is done now. > > There have been no more comments on this, and the ADs are still > waiting for a final draft of this document so they can move all three > IKEv2 documents to IETF last call. > > Charlie: are you OK with this solution? If so, can you get the new > draft out soon, such as when the Internet Drafts window opens? > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Tue Feb 24 13:37:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03171 for ; Tue, 24 Feb 2004 13:37:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhQn-00061D-Gn for cfrg-archive@odin.ietf.org; Tue, 24 Feb 2004 13:37:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OIbLk0023121 for cfrg-archive@odin.ietf.org; Tue, 24 Feb 2004 13:37:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhQn-00060q-1O for cfrg-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 13:37:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03168 for ; Tue, 24 Feb 2004 13:37:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvhQi-0003qO-00 for cfrg-web-archive@ietf.org; Tue, 24 Feb 2004 13:37:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvhPo-0003le-00 for cfrg-web-archive@ietf.org; Tue, 24 Feb 2004 13:36:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvhPN-0003gP-00 for cfrg-web-archive@ietf.org; Tue, 24 Feb 2004 13:35:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhOb-0005nX-4R; Tue, 24 Feb 2004 13:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avfo2-0005XV-8s for cfrg@optimus.ietf.org; Tue, 24 Feb 2004 11:53:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29203 for ; Tue, 24 Feb 2004 11:53:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avfo1-0001Sb-00 for cfrg@ietf.org; Tue, 24 Feb 2004 11:53:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avfn8-0001Ny-00 for cfrg@ietf.org; Tue, 24 Feb 2004 11:52:18 -0500 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1Avfmk-0001Il-00 for cfrg@ietf.org; Tue, 24 Feb 2004 11:51:54 -0500 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1AvflW-0001je-00; Tue, 24 Feb 2004 11:50:38 -0500 Received: from tytso by thunk.org with local (Exim 4.30) id 1AvflU-0007Et-3l; Tue, 24 Feb 2004 11:50:36 -0500 Date: Tue, 24 Feb 2004 11:50:35 -0500 From: "Theodore Ts'o" To: Paul Hoffman / VPNC Cc: cfrg@ietf.org, ipsec@lists.tislabs.com, Charlie Kaufman , Hugo Krawczyk , "The Purple Streak, Hilarie Orman" Subject: Re: [Cfrg] Re: Changing the key deriveration Message-ID: <20040224165035.GA27403@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-7.8 required=5.0 tests=AWL,HABEAS_SWE autolearn=no version=2.60 On Fri, Feb 20, 2004 at 06:09:58PM -0800, Paul Hoffman / VPNC wrote: > At 9:57 PM +0200 2/17/04, Hugo Krawczyk wrote: > >Anyway, replacing SK_ai and SK_ar in the above text (as well as in 2.15, > >first paragraph) with SK_d does resolve the problem of using two > >algorithms (prf and integrity) with the same key, and it is much better > >than what is done now. > > There have been no more comments on this, and the ADs are still > waiting for a final draft of this document so they can move all three > IKEv2 documents to IETF last call. David and Ran --- is the CFRG currently working on some kind of official statement that represents the consensus of the group, or should we use the comments made by CFRG members in our deliberations? If the former, could you give us a timeline when the official comments from the CFRG can be expected? If the latter, please accept the thanks of the IPSEC working group to those members who took the time to evaluate Hugo's proposal. - Ted _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Tue Feb 24 15:30:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09549 for ; Tue, 24 Feb 2004 15:30:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvjC9-0007yF-GZ for cfrg-archive@odin.ietf.org; Tue, 24 Feb 2004 15:30:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OKULjp030638 for cfrg-archive@odin.ietf.org; Tue, 24 Feb 2004 15:30:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvjC9-0007y5-Cd for cfrg-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 15:30:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09526 for ; Tue, 24 Feb 2004 15:30:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvjC7-0006xT-00 for cfrg-web-archive@ietf.org; Tue, 24 Feb 2004 15:30:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvjBG-0006rv-00 for cfrg-web-archive@ietf.org; Tue, 24 Feb 2004 15:29:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvjAZ-0006mE-00 for cfrg-web-archive@ietf.org; Tue, 24 Feb 2004 15:28:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avj9t-0007nt-WC; Tue, 24 Feb 2004 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avj9J-0007lz-Ht for cfrg@optimus.ietf.org; Tue, 24 Feb 2004 15:27:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09353 for ; Tue, 24 Feb 2004 15:27:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avj9I-0006ds-00 for cfrg@ietf.org; Tue, 24 Feb 2004 15:27:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avj8I-0006WP-00 for cfrg@ietf.org; Tue, 24 Feb 2004 15:26:23 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Avj7V-0006KY-00 for cfrg@ietf.org; Tue, 24 Feb 2004 15:25:33 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Feb 2004 12:35:54 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1OKP01m002522; Tue, 24 Feb 2004 12:25:00 -0800 (PST) Received: from [10.34.251.98] (stealth-10-34-251-98.cisco.com [10.34.251.98]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AQP11531; Tue, 24 Feb 2004 12:24:58 -0800 (PST) In-Reply-To: <20040224165035.GA27403@thunk.org> References: <20040224165035.GA27403@thunk.org> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <77B04400-6707-11D8-A080-0003935495EC@cisco.com> Content-Transfer-Encoding: 7bit Cc: Hugo Krawczyk , cfrg@ietf.org, Charlie Kaufman , ipsec@lists.tislabs.com, Paul Hoffman / VPNC , "The Purple Streak, Hilarie Orman" From: "David A. McGrew" Subject: Re: [Cfrg] Re: Changing the key deriveration Date: Tue, 24 Feb 2004 15:24:37 -0500 To: "Theodore Ts'o" X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ted, I'll try to wrap up the discussion and move on a summary that we can agree on, in a separate mail. David On Feb 24, 2004, at 11:50 AM, Theodore Ts'o wrote: > On Fri, Feb 20, 2004 at 06:09:58PM -0800, Paul Hoffman / VPNC wrote: >> At 9:57 PM +0200 2/17/04, Hugo Krawczyk wrote: >>> Anyway, replacing SK_ai and SK_ar in the above text (as well as in >>> 2.15, >>> first paragraph) with SK_d does resolve the problem of using two >>> algorithms (prf and integrity) with the same key, and it is much >>> better >>> than what is done now. >> >> There have been no more comments on this, and the ADs are still >> waiting for a final draft of this document so they can move all three >> IKEv2 documents to IETF last call. > > David and Ran --- is the CFRG currently working on some kind of > official statement that represents the consensus of the group, or > should we use the comments made by CFRG members in our deliberations? > If the former, could you give us a timeline when the official comments > from the CFRG can be expected? If the latter, please accept the > thanks of the IPSEC working group to those members who took the time > to evaluate Hugo's proposal. > > - Ted > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Tue Feb 24 15:49:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10431 for ; Tue, 24 Feb 2004 15:49:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvjUW-00019M-Bg for cfrg-archive@odin.ietf.org; Tue, 24 Feb 2004 15:49:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OKnKvN004419 for cfrg-archive@odin.ietf.org; Tue, 24 Feb 2004 15:49:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvjUW-00019C-5r for cfrg-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 15:49:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10407 for ; Tue, 24 Feb 2004 15:49:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvjUU-0000sf-00 for cfrg-web-archive@ietf.org; Tue, 24 Feb 2004 15:49:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvjTZ-0000n6-00 for cfrg-web-archive@ietf.org; Tue, 24 Feb 2004 15:48:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvjT0-0000i8-00 for cfrg-web-archive@ietf.org; Tue, 24 Feb 2004 15:47:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvjSH-0000y4-HQ; Tue, 24 Feb 2004 15:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvjQd-0000qD-KC for cfrg@optimus.ietf.org; Tue, 24 Feb 2004 15:45:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10214 for ; Tue, 24 Feb 2004 15:45:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvjQc-0000UN-00 for cfrg@ietf.org; Tue, 24 Feb 2004 15:45:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvjPi-0000P0-00 for cfrg@ietf.org; Tue, 24 Feb 2004 15:44:22 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvjP1-0000H2-00 for cfrg@ietf.org; Tue, 24 Feb 2004 15:43:39 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1OKh74U011815; Tue, 24 Feb 2004 12:43:07 -0800 (PST) Received: from [10.34.251.98] (stealth-10-34-251-98.cisco.com [10.34.251.98]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AQP13534; Tue, 24 Feb 2004 12:43:05 -0800 (PST) In-Reply-To: <76651B96-6707-11D8-A080-0003935495EC@mindspring.com> References: <76651B96-6707-11D8-A080-0003935495EC@mindspring.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, "Theodore Ts'o" , byfraser@cisco.com, Hugo Krawczyk From: "David A. McGrew" Date: Tue, 24 Feb 2004 15:42:43 -0500 To: cfrg@ietf.org X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Subject: [Cfrg] additional key derivation in IKEv2 Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, we CFRGers need to wrap up the discussion of Hugo's proposed change to the IKEv2 Internet Draft (see https://www1.ietf.org/mail-archive/working-groups/cfrg/current/ msg00366.html). This ID is close to being wrapped up, so it is important that we get our comments in now. The questions that CFRG ought to be answering are: * Is the problem significant? * Is proposed solution good? * Is revising the specification warranted? From Barb Fraser, I understand that the cost of delaying the IKEv2 draft is not big - as long the change is small and can be made by the time that the periodic blackout on Internet Drafts is lifted on or around March 11th. From what I've gathered, it should be possible to make this change within this timeframe (Barb, Ted, Hugo, if I'm wrong about this, please correct me.) Here is my personal $0.02: the change is well motivated, the solution is good (it requires storing two extra keys, which seems not to be a big deal), and if the spec can be rev'ed in the next couple of weeks, I vote to do it. I spoke with several people about this issue who had similar sentiments. Other opinions welcome. David _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Wed Feb 25 09:23:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17596 for ; Wed, 25 Feb 2004 09:23:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avzw0-0004WX-6B for cfrg-archive@odin.ietf.org; Wed, 25 Feb 2004 09:22:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PEMmjO017383 for cfrg-archive@odin.ietf.org; Wed, 25 Feb 2004 09:22:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avzvz-0004WI-Km for cfrg-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 09:22:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17577 for ; Wed, 25 Feb 2004 09:22:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avzvx-0004fS-00 for cfrg-web-archive@ietf.org; Wed, 25 Feb 2004 09:22:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avzv0-0004Zq-00 for cfrg-web-archive@ietf.org; Wed, 25 Feb 2004 09:21:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avzu5-0004UJ-00 for cfrg-web-archive@ietf.org; Wed, 25 Feb 2004 09:20:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvztL-0004PK-Iy; Wed, 25 Feb 2004 09:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvztC-0004OH-AQ for cfrg@optimus.ietf.org; Wed, 25 Feb 2004 09:19:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17496 for ; Wed, 25 Feb 2004 09:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvztA-0004Pm-00 for cfrg@ietf.org; Wed, 25 Feb 2004 09:19:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvzsF-0004L9-00 for cfrg@ietf.org; Wed, 25 Feb 2004 09:18:55 -0500 Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx with esmtp (Exim 4.12) id 1Avzry-0004Fq-00 for cfrg@ietf.org; Wed, 25 Feb 2004 09:18:38 -0500 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i1PEI7F16908; Wed, 25 Feb 2004 09:18:07 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i1PEI6751160; Wed, 25 Feb 2004 09:18:06 -0500 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i1PEI6I32046; Wed, 25 Feb 2004 09:18:06 -0500 Date: Wed, 25 Feb 2004 09:18:05 -0500 (EST) From: canetti To: "David A. McGrew" cc: cfrg@ietf.org, ipsec@lists.tislabs.com, tytso@mit.edu, byfraser@cisco.com, hugo@ee.technion.ac.il In-Reply-To: <76651B96-6707-11D8-A080-0003935495EC@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Cfrg] Re: your mail Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I concur. Ran On Tue, 24 Feb 2004, David A. McGrew wrote: > Here is my personal $0.02: the change is well motivated, the solution > is good (it requires storing two extra keys, which seems not to be a > big deal), and if the spec can be rev'ed in the next couple of weeks, I > vote to do it. I spoke with several people about this issue who had > similar sentiments. Other opinions welcome. > > David > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Thu Feb 26 12:06:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24933 for ; Thu, 26 Feb 2004 12:06:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOx7-0006oQ-Pp for cfrg-archive@odin.ietf.org; Thu, 26 Feb 2004 12:05:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QH5bpe026186 for cfrg-archive@odin.ietf.org; Thu, 26 Feb 2004 12:05:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOx7-0006oH-Kz for cfrg-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 12:05:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24898 for ; Thu, 26 Feb 2004 12:05:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwOx6-00028b-00 for cfrg-web-archive@ietf.org; Thu, 26 Feb 2004 12:05:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwOw8-00022U-00 for cfrg-web-archive@ietf.org; Thu, 26 Feb 2004 12:04:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwOvA-0001wc-00 for cfrg-web-archive@ietf.org; Thu, 26 Feb 2004 12:03:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOtg-0006Mc-DX; Thu, 26 Feb 2004 12:02:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOt6-0006D8-7D for cfrg@optimus.ietf.org; Thu, 26 Feb 2004 12:01:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24614 for ; Thu, 26 Feb 2004 12:01:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwOt4-0001ex-00 for cfrg@ietf.org; Thu, 26 Feb 2004 12:01:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwOrv-0001Rj-00 for cfrg@ietf.org; Thu, 26 Feb 2004 12:00:15 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AwOqZ-00014s-00 for cfrg@ietf.org; Thu, 26 Feb 2004 11:58:52 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 26 Feb 2004 08:58:53 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1QGwIvV006785; Thu, 26 Feb 2004 08:58:18 -0800 (PST) Received: from [10.34.251.98] (stealth-10-34-251-98.cisco.com [10.34.251.98]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AQR04923; Thu, 26 Feb 2004 08:58:16 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Theodore Ts'o" , Hugo Krawczyk , byfraser@cisco.com, canetti , ipsec@lists.tislabs.com From: "David A. McGrew" Subject: Re: [Cfrg] Re: your mail Date: Thu, 26 Feb 2004 11:57:54 -0500 To: cfrg@ietf.org X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit CFRGers, is there anyone with another viewpoint about Hugo's proposed changes (described at https://www1.ietf.org/mail-archive/working-groups/cfrg/current/ msg00366.html)? If not, we will go ahead and give this positive report this back to the IPsec WG. thanks, David On Feb 25, 2004, at 9:18 AM, canetti wrote: > > I concur. > > Ran > > > On Tue, 24 Feb 2004, David A. McGrew wrote: > >> Here is my personal $0.02: the change is well motivated, the solution >> is good (it requires storing two extra keys, which seems not to be a >> big deal), and if the spec can be rev'ed in the next couple of weeks, >> I >> vote to do it. I spoke with several people about this issue who had >> similar sentiments. Other opinions welcome. >> >> David >> > > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg