From exim@www1.ietf.org Wed Jul 9 13:05:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10293 for ; Wed, 9 Jul 2003 13:05:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aIMv-00050x-CQ for cfrg-archive@odin.ietf.org; Wed, 09 Jul 2003 13:04:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69H4bw1019275 for cfrg-archive@odin.ietf.org; Wed, 9 Jul 2003 13:04:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aIMv-00050o-8I for cfrg-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 13:04:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10253 for ; Wed, 9 Jul 2003 13:04:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aIMt-0000nW-00 for cfrg-web-archive@ietf.org; Wed, 09 Jul 2003 13:04:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aIMs-0000nS-00 for cfrg-web-archive@ietf.org; Wed, 09 Jul 2003 13:04:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aIMM-0004ub-8n; Wed, 09 Jul 2003 13:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHan-0001eX-Rs for cfrg@optimus.ietf.org; Wed, 09 Jul 2003 12:14:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08213 for ; Wed, 9 Jul 2003 12:14:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aHal-0000HF-00 for cfrg@ietf.org; Wed, 09 Jul 2003 12:14:51 -0400 Received: from mpdir1.jmu.edu ([134.126.12.40] ident=mirapoint) by ietf-mx with esmtp (Exim 4.12) id 19aHal-0000HB-00 for cfrg@ietf.org; Wed, 09 Jul 2003 12:14:51 -0400 Received: from exchange1.CISAT.JMU.EDU ([134.126.69.6]) by mpdir1.jmu.edu (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id AEG85747; Wed, 9 Jul 2003 12:14:42 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34635.344C8DFB" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Wed, 9 Jul 2003 12:14:42 -0400 Message-ID: <95B156112CF89C4390AB7CF09E601906054D1F@exchange1.cisat.jmu.edu> Thread-Topic: one question about hash Thread-Index: AcM5mw9UICG8vxIuQYe8igrIIPOFtgMmV09A From: "Wang, Steve" To: Subject: [Cfrg] one question about hash 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: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C34635.344C8DFB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have one question about secure hash functions. Assume that H is a secure hash function and k is a 128-bit symmetric key. One can compute k1 =3D H (k || 1) and k2 =3D H(k || 2) {|| denotes string = concatenation}. If H is an ideal function, then it is hard to compute k1 from k2 and vice versa. What will happen if we replace H with SHA-1? =20 Thanks, =20 Steve =20 =20 ------_=_NextPart_001_01C34635.344C8DFB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SAC 2003 - Accepted Papers and Registration Information Now = Available

Hi,

 <= /span>

I have one = question about secure hash functions. Assume that H is a secure hash function and k is = a 128-bit symmetric key. One can compute k1 =3D H (k || 1) and k2 =3D H(k || 2) = {|| denotes = string concatenation}. If H is an = ideal function, then it is hard to compute k1 from k2 and vice versa. What = will happen if we replace H with SHA-1?

 <= /span>

Thanks,=

 <= /span>

Steve

 

 

------_=_NextPart_001_01C34635.344C8DFB-- _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Wed Jul 9 15:16:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16542 for ; Wed, 9 Jul 2003 15:16:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKQM-0004wg-PJ for cfrg-archive@odin.ietf.org; Wed, 09 Jul 2003 15:16:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69JGIMt019006 for cfrg-archive@odin.ietf.org; Wed, 9 Jul 2003 15:16:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKQM-0004wT-Lr for cfrg-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 15:16:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16490 for ; Wed, 9 Jul 2003 15:16:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKQL-00029m-00 for cfrg-web-archive@ietf.org; Wed, 09 Jul 2003 15:16:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aKQK-00029j-00 for cfrg-web-archive@ietf.org; Wed, 09 Jul 2003 15:16:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKQ5-0004v1-Tz; Wed, 09 Jul 2003 15:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKQ2-0004um-VB for cfrg@optimus.ietf.org; Wed, 09 Jul 2003 15:15:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16452 for ; Wed, 9 Jul 2003 15:15:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKQ1-00029P-00 for cfrg@ietf.org; Wed, 09 Jul 2003 15:15:57 -0400 Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx with esmtp (Exim 4.12) id 19aKQ0-00029M-00 for cfrg@ietf.org; Wed, 09 Jul 2003 15:15:56 -0400 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h69JEKq158132; Wed, 9 Jul 2003 15:14:20 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h69JFOS101736; Wed, 9 Jul 2003 15:15:25 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3p2/8.9.3/09-18-2002) with ESMTP id PAA33442; Wed, 9 Jul 2003 15:15:24 -0400 Date: Wed, 9 Jul 2003 15:15:24 -0400 (EDT) From: canetti To: "Wang, Steve" cc: cfrg@ietf.org Subject: Re: [Cfrg] one question about hash In-Reply-To: <95B156112CF89C4390AB7CF09E601906054D1F@exchange1.cisat.jmu.edu> 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: , Well, that's the million-dollar question... :) We have no definite guarantees that "SHA1 behaves like an ideal function". In fact, your example demonstrates that it does not really: With your construction the answer may depend on how "1" and "2" are encoded. For instance, if |k| is exactly a block-size, and you encode "1" as a block of 1's, and encode "2" as two blocks of 1's, then k2 is easily computable from k1 if SHA1 is used. The trick is to be able to show how to derive keys using SHA1, while making the weakest assumptions on SHA1. If you define k1=HMAC_k(1) and k2=HMAC_k(2) then k1 and k2 will be "computationally independent" under relatively weak assumptions on SHA1, regardless of how "1" and "2" are encoded. (In particular, you would not need to assume that "SHA1 behaves like an ideal function".) Ran On Wed, 9 Jul 2003, Wang, Steve wrote: > Hi, > > I have one question about secure hash functions. Assume that H is a > secure hash function and k is a 128-bit symmetric key. One can compute > k1 = H (k || 1) and k2 = H(k || 2) {|| denotes string concatenation}. If > H is an ideal function, then it is hard to compute k1 from k2 and vice > versa. What will happen if we replace H with SHA-1? > > Thanks, > > Steve > > > _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Thu Jul 10 11:15:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06847 for ; Thu, 10 Jul 2003 11:15:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ad8g-0000gN-B1 for cfrg-archive@odin.ietf.org; Thu, 10 Jul 2003 11:15:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AFFIex002619 for cfrg-archive@odin.ietf.org; Thu, 10 Jul 2003 11:15:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ad8g-0000gA-7W for cfrg-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 11:15:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06788 for ; Thu, 10 Jul 2003 11:15:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ad8f-0003rP-00 for cfrg-web-archive@ietf.org; Thu, 10 Jul 2003 11:15:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ad8e-0003rM-00 for cfrg-web-archive@ietf.org; Thu, 10 Jul 2003 11:15:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ad8O-0000e1-MV; Thu, 10 Jul 2003 11:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ad7q-0000al-Ar for cfrg@optimus.ietf.org; Thu, 10 Jul 2003 11:14:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06606 for ; Thu, 10 Jul 2003 11:14:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ad7p-0003pO-00 for cfrg@ietf.org; Thu, 10 Jul 2003 11:14:25 -0400 Received: from mailout.zetnet.co.uk ([194.247.47.231]) by ietf-mx with esmtp (Exim 4.12) id 19ad7o-0003pL-00 for cfrg@ietf.org; Thu, 10 Jul 2003 11:14:24 -0400 Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by mailout.zetnet.co.uk with esmtp (Exim 3.36 #1 (Debian)) id 19ad7n-0002u0-00 for ; Thu, 10 Jul 2003 16:14:23 +0100 Received: from zetnet.co.uk (bts-0072.dialup.zetnet.co.uk [194.247.48.72]) by zetnet.co.uk (8.12.3/8.12.3/Debian-5.zet) with ESMTP id h6AFEJNx003762 for ; Thu, 10 Jul 2003 16:14:21 +0100 Message-ID: <3F0D8FAA.9ACD1EE@zetnet.co.uk> Date: Thu, 10 Jul 2003 16:09:14 +0000 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: cfrg@ietf.org Subject: Re: [Cfrg] one question about hash References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- canetti wrote: > We have no definite guarantees that "SHA1 behaves like an ideal function". > In fact, your example demonstrates that it does not really: > With your construction the answer may depend on how "1" and "2" are > encoded. For instance, if |k| is exactly a block-size, and you encode "1" > as a block of 1's, and encode "2" as two blocks of 1's, then k2 is easily > computable from k1 if SHA1 is used. I think you mean that "1" and "2" would have be encoded in such a way that the result of padding k || "1", taking into account the length field, is a prefix of k || "2"; in that case k2 is easily computed from k1. I agree that it is better to use HMAC for key separation than a plain hash function. - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPw2PgjkCAxeYt5gVAQFRjgf/a9lTAlD1v6kisIo/tBASq5PIbEAlZkAG JFXQYr7fhHgb+8nbAKrUQ5E0O/Aab6AX8ZG63H438zORiiAnY4eO85xjMCQTguO8 vIoqlwIOPJkAF7V5wjEvcT12isHr+tzFSCmxI2bV+RciXk6iJyncrCY0Tv2HehZM oyF5zQmGlbFV94+yPoMrqw5sBAWsXGjPaeN4cfWKCnQhwK3lELvMk368pRil7YST vnS9fwdKnuhnHv76ZKq5BBYwWZ31Sysdryo5rkSxCUP59XQ19SRqDQafsI5x7NHy 6xIQao7wbrazRkHE0ZfWp9I+KUC29DC/cpzqocgKFZYXswrUtr5w2A== =kVjn -----END PGP SIGNATURE----- _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Thu Jul 10 13:45:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14128 for ; Thu, 10 Jul 2003 13:45:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19afTI-0006dl-Fe for cfrg-archive@odin.ietf.org; Thu, 10 Jul 2003 13:44:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AHiiHS025519 for cfrg-archive@odin.ietf.org; Thu, 10 Jul 2003 13:44:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19afTI-0006dW-BR for cfrg-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 13:44:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14103 for ; Thu, 10 Jul 2003 13:44:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19afTG-0005a0-00 for cfrg-web-archive@ietf.org; Thu, 10 Jul 2003 13:44:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19afTF-0005Zw-00 for cfrg-web-archive@ietf.org; Thu, 10 Jul 2003 13:44:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19afSb-0006b6-5U; Thu, 10 Jul 2003 13:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19af6U-00043T-RU for cfrg@optimus.ietf.org; Thu, 10 Jul 2003 13:21:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13040 for ; Thu, 10 Jul 2003 13:21:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19af6S-0005LL-00 for cfrg@ietf.org; Thu, 10 Jul 2003 13:21:08 -0400 Received: from piper.cs.colorado.edu ([128.138.236.20]) by ietf-mx with esmtp (Exim 4.12) id 19af6R-0005L7-00 for cfrg@ietf.org; Thu, 10 Jul 2003 13:21:07 -0400 Received: from piper.cs.colorado.edu (localhost [127.0.0.1]) by piper.cs.colorado.edu (8.12.9/8.12.6) with ESMTP id h6AHKTSg004852; Thu, 10 Jul 2003 11:20:30 -0600 (MDT) Received: (from jrblack@localhost) by piper.cs.colorado.edu (8.12.9/8.12.6/Submit) id h6AHKTqs004851; Thu, 10 Jul 2003 11:20:29 -0600 (MDT) Date: Thu, 10 Jul 2003 11:20:29 -0600 From: "John R. Black" To: canetti@watson.ibm.com Cc: cfrg@ietf.org Message-ID: <20030710112029.B4793@cs> References: <20030710160004.15616.24446.Mailman@www1.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20030710160004.15616.24446.Mailman@www1.ietf.org>; from cfrg-request@ietf.org on Thu, Jul 10, 2003 at 12:00:04PM -0400 Subject: [Cfrg] Re: one question about hash 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: , > Date: Wed, 9 Jul 2003 15:15:24 -0400 (EDT) > From: canetti > > We have no definite guarantees that "SHA1 behaves like an ideal function". > In fact, your example demonstrates that it does not really: > With your construction the answer may depend on how "1" and "2" are > encoded. For instance, if |k| is exactly a block-size, and you encode "1" > as a block of 1's, and encode "2" as two blocks of 1's, then k2 is easily > computable from k1 if SHA1 is used. > Ran, You're assuming that you can extend SHA1(k || 1^n) to SHA1(k || 1^{2n}) without knowing k? Remember that SHA1 (and SHA-{256,384,512}) all use MD-strengthening so the bit-length of the hashed msg is encoded in the final bits of the input before it is hashed. This means it is non-trivial to extend a SHA1 output. john// _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Thu Jul 10 17:05:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21692 for ; Thu, 10 Jul 2003 17:05:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aian-0008DD-NI for cfrg-archive@odin.ietf.org; Thu, 10 Jul 2003 17:04:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AL4fvj031565 for cfrg-archive@odin.ietf.org; Thu, 10 Jul 2003 17:04:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aian-0008D2-Ib for cfrg-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 17:04:41 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21666 for ; Thu, 10 Jul 2003 17:04:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aia9-00087P-EA; Thu, 10 Jul 2003 17:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aiZX-00086p-77 for cfrg@optimus.ietf.org; Thu, 10 Jul 2003 17:03:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21652 for ; Thu, 10 Jul 2003 17:03:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aiZU-0007IZ-00 for cfrg@ietf.org; Thu, 10 Jul 2003 17:03:20 -0400 Received: from ee.technion.ac.il ([132.68.48.5]) by ietf-mx with esmtp (Exim 4.12) id 19aiZT-0007IW-00 for cfrg@ietf.org; Thu, 10 Jul 2003 17:03:19 -0400 Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.11.6+Sun/8.10.2) with ESMTP id h6AL3hK07189; Fri, 11 Jul 2003 00:03:44 +0300 (IDT) Date: Fri, 11 Jul 2003 00:03:43 +0300 (IDT) From: Hugo Krawczyk To: "John R. Black" cc: canetti@watson.ibm.com, cfrg@ietf.org Subject: Re: [Cfrg] Re: one question about hash In-Reply-To: <20030710112029.B4793@cs> 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: , Don't take Ran's example too literally. What he was pointing out to (even if he did not say this explicitly) is that even if the compression function of SHA-1 is a totally random function then the iterated SHA-1 is not. In particular, this brings up the issue that using plain SHA-1 your security may depend on the way you encode the input to the function. To make Ran's example really work you have to encode 1 as a string of 448 (=512-64) 1's, and encode 2 as the concatenation of 448 1's followed by a 64-bit representation of the number 2^63+448, followed by another 448 1's. Surely enough, no one is going to use such an encoding but, again, the point is in showing that the iterated SHA-1 is not random (or unpredictable for this matter) even if the compression function is. These considerations however do not really answer the original question that arises in natural settings, namely, are SHA1(k,1) and SHA(k,2) "computationally independent", if we fix the encoding to be 160 bits for the key followed by a single octet representing 1 or 2 (or 0 and 1)? Here the answer is: we do not realy know. Or, with a more optimistic twist: as far as we know today, this is ok. Yet it is always good to use standard constructions with security proven independently of the application and other specifics such as the semantics of the data or its encoding. In that sense HMAC is a good solution. Especially that it enjoys a proof of security based on much less that "ideal" assumptions on the compression function. In addition, I personally do not like "counter mode" constructions where the only difference between two inputs to the function (as is the case with SHA1(k,1) and SHA(k,2)) is by one or two bits at most. In my opinion, robustness to cryptanalytical advances calls for more prudent designs. In this sense, HMAC has a significant contribution via its "double hashing". Moreover, as in the case of TLS and IKE, also here I'd recommend "feedback mode" for key derivation; in the above example we would have K1=HMAC-SHA1(k,1) and K2=HMAC-SHA1(k,K1)). Finally, there is also a drawback to using HMAC. While SHA-1(k,i) takes only one application of the compression function, HMAC would take two (or even three, if you do not cache the initial value produced by the first iteration of HMAC). This may be totally negligible (especially in the case of key derivation) but may be significant in other situations (e.g. when implementing defenses against DoS attacks). In these cases the engineering trade-offs (and possibly the less stringent security requirements) may justify going to the less robust solutions Sorry for the long response, I just wanted to write the first paragraph but found myself in a too talkative mode... Hugo On Thu, 10 Jul 2003, John R. Black wrote: > > Date: Wed, 9 Jul 2003 15:15:24 -0400 (EDT) > > From: canetti > > > > We have no definite guarantees that "SHA1 behaves like an ideal function". > > In fact, your example demonstrates that it does not really: > > With your construction the answer may depend on how "1" and "2" are > > encoded. For instance, if |k| is exactly a block-size, and you encode "1" > > as a block of 1's, and encode "2" as two blocks of 1's, then k2 is easily > > computable from k1 if SHA1 is used. > > > > Ran, > > You're assuming that you can extend SHA1(k || 1^n) to SHA1(k || 1^{2n}) > without knowing k? > > Remember that SHA1 (and SHA-{256,384,512}) all use MD-strengthening so > the bit-length of the hashed msg is encoded in the final bits of the > input before it is hashed. This means it is non-trivial to extend a > SHA1 output. > > john// > > _______________________________________________ > 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 Jul 11 10:05:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29830 for ; Fri, 11 Jul 2003 10:05:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayWY-0004UZ-3b for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 10:05:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BE5MjT017262 for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 10:05:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayWX-0004UL-Vf for cfrg-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 10:05:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29761 for ; Fri, 11 Jul 2003 10:05:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ayWV-0005s1-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 10:05:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ayWV-0005ry-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 10:05:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayWD-0004Oh-22; Fri, 11 Jul 2003 10:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ayVO-0004Lf-SR for cfrg@optimus.ietf.org; Fri, 11 Jul 2003 10:04:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29573 for ; Fri, 11 Jul 2003 10:04:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ayVJ-0005qG-00 for cfrg@ietf.org; Fri, 11 Jul 2003 10:04:05 -0400 Received: from pigeon.verisign.com ([65.205.251.71]) by ietf-mx with esmtp (Exim 4.12) id 19ayVI-0005qD-00 for cfrg@ietf.org; Fri, 11 Jul 2003 10:04:04 -0400 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h6BE3s2Q012494; Fri, 11 Jul 2003 07:03:57 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jul 2003 07:03:54 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2312@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Hugo Krawczyk'" , "John R. Black" Cc: canetti@watson.ibm.com, cfrg@ietf.org Subject: RE: [Cfrg] Re: one question about hash Date: Fri, 11 Jul 2003 07:03:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Following on from Hugo's question This is an issue that has always troubled me about the MD5 and SHA1 itteration functions. I would prefer it if there was some significant difference between the itteration step and the result, something that simply cannot be constructed from normal operation For example changing the way in which the chaining variables are transmitted from one step to the next for the final iteration of the compression function. This could be as simple as a permutation on the chaining variables, H0' = H1, H1'= H2 etc... For the HTTP digest spec I put the output of the message digest through the message digest function again concatenated with a bunch of other values as a way to achieve this same effect. Even so I would prefer to see the message extension issue eliminated entirely, I don't think it is an acceptable property for a cryptographic primitive. Phill _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Fri Jul 11 11:44:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03995 for ; Fri, 11 Jul 2003 11:44:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b048-0003nJ-Nu for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 11:44:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BFi8Kf014584 for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 11:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b048-0003n9-IE for cfrg-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 11:44:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03984 for ; Fri, 11 Jul 2003 11:44:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b047-0006ck-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 11:44:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b046-0006ch-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 11:44:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b041-0003lz-Es; Fri, 11 Jul 2003 11:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b03A-0003kb-Iy for cfrg@optimus.ietf.org; Fri, 11 Jul 2003 11:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03975 for ; Fri, 11 Jul 2003 11:43:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b039-0006cM-00 for cfrg@ietf.org; Fri, 11 Jul 2003 11:43:07 -0400 Received: from [207.61.238.66] (helo=mail.okiok.com) by ietf-mx with esmtp (Exim 4.12) id 19b038-0006bz-00 for cfrg@ietf.org; Fri, 11 Jul 2003 11:43:06 -0400 Received: from p1038mobile (unknown [192.168.0.63]) by mail.okiok.com (Postfix) with ESMTP id 6B10FB4064; Fri, 11 Jul 2003 11:24:57 -0400 (EDT) Message-ID: <004101c347c3$2c6c8490$3f00a8c0@p1038mobile> From: "Anton Stiglic" To: "Hugo Krawczyk" , "John R. Black" Cc: , References: Subject: Re: [Cfrg] Re: one question about hash Date: Fri, 11 Jul 2003 11:43:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > These considerations however do not really answer the original question > that arises in natural settings, namely, are SHA1(k,1) and SHA(k,2) > "computationally independent", if we fix the encoding to be 160 bits for > the key followed by a single octet representing 1 or 2 (or 0 and 1)? Here > the answer is: we do not really know. Or, with a more optimistic twist: as > far as we know today, this is ok. If you consider SHA1(k, .) as a PRF, and the input is prefix-free (that is the case say if the representation of 1, 2,... is made in say n octets for some fixed n), then results of the paper "The Cascade Construction and its Concrete Security" (by Hugo, Ran, and Mihir) apply. By that I mean (informally) that if you assume that the compression function of SHA1 makes for a good Finite-length Input PRF, and assume some other pseudoranmness properties about the compression function (which are also assumed in the proof of HMAC), then SHA1(k,.) makes for a good PRF (assuming k is chosen randomly of course...). These are about the same assumption needed to prove that HMAC based on SHA1 makes for a good PRF (note that I'm not talking about the proof that HMAC is a good MAC, which assumes that the compression function acts like a good MAC, which is possibly a weaker assumption). So I don't understand why you state that we don't really know about the security of such a scheme. I say we know as much about the security of SHA1(k,.) as a PRF, with prefix-free inputs, that we know about HMAC-SHA1 on variable inputs. But Hugo you are one of the authors of the paper I referred to, so you surely have more insight than I do, can you elaborate? Is it really just an educated feeling you have that makes you say that HMAC-SHA1 would be better because the inner hash randomizes in some sense the inputs to the PRF? --Anton _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Fri Jul 11 12:27:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04965 for ; Fri, 11 Jul 2003 12:27:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0ju-0007hf-Pm for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 12:27:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BGRIAi029610 for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 12:27:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0ju-0007hV-Mu for cfrg-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 12:27:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04942 for ; Fri, 11 Jul 2003 12:27:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b0jg-0006t3-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 12:27:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b0jg-0006t0-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 12:27:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0jd-0007cu-6A; Fri, 11 Jul 2003 12:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0ix-0007cV-QS for cfrg@optimus.ietf.org; Fri, 11 Jul 2003 12:26:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04896 for ; Fri, 11 Jul 2003 12:26:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b0iw-0006sW-00 for cfrg@ietf.org; Fri, 11 Jul 2003 12:26:18 -0400 Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx with esmtp (Exim 4.12) id 19b0iv-0006s5-00 for cfrg@ietf.org; Fri, 11 Jul 2003 12:26:17 -0400 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h6BGObq188060 for ; Fri, 11 Jul 2003 12:24:37 -0400 Received: from halevi.watson.ibm.com (halevi.watson.ibm.com [9.2.16.46]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h6BGPjS109652 for ; Fri, 11 Jul 2003 12:25:45 -0400 Received: from localhost (localhost [[UNIX: localhost]]) by halevi.watson.ibm.com (8.11.6/8.11.6/2001/12/13) id h6BGPkB16372 for cfrg@ietf.org; Fri, 11 Jul 2003 12:25:46 -0400 Content-Type: text/plain; charset="iso-8859-1" From: Shai Halevi Organization: IBM To: cfrg@ietf.org Subject: [Cfrg] counter mode vs feedback mode (Re: one question about hash) Date: Fri, 11 Jul 2003 12:25:45 -0400 User-Agent: KMail/1.4.1 References: <20030711160004.18786.3923.Mailman@www1.ietf.org> In-Reply-To: <20030711160004.18786.3923.Mailman@www1.ietf.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200307111225.45595.shaih@watson.ibm.com> Content-Transfer-Encoding: quoted-printable 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hugo, I take issue with the following point:=20 > [...] > In addition, I personally do not like "counter mode" constructions wher= e > the only difference between two inputs to the function (as is the case > with SHA1(k,1) and SHA(k,2)) is by one or two bits at most. In my opini= on, > robustness to cryptanalytical advances calls for more prudent designs. = =20 > In this sense, HMAC has a significant contribution via its "double hash= ing".=20 > Moreover, as in the case of TLS and IKE, also here I'd recommend > "feedback mode" for key derivation; in the above example we would have > K1=3DHMAC-SHA1(k,1) and K2=3DHMAC-SHA1(k,K1)). Building blocks such as block ciphers and hash functions are explicitly=20 designed to be secure against "small variations" in their inputs. Indeed,= =20 much of the work involved in the design of such primitives is to analyze=20 (and defend against) attacks that involve such "similar inputs".=20 Hence, I feel quite confortable using these primitives in counter mode.=20 In fact, more confortable than using them in the "feedback mode" that you= =20 describe. Such feedback mode may be suspetible to short cycles. Although=20 extremely unlikely, I view short cycles as more likely than problems with= =20 counter mode. Simply because typically, the designers of such primitives=20 spend (almost) no time thinking about short cycles, but lots and lots of=20 time thinking about "similar inputs".=20 -- Shai _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Fri Jul 11 14:08:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08577 for ; Fri, 11 Jul 2003 14:08:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2J3-0007rC-8z for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 14:07:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BI7fVD030196 for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 14:07:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2J3-0007qx-4Q for cfrg-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 14:07:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08544 for ; Fri, 11 Jul 2003 14:07:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b2J0-0000EQ-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 14:07:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b2J0-0000EM-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 14:07:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2IP-0007ZJ-TA; Fri, 11 Jul 2003 14:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b2HZ-0007XK-49 for cfrg@optimus.ietf.org; Fri, 11 Jul 2003 14:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08495 for ; Fri, 11 Jul 2003 14:06:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b2HW-0000D7-00 for cfrg@ietf.org; Fri, 11 Jul 2003 14:06:06 -0400 Received: from ee.technion.ac.il ([132.68.48.5]) by ietf-mx with esmtp (Exim 4.12) id 19b2HV-0000D0-00 for cfrg@ietf.org; Fri, 11 Jul 2003 14:06:05 -0400 Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.11.6+Sun/8.10.2) with ESMTP id h6BI6bx22749; Fri, 11 Jul 2003 21:06:37 +0300 (IDT) Date: Fri, 11 Jul 2003 21:06:37 +0300 (IDT) From: Hugo Krawczyk To: Anton Stiglic cc: cfrg@ietf.org Subject: Re: [Cfrg] Re: one question about hash In-Reply-To: <004101c347c3$2c6c8490$3f00a8c0@p1038mobile> 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: , In order to apply the results from the paper you mention to SHA1(k,...) you have to assume that k occupies a full block (i.e. the input is aligned to start in the second block) and that (as you say) the inputs are ensured to be prefix-free (i.e. the atacker will never see the output of the function on two different inputs x and x for which x is a prefix of x'). This strong requirement for prefix-freeness is avoided at all by hmac and in that sense hmac is a (significantly) better prf construction than SHA1(k,...) for general use. For the specific case of key derivation the prefix-freeness may be less of a problem if you are careful enough to design the input to the function in the key-derivation process to be prefix-free. But the original question talked about SHA1(k,i) which I guess (that is the usual and natural case) was intended to mean k concatenated with the index i all filling in one block. In this case the analysis of the mentioned paper does not apply (or at least requires a re-modelling of the prf family). Besides, as you hint to I also like the "double hashing" of HMAC as a "robustness measure" (or second line defense). Hugo On Fri, 11 Jul 2003, Anton Stiglic wrote: > > > > These considerations however do not really answer the original question > > that arises in natural settings, namely, are SHA1(k,1) and SHA(k,2) > > "computationally independent", if we fix the encoding to be 160 bits for > > the key followed by a single octet representing 1 or 2 (or 0 and 1)? Here > > the answer is: we do not really know. Or, with a more optimistic twist: as > > far as we know today, this is ok. > > If you consider SHA1(k, .) as a PRF, and the input is prefix-free (that is > the > case say if the representation of 1, 2,... is made in say n octets for some > fixed > n), then results of the paper "The Cascade Construction and its Concrete > Security" > (by Hugo, Ran, and Mihir) apply. By that I mean (informally) that if you > assume > that the compression function of SHA1 makes for a good Finite-length Input > PRF, and assume some other pseudoranmness properties about the compression > function (which are also assumed in the proof of HMAC), then SHA1(k,.) makes > for a good PRF (assuming k is chosen randomly of course...). > > These are about the same assumption needed to prove that HMAC based on SHA1 > makes for a good PRF (note that I'm not talking about the proof that HMAC is > a good > MAC, which assumes that the compression function acts like a good MAC, which > is > possibly a weaker assumption). > > So I don't understand why you state that we don't really know about the > security > of such a scheme. I say we know as much about the security of SHA1(k,.) as > a PRF, with prefix-free inputs, that we know about HMAC-SHA1 on variable > inputs. > > But Hugo you are one of the authors of the paper I referred to, so you > surely have > more insight than I do, can you elaborate? Is it really just an educated > feeling you have > that makes you say that HMAC-SHA1 would be better because the inner hash > randomizes in some sense the inputs to the PRF? > > --Anton > > > > > _______________________________________________ > 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 Jul 11 16:53:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16379 for ; Fri, 11 Jul 2003 16:53:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4tI-0002Ry-Kr for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 16:53:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BKrGFe009418 for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 16:53:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4tI-0002Rp-HW for cfrg-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 16:53:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16351 for ; Fri, 11 Jul 2003 16:53:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b4tB-0002D5-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 16:53:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b4tB-0002D2-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 16:53:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4t3-0002QY-K4; Fri, 11 Jul 2003 16:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4sU-0002Pw-Ms for cfrg@optimus.ietf.org; Fri, 11 Jul 2003 16:52:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16323 for ; Fri, 11 Jul 2003 16:52:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b4sS-0002CU-00 for cfrg@ietf.org; Fri, 11 Jul 2003 16:52:24 -0400 Received: from ee.technion.ac.il ([132.68.48.5]) by ietf-mx with esmtp (Exim 4.12) id 19b4sR-0002CO-00 for cfrg@ietf.org; Fri, 11 Jul 2003 16:52:23 -0400 Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.11.6+Sun/8.10.2) with ESMTP id h6BKqsH25075; Fri, 11 Jul 2003 23:52:55 +0300 (IDT) Date: Fri, 11 Jul 2003 23:52:54 +0300 (IDT) From: Hugo Krawczyk To: "Hallam-Baker, Phillip" cc: cfrg@ietf.org Subject: RE: [Cfrg] Re: one question about hash In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2312@mou1wnexm02.verisign.com> 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: , If the extension attacks bother you can use hmac or append a key. Without entering into the specifics of your proposal, I would caution against heuristics that "seem to work" or intuitively improve a given function. Intuition is very misleading in this area. In particular, keep in mind that one main reason for the way these functions chain the intermediate results is to ensure the collision-resistance of the iterated function on the basis of the colision resistance property of the compression function (the "Merkle-Damgard Theorem"). Also this form of chaining proves useful in building a prf (or mac) out of these funtions based on the properties of the compression function. Any deviation from the original design and usage goal of these functions needs to be carefully anlyzed. We do not have strong enough ways to validate the basic design of crypto functions (except for the relative comfort given by years of cryptanalysis), but we do have a well-established methodology (via reductions) to relate the properties of a given cryptographic scheme to the (assumed) properties of the underlying cryptographic primitive. Hugo On Fri, 11 Jul 2003, Hallam-Baker, Phillip wrote: > Following on from Hugo's question This is an issue that has always troubled > me about the MD5 and SHA1 itteration functions. I would prefer it if there > was some significant difference between the itteration step and the result, > something that simply cannot be constructed from normal operation > > For example changing the way in which the chaining variables are transmitted > from one step to the next for the final iteration of the compression > function. This could be as simple as a permutation on the chaining > variables, H0' = H1, H1'= H2 etc... > > For the HTTP digest spec I put the output of the message digest through the > message digest function again concatenated with a bunch of other values as a > way to achieve this same effect. > > Even so I would prefer to see the message extension issue eliminated > entirely, I don't think it is an acceptable property for a cryptographic > primitive. > > Phill > > _______________________________________________ > 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 Jul 11 16:59:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16590 for ; Fri, 11 Jul 2003 16:59:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4yt-0003AL-EE for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 16:59:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BKx37t012163 for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 16:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4yt-0003A6-B3 for cfrg-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 16:59:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16577 for ; Fri, 11 Jul 2003 16:58:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b4yr-0002Ii-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 16:59:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b4yq-0002If-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 16:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4yq-00037m-MX; Fri, 11 Jul 2003 16:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b4y2-00036e-Ai for cfrg@optimus.ietf.org; Fri, 11 Jul 2003 16:58:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16565 for ; Fri, 11 Jul 2003 16:58:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b4y0-0002I5-00 for cfrg@ietf.org; Fri, 11 Jul 2003 16:58:08 -0400 Received: from ee.technion.ac.il ([132.68.48.5]) by ietf-mx with esmtp (Exim 4.12) id 19b4xy-0002I2-00 for cfrg@ietf.org; Fri, 11 Jul 2003 16:58:07 -0400 Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.11.6+Sun/8.10.2) with ESMTP id h6BKwfv25138; Fri, 11 Jul 2003 23:58:41 +0300 (IDT) Date: Fri, 11 Jul 2003 23:58:41 +0300 (IDT) From: Hugo Krawczyk To: Shai Halevi cc: cfrg@ietf.org Subject: Re: [Cfrg] counter mode vs feedback mode (Re: one question about hash) In-Reply-To: <200307111225.45595.shaih@watson.ibm.com> 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: , First, let's make clear that the discussion regarding the prf in "counter mode" or "feedback mode" is fully based on ineherently heuristic grounds (since no actual proof of the superiority of one over the other exists for specific constructions such as SHA1). Therefore, personal beliefs and feelings have a stronger role here than in other more "scientific" discussions. Being a skeptical person (this is what being a cryptographer means: do not trust anyone, not even yourself :) I doubt that the design tools available today for building specific functions will stand the proof of time. And if any weaknesses are eventually found in these functions it will surprise me less if they apply to closely related inputs than to randomized ones (see, for example, the MD5 case). The argument that short cycles are less studied than diffusion/mixing/avalance properties is valid if you think of "short" cycles whose size is in the order of billions (say 2^30) or more. But for a prf in "feedback mode" to go wrong in the key derivation application (which we are discussing here) you'll need to find cycles of length in the two/three-digit range at most (that's how many times you will typically apply the same function for deriving keys). If any of the prf families that we are commonly using have such super-short cycles (with non-negligible probability) then we better know about it earlier than later, so we can stop using that prf. Finally, regarding the mentioned example of MD5: what makes Dobbertin's attack against MD5 work is (surprise surprise) low hamming distance between inputs. Remarkably, his first published collision had inputs X,X' which difffer by exactly one bit... (To be fair to SHA1, its design does a much better job in dealing with close inputs by applying an expansion stage to the input; yet the example of MD5 where avalanche effects and the like were main design principles shows that it is prudent not to build too much on the perfectness of these principles.) Hugo On Fri, 11 Jul 2003, Shai Halevi wrote: > Hugo, I take issue with the following point: > > > [...] > > In addition, I personally do not like "counter mode" constructions where > > the only difference between two inputs to the function (as is the case > > with SHA1(k,1) and SHA(k,2)) is by one or two bits at most. In my opinion, > > robustness to cryptanalytical advances calls for more prudent designs. > > In this sense, HMAC has a significant contribution via its "double hashing". > > Moreover, as in the case of TLS and IKE, also here I'd recommend > > "feedback mode" for key derivation; in the above example we would have > > K1=HMAC-SHA1(k,1) and K2=HMAC-SHA1(k,K1)). > > Building blocks such as block ciphers and hash functions are explicitly > designed to be secure against "small variations" in their inputs. Indeed, > much of the work involved in the design of such primitives is to analyze > (and defend against) attacks that involve such "similar inputs". > > Hence, I feel quite confortable using these primitives in counter mode. > In fact, more confortable than using them in the "feedback mode" that you > describe. Such feedback mode may be suspetible to short cycles. Although > extremely unlikely, I view short cycles as more likely than problems with > counter mode. Simply because typically, the designers of such primitives > spend (almost) no time thinking about short cycles, but lots and lots of > time thinking about "similar inputs". > > -- Shai > > _______________________________________________ > 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 Jul 11 19:03:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23105 for ; Fri, 11 Jul 2003 19:03:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b6v6-0002lt-CJ for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 19:03:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BN3Gdf010652 for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 19:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b6v6-0002lj-8r for cfrg-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 19:03:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23074 for ; Fri, 11 Jul 2003 19:03:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b6v3-0004Cm-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 19:03:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b6v2-0004Cj-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 19:03:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b6uq-0002fh-OR; Fri, 11 Jul 2003 19:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b6uD-0002fN-Gm for cfrg@optimus.ietf.org; Fri, 11 Jul 2003 19:02:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23049 for ; Fri, 11 Jul 2003 19:02:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b6uA-0004Bx-00 for cfrg@ietf.org; Fri, 11 Jul 2003 19:02:18 -0400 Received: from email1.ballou.se ([212.214.136.50]) by ietf-mx with esmtp (Exim 4.12) id 19b6u8-0004Bm-00 for cfrg@ietf.org; Fri, 11 Jul 2003 19:02:17 -0400 Received: from streamsec.se [213.65.16.32] by email1.ballou.se with ESMTP (SMTPD32-5.05) id A1EF6AC01B8; Sat, 12 Jul 2003 01:02:07 +0200 Message-ID: <3F0F4232.9060507@streamsec.se> Date: Sat, 12 Jul 2003 01:03:14 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cfrg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA23050 Subject: [Cfrg] Seekable Encryption w secure rewrites 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I am looking for a block cipher mode that meets the following criteria: * Unpatented, or at least free for both non-commercial and commercial use * Minimal cipher text size overhead * Reasonably efficient w.r.t. execution time (approximately two times=20 ECB is OK) * Seekable in both encryption and decryption mode * No plain text leakage even if parts of the file are re-encrypted or=20 data is appended to the file and encrypted with the same key over and ove= r. This is what I have come up with so far: Encryption: for i =3D 1 to n-1 do C_i =3D E_k(i) xor E_k(P_i xor E_k(i)) -> file end for S =3D P_1 xor ... xor P_{n-1} Mac =3D E_k(E_k(S) xor E_k(0)) -> file To change block j, do the following: file -> OC_j OP_j =3D D_k(OC_j xor E_k(j)) xor E_k(j) C_j =3D E_k(P_j xor E_k(j)) xor E_k(j) -> file file -> OMac OS =3D D_k(D_k(OMac) xor E_k(0)) S =3D OS xor OP_j xor P_j Mac =3D E_k(E_k(S) xor E_k(0)) -> file This mode will reveal which parts of the file were changed during a=20 rewrite, but afaics the mode will guarantee the confidentiality and=20 integrity of each block. Comments? --=20 Henrick Hellstr=F6m, StreamSec http://www.streamsec.com Borland Technology Partner Need security enhancements for your Delphi application? Don't settle for=20 anything less than StrSecII: http://www.streamsec.com/prod_strsec2.asp _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Fri Jul 11 19:19:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23894 for ; Fri, 11 Jul 2003 19:19:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7AR-0003gl-CR for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 19:19:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BNJ7sM014180 for cfrg-archive@odin.ietf.org; Fri, 11 Jul 2003 19:19:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7AR-0003gd-7K for cfrg-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 19:19:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23861 for ; Fri, 11 Jul 2003 19:19:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b7AP-0004Vu-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 19:19:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b7AP-0004Vr-00 for cfrg-web-archive@ietf.org; Fri, 11 Jul 2003 19:19:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7AK-0003fU-L9; Fri, 11 Jul 2003 19:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b79m-0003eL-2Q for cfrg@optimus.ietf.org; Fri, 11 Jul 2003 19:18:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23838 for ; Fri, 11 Jul 2003 19:18:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b79k-0004V0-00 for cfrg@ietf.org; Fri, 11 Jul 2003 19:18:24 -0400 Received: from pigeon.verisign.com ([65.205.251.71]) by ietf-mx with esmtp (Exim 4.12) id 19b79j-0004Uv-00 for cfrg@ietf.org; Fri, 11 Jul 2003 19:18:23 -0400 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h6BNIH2Q009126; Fri, 11 Jul 2003 16:18:17 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jul 2003 16:18:17 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D231C@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Hugo Krawczyk'" , "Hallam-Baker, Phillip" Cc: cfrg@ietf.org Subject: RE: [Cfrg] Re: one question about hash Date: Fri, 11 Jul 2003 16:18:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , I am certainly not arguing for an ad hoc change to the algorithm. However I do believe that in future we should consider vulnerability to extension attacks as an unacceptable feature of a digest. Phill > -----Original Message----- > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > Sent: Friday, July 11, 2003 4:53 PM > To: Hallam-Baker, Phillip > Cc: cfrg@ietf.org > Subject: RE: [Cfrg] Re: one question about hash > > > If the extension attacks bother you can use hmac or append a key. > > Without entering into the specifics of your proposal, I would caution > against heuristics that "seem to work" or intuitively improve a given > function. Intuition is very misleading in this area. In > particular, keep > in mind that one main reason for the way these functions chain the > intermediate results is to ensure the collision-resistance of > the iterated > function on the basis of the colision resistance property of the > compression function (the "Merkle-Damgard Theorem"). Also this form of > chaining proves useful in building a prf (or mac) out of > these funtions > based on the properties of the compression function. > > Any deviation from the original design and usage goal of > these functions > needs to be carefully anlyzed. We do not have strong enough ways to > validate the basic design of crypto functions (except for the relative > comfort given by years of cryptanalysis), but we do have a > well-established methodology (via reductions) to relate the > properties of > a given cryptographic scheme to the (assumed) properties of > the underlying > cryptographic primitive. > > Hugo > > On Fri, 11 Jul 2003, Hallam-Baker, Phillip wrote: > > > Following on from Hugo's question This is an issue that has > always troubled > > me about the MD5 and SHA1 itteration functions. I would > prefer it if there > > was some significant difference between the itteration step > and the result, > > something that simply cannot be constructed from normal operation > > > > For example changing the way in which the chaining > variables are transmitted > > from one step to the next for the final iteration of the compression > > function. This could be as simple as a permutation on the chaining > > variables, H0' = H1, H1'= H2 etc... > > > > For the HTTP digest spec I put the output of the message > digest through the > > message digest function again concatenated with a bunch of > other values as a > > way to achieve this same effect. > > > > Even so I would prefer to see the message extension issue eliminated > > entirely, I don't think it is an acceptable property for a > cryptographic > > primitive. > > > > Phill > > > > _______________________________________________ > > 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 Mon Jul 14 09:41:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20312 for ; Mon, 14 Jul 2003 09:41:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3ZE-0005O3-DS for cfrg-archive@odin.ietf.org; Mon, 14 Jul 2003 09:40:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EDeaHR020702 for cfrg-archive@odin.ietf.org; Mon, 14 Jul 2003 09:40:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3ZE-0005Np-8L for cfrg-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 09:40:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20254 for ; Mon, 14 Jul 2003 09:40:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3ZC-0007c2-00 for cfrg-web-archive@ietf.org; Mon, 14 Jul 2003 09:40:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c3ZB-0007by-00 for cfrg-web-archive@ietf.org; Mon, 14 Jul 2003 09:40:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3Yf-0005MK-Iz; Mon, 14 Jul 2003 09:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c3YG-0005Ho-Gb for cfrg@optimus.ietf.org; Mon, 14 Jul 2003 09:39:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20162 for ; Mon, 14 Jul 2003 09:39:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c3YE-0007av-00 for cfrg@ietf.org; Mon, 14 Jul 2003 09:39:34 -0400 Received: from [207.61.238.66] (helo=mail.okiok.com) by ietf-mx with esmtp (Exim 4.12) id 19c3YD-0007aG-00 for cfrg@ietf.org; Mon, 14 Jul 2003 09:39:33 -0400 Received: from p1038mobile (unknown [192.168.0.63]) by mail.okiok.com (Postfix) with ESMTP id 21F90B4064; Mon, 14 Jul 2003 09:20:55 -0400 (EDT) Message-ID: <004201c34a0d$6b6f4370$3f00a8c0@p1038mobile> From: "Anton Stiglic" To: "Hallam-Baker, Phillip" , "'Hugo Krawczyk'" Cc: References: <2A1D4C86842EE14CA9BC80474919782E0D231C@mou1wnexm02.verisign.com> Subject: Re: [Cfrg] Re: one question about hash Date: Mon, 14 Jul 2003 09:39:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > However I do believe that in future we should consider vulnerability to > extension attacks as an unacceptable feature of a digest. I have to disagree. Hash functions like SHA1 were made to be hash functions, not constructions that act like a random oracle or a PRF. Cryptographic hash functions are built in a way that they are (hopefully) strongly collision resistant and one-way, so far SHA1 seems to satisfy these criterias very well, and that's all we need! The compression function of SHA1 seems to act like a good PRF on finite-length inputs, so we can use it as a MAC (via SHA1-HMAC) or as a PRF (cascade construction or HMAC), even though this wasn't it's initial intended use. The primitive we need to rely on is the compression function, and that's it! The smaller the primitive that is used is, the more confident I am since we can study it more extensively and we need to assume less when applying security proofs. For example, we don't need to assume that construction C acts like a good PRF on arbitrary inputs, we just need to assume that the subconstruction c used in C acts like a good finite-length input PRF, this is better. We don't need a hash functions that are not vulnerable to extension attacks, we just need good compression functions. --Anton ----- Original Message ----- From: "Hallam-Baker, Phillip" To: "'Hugo Krawczyk'" ; "Hallam-Baker, Phillip" Cc: Sent: Friday, July 11, 2003 7:18 PM Subject: RE: [Cfrg] Re: one question about hash > I am certainly not arguing for an ad hoc change to the algorithm. > > However I do believe that in future we should consider vulnerability to > extension attacks as an unacceptable feature of a digest. > > Phill > > > -----Original Message----- > > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > > Sent: Friday, July 11, 2003 4:53 PM > > To: Hallam-Baker, Phillip > > Cc: cfrg@ietf.org > > Subject: RE: [Cfrg] Re: one question about hash > > > > > > If the extension attacks bother you can use hmac or append a key. > > > > Without entering into the specifics of your proposal, I would caution > > against heuristics that "seem to work" or intuitively improve a given > > function. Intuition is very misleading in this area. In > > particular, keep > > in mind that one main reason for the way these functions chain the > > intermediate results is to ensure the collision-resistance of > > the iterated > > function on the basis of the colision resistance property of the > > compression function (the "Merkle-Damgard Theorem"). Also this form of > > chaining proves useful in building a prf (or mac) out of > > these funtions > > based on the properties of the compression function. > > > > Any deviation from the original design and usage goal of > > these functions > > needs to be carefully anlyzed. We do not have strong enough ways to > > validate the basic design of crypto functions (except for the relative > > comfort given by years of cryptanalysis), but we do have a > > well-established methodology (via reductions) to relate the > > properties of > > a given cryptographic scheme to the (assumed) properties of > > the underlying > > cryptographic primitive. > > > > Hugo > > > > On Fri, 11 Jul 2003, Hallam-Baker, Phillip wrote: > > > > > Following on from Hugo's question This is an issue that has > > always troubled > > > me about the MD5 and SHA1 itteration functions. I would > > prefer it if there > > > was some significant difference between the itteration step > > and the result, > > > something that simply cannot be constructed from normal operation > > > > > > For example changing the way in which the chaining > > variables are transmitted > > > from one step to the next for the final iteration of the compression > > > function. This could be as simple as a permutation on the chaining > > > variables, H0' = H1, H1'= H2 etc... > > > > > > For the HTTP digest spec I put the output of the message > > digest through the > > > message digest function again concatenated with a bunch of > > other values as a > > > way to achieve this same effect. > > > > > > Even so I would prefer to see the message extension issue eliminated > > > entirely, I don't think it is an acceptable property for a > > cryptographic > > > primitive. > > > > > > Phill > > > > > > _______________________________________________ > > > 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 _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Mon Jul 14 15:24:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18000 for ; Mon, 14 Jul 2003 15:24:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8vG-0004Ct-00 for cfrg-archive@odin.ietf.org; Mon, 14 Jul 2003 15:23:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EJNfiC016159 for cfrg-archive@odin.ietf.org; Mon, 14 Jul 2003 15:23:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8vF-0004CS-2l for cfrg-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 15:23:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17903 for ; Mon, 14 Jul 2003 15:23:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c8uv-00065G-00 for cfrg-web-archive@ietf.org; Mon, 14 Jul 2003 15:23:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c8uu-00065D-00 for cfrg-web-archive@ietf.org; Mon, 14 Jul 2003 15:23:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c8ua-00046Y-OW; Mon, 14 Jul 2003 15:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7CX-0003YR-7e for cfrg@optimus.ietf.org; Mon, 14 Jul 2003 13:33:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07213 for ; Mon, 14 Jul 2003 13:33:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7CU-0003gl-00 for cfrg@ietf.org; Mon, 14 Jul 2003 13:33:22 -0400 Received: from mailout.zetnet.co.uk ([194.247.47.231]) by ietf-mx with esmtp (Exim 4.12) id 19c7CU-0003gi-00 for cfrg@ietf.org; Mon, 14 Jul 2003 13:33:22 -0400 Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk) by mailout.zetnet.co.uk with esmtp (Exim 3.36 #1 (Debian)) id 19c7CQ-0003Lr-00 for ; Mon, 14 Jul 2003 18:33:18 +0100 Received: from iplusd.net (bts-0128.dialup.zetnet.co.uk [194.247.48.128]) by zetnet.co.uk (8.12.3/8.12.3/Debian-5.zet) with ESMTP id h6EHXFJD017791 for ; Mon, 14 Jul 2003 18:33:16 +0100 Message-ID: <3F12F618.9ADB73F7@iplusd.net> Date: Mon, 14 Jul 2003 18:27:36 +0000 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: cfrg@ietf.org Subject: Re: [Cfrg] Re: one question about hash References: <2A1D4C86842EE14CA9BC80474919782E0D231C@mou1wnexm02.verisign.com> <004201c34a0d$6b6f4370$3f00a8c0@p1038mobile> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Anton Stiglic wrote: > > > However I do believe that in future we should consider vulnerability to > > extension attacks as an unacceptable feature of a digest. > > I have to disagree. I don't. It would be quite straightforward to "fix" a digest not to have this property; if we analyse the compression function as a PRF, it only requires the inputs to the last iteration of the compression function to be disjoint from the inputs to previous iterations. This would allow the digest to be safely used directly, in some applications where less efficient constructions are currently required. For example, it could be used to directly instantiate a random oracle on variable length inputs. That is, it makes the digest more useful, at very little cost (the only cost is that the input range of the PRF has to be slightly larger than the block size). - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPxL19zkCAxeYt5gVAQGLYgf/ZhSEKr7f2Wlz4Hho5B2fUeAv+EHCDM0Y L+cklIcdCLFdgI7ehDOC9J8X2e04a/kNG5yEuA7gBXULcXfk3orcNBrX4UD40moA 4X4GW4FV+zwPJ4+b21Uv3XofX1wf0LtJeKZ/tEVTOKJWSWAW1MgTazVnzoTQqK1q JO7QZrhv56MF29Woy6kjRRuYBwlYEAOR8bCuB7xadJINLfivUEtSCO8VN4erwMhF G9LFAhfOB0o0u/QLoPpC0z4k3tdY9ZnRGeF+Kft4t22ehlTa/anzZvyXssCx3Zyz llukSs233pjTgZ8N1WDm1XVKdI1EU30hiZXd8YyNmV/5PwbUg8xfbA== =qf9b -----END PGP SIGNATURE----- _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Mon Jul 14 15:59:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21155 for ; Mon, 14 Jul 2003 15:59:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9Tb-0006dN-KI for cfrg-archive@odin.ietf.org; Mon, 14 Jul 2003 15:59:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EJxB6e025495 for cfrg-archive@odin.ietf.org; Mon, 14 Jul 2003 15:59:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9Tb-0006d8-Cs for cfrg-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 15:59:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21127 for ; Mon, 14 Jul 2003 15:59:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c9TZ-0006pt-00 for cfrg-web-archive@ietf.org; Mon, 14 Jul 2003 15:59:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c9TZ-0006pq-00 for cfrg-web-archive@ietf.org; Mon, 14 Jul 2003 15:59:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9TR-0006ah-40; Mon, 14 Jul 2003 15:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c9Si-0006W0-Da for cfrg@optimus.ietf.org; Mon, 14 Jul 2003 15:58:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21069 for ; Mon, 14 Jul 2003 15:58:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c9Sf-0006or-00 for cfrg@ietf.org; Mon, 14 Jul 2003 15:58:13 -0400 Received: from [207.61.238.66] (helo=mail.okiok.com) by ietf-mx with esmtp (Exim 4.12) id 19c9Se-0006o5-00 for cfrg@ietf.org; Mon, 14 Jul 2003 15:58:12 -0400 Received: from p1038mobile (unknown [192.168.0.63]) by mail.okiok.com (Postfix) with ESMTP id 82315B4064; Mon, 14 Jul 2003 15:39:33 -0400 (EDT) Message-ID: <013e01c34a42$51372010$3f00a8c0@p1038mobile> From: "Anton Stiglic" To: "David Hopwood" , References: <2A1D4C86842EE14CA9BC80474919782E0D231C@mou1wnexm02.verisign.com> <004201c34a0d$6b6f4370$3f00a8c0@p1038mobile> <3F12F618.9ADB73F7@iplusd.net> Subject: Re: [Cfrg] Re: one question about hash Date: Mon, 14 Jul 2003 15:58:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "David Hopwood" [...] > I don't. It would be quite straightforward to "fix" a digest not to have > this property; if we analyse the compression function as a PRF, it only > requires the inputs to the last iteration of the compression function to > be disjoint from the inputs to previous iterations. Can you give the details of your suggestion? And how it would be better than HMAC? Thanks, --Anton _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Tue Jul 15 19:01:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10472 for ; Tue, 15 Jul 2003 19:01:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cYnd-0007kI-2q for cfrg-archive@odin.ietf.org; Tue, 15 Jul 2003 19:01:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6FN1XjK029770 for cfrg-archive@odin.ietf.org; Tue, 15 Jul 2003 19:01:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cYnc-0007k5-83 for cfrg-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 19:01:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10452 for ; Tue, 15 Jul 2003 19:01:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cYnZ-0006x2-00 for cfrg-web-archive@ietf.org; Tue, 15 Jul 2003 19:01:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cYnT-0006ww-00 for cfrg-web-archive@ietf.org; Tue, 15 Jul 2003 19:01:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cYn6-0007ik-NH; Tue, 15 Jul 2003 19:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cYmM-0007hz-3l for cfrg@optimus.ietf.org; Tue, 15 Jul 2003 19:00:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10383 for ; Tue, 15 Jul 2003 19:00:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cYmI-0006wI-00 for cfrg@ietf.org; Tue, 15 Jul 2003 19:00:10 -0400 Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx with smtp (Exim 4.12) id 19cYm7-0006ss-00 for cfrg@ietf.org; Tue, 15 Jul 2003 18:59:59 -0400 Received: (qmail 32713 invoked by uid 65534); 15 Jul 2003 22:58:39 -0000 Received: from pD9E12AAC.dip.t-dialin.net (EHLO gmx.de) (217.225.42.172) by mail.gmx.net (mp015) with SMTP; 16 Jul 2003 00:58:39 +0200 Message-ID: <3F1486C8.3000706@gmx.de> Date: Wed, 16 Jul 2003 00:57:12 +0200 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030704 Debian/1.4-1 X-Accept-Language: en MIME-Version: 1.0 To: p2p-hackers@zgp.org CC: urn-nid@apps.ietf.org, thiemann@informatik.uni-freiburg.de, cfrg@ietf.org References: <3F0DC458.6090401@gmx.de> <3F1427B7.6010402@chapweske.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Cfrg] Cryptographic hashes in URNs (was: Comments on draft-thiemann-cbuid-urn-00) 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, This is a discussion about the registration of a URN namespace based on cryptographic hashes, i.e., a namespace of octet streams as identified by their hashes. Some security-related issues have (unsurprisingly) turned up, so I'm now cross-posting to three mailing lists-- - urn-nid (technical discussion of URN namespace registrations) - p2p-hackers (because one important user base would be the p2p community) - the IRTF crypto forum (to pick their minds about the security issues). I think it's appropriate in all three, but please stay strictly on topic :-) Justin Chapweske wrote: > [Peter Thiemann wrote: -bf] >> Well, I'm pretty sure that the URN scheme should *not* fix one >> particular hash function. Instead, it should be extensible so that it >> does not become obsolete just because a hash function is broken or >> somebody discovers a new super-safe or super-efficient hash function. [Later in the mail, Peter even suggested a registry for hash functions.] > I actually disagree. In order to avoid chosen-algorithm attacks, > the set of standardized hashes should be kept very small and directly > under the control of the IETF and at the guidance of the CFRG. I agree; if we have a urn:hash: namespace or similar, the list of allowable hash functions should be fixed in the namespace registration, and only be changeable by going through the RFC process. Regarding chosen-algorithm attacks, we have to keep in mind what our adversary model is. It should be noted that the hash function is picked by the person publishing a URN, not by the person a file is downloaded from. An attack using a hash collision would still be possible, but it would go more like this: - Find a hash collision, H = h(x) = h(y), x != y. - Use x to obtain some form of a "good rating" on H; this could include something like having an independent, widely trusted entity publish H as the hash of some good data, or even obtaining a signature on H. - Make y available for download with H as its id. If the URN is published by someone else than the adversary, the adversary doesn't get to choose the algorithm. > By having it as a top level URN scheme such as urn:sha1, implementors > will tend to focus on the algorithm itself rather than the notion > of generic hash-based naming. Maybe you're right. OTOH this doesn't generalize to using combinations of hash functions (more on this below). > We must avoid having a generic hash name space that allows developers > to add new hashes willy-nilly. I believe that many non crypto-savvy > developers would tend to support every algorithm specified in the > name space without understanding that by supporting multiple agorithms > you introduce a weakest-link condition. These are separate issues. Having developers add non-standard hash functions seems like a really bad idea. Supporting every function in the namespace registration may be a bad idea, but do you trust non-crypto-savvy developers to make a sensible *choice* of which algorithms to support (assuming that there *are* namespaces for different functions, including maybe md5 for backward compatibility). It should also be noted that the spec can try to educate those people that do read it. Of course there are always those that never read the spec, just use what the others use. > Also, for reasons of interoperability, it would be useful if the number > of different URNs be kept small. I agree, but what about developers who don't want to use e.g. SHA1 for technical reasons? (In particular hash size; possibly also backwards compatibility, especially if they have a running system they want to augment with URNs.) Well, maybe such developers aren't plentiful; anybody know any? (Not sure how on-topic this is for CFRG tho.) > A large number of the P2P developers have agreed upon SHA1 for the time > being, which could potentially enable very simple interoperability > between these systems. True, but there are also the two technical points against using SHA1 alone: - Many systems today use hash trees for multisource downloading. (Of course you can use a SHA1 hash tree, but that obviously doesn't give you the interoperability with plain SHA1 systems.) - Using just one function makes repair after the function is broken much more difficult (again, more below). > I also think some mechanism should be introduced to deprecate hash schemes > over time. So while urn:md5 would be a decent name space to add for > compatibility with existing MD5-based applications, such a scheme should be > immediately denoted as being deprecated to avoid having new applications > adopt MD5. Agreed. >> BF> I would suggest adding the ability to use more than one hash function >> BF> in the same URN. >> >> BF> The syntax could look for example like this: >> >> BF> urn:cbuid:md5.sha1:. >> >> That sounds like a good proposal to me, it gives you increased >> confidence and robustness virtually for free. I'll put a concrete >> syntax proposal at the end of this message. > > I don't believe this is a good idea from a security perspective. I fear that > most implementors would only verify one of the hashes, and unless they make a > judicious choice about the hash to verify, they are again opening themselves to > a chosen-algorithm attack. Otherwise, implementors w/o the proper context to > decide which hash is the strongest are forced to verify both hashes, which will > cut their hashing performance roughly in half. > > Zooko, do you have any thoughts on this? These seem like the types of attacks > that you've spent a lot of time thinking about. Zooko replied: > I *have* thought about this issue. The short of it is: I'm not sure how to do > it right, so I'm not going to do it. (I understand this as: "I'm not going to use more than a single hash function in the id.") > For example, what should the required/allowed behavior be when one of the > hashes fails to match and the matches? Are implementors required to check all > hashes that are included? My take on this is: Generally, yes. If you don't, you open yourself to a very similar attack to the one I described above regarding chosen-message attacks. Assume that two hash functions, g(.) and h(.) are in use. - Create a URN containing g(x), h(y) for x != y. - Using x, obtain an endorsement for the URN from someone who verifies only g(.). - Use the endorsement to "sell" y to someone who verifies only h(.). Yes, verifying only one of the two hashes takes longer. Well, verifying one hash takes longer than verifying zero hashes; let's specify a system without this kind of security holes. I think that using a URN which includes two hashes should be read as a statement by the URN's creator that they think verifying two hashes is reasonable. If you don't agree with them, don't resolve their URN in the first place... (I don't see why Justin thinks that verifying only one hash would introduce chosen-algorithm attacks, though. Assume that a verifier is capable of verifying both g(.) and h(.), but verifies only g(.), which happens to be insecure. I think it is reasonable to think that the verifier would also accept a URN including *only* a g(.) hash; thus, the double hash isn't necessary for the attack. And if the developer of the verifier knew that g(.) was insecure, surely they wouldn't make their program verify only g(.) in the first place. Maybe someone can enlighten me on chosen-algorithm attacks made possible by using two functions.) The one exception I would make to having to verify both hashes is when the verifier doesn't have an implementation of both hash functions. In these cases, I would say that an implementation MAY reject the URN, but if it does not, it SHOULD provide an indication to the user that the verifier cannot guarantee that everybody else will see the same file behind this URN as given. The verifier could also provide an alternative URN where this *can* be guaranteed (i.e., one containing only one hash). > I suspect that there might be a way to do secure, smooth, backwards- > compatible upgrade past certain kinds of hash algorithm breakages. However, > I haven't seen a complete description of how it would work. Ok. I assume that you mean, a way to continue to use identifiers even after the hash functions used in these identifiers are all broken. For the following, you have to have a secure timestamping service. Assume that your identifiers include two hashes, using g(.) and h(.). Assume that g(.) is broken, but h(.) still works. Assume that you have decided upon a new hash function, i(.), which you will in the future use together with h(.). For every file x where you have the contents, not just the hash, you can: - Compute h(x) and i(x). - Timestamp the statement: "H = h(x) and I = i(x) are hashes of the same file." Now suppose that h(.) is broken, but i(.) still works. Assume that you have an old-style identifier containing g(x) and h(x). Assume that you have downloaded y, an alleged copy of x; you want to verify it against the identifier containing G = g(x) and H2 = h(x). You have the timestamp certificate of the above statement. You now verify that g(y) = G; h(y) = H = H2; and i(y) = I. If this holds, you can be sure that y = x. Proof: Assume that y != x. We know that h(y) = h(x). That's not something big; at the time of verification, we know ways of computing collisions for h(.). However, the timestamped statement contains I = i(y). At the time of verification, it is believed that nobody can obtain hash collisions on i(.). Therefore, at the time of verification, the adversary must have used y to compute i(y), or, alternatively, created a timestamp for every possible value of i(.). Since timestamping involves hashing, creating a timestamp for every possible value of i(.) requires at least as much computing power as mounting a birthday attack on the function used, which is held to be impossible. Thus, someone has intentionally associated h(x) with i(y), and thus y. To know that it makes sense to associate h(x) with y, the person must have known, at the time, that h(x) = h(y). Therefore, if y != x, then someone must have known that h(x) = h(y), **at a time where no way to compute a hash collision on h(.) was known, yet**. This is held to be impossible; thus, y = x, q.e.d. Does this satisfy you? Note that you cannot use the above in a system using only one hash function-- because once your hash function breaks, your timestamps, using that hash function, break as well! At every time, you need at least one hash function that remains unbroken. I should also note that the above idea is patented in the US and probably elsewhere. However, patents expire (this one in the 2010s, I think), and this is long-term thinking. > (The algorithm-negotiation features of SSL/TLS might be considered an example > of what *not* to do, and in any case they cannot be carried over to this > application since they are interactive.) Yup and yup. (Some protocols may use hash URNs as return values and may include algorithm negotiation, but that would be a security issue with those protocols, not with the hash URN spec.) We can of course use a different URN namespace identifier for each hash function, i.e., urn:sha1:... A point in favor of this would be that people use it already. I'm not sure how this interacts with using different hashes in a single URN, though. I think there should be a method to do so, in order to enable the lifetime extension as described above, and in order to combine 'industry standard' SHA-1 hashes with a tree hash that enables multisource downloading. I think that the specification should probably say that an implementation must check all hashes, except at explicit user discretion. I think that if an an application does check all hashes, there are no security considerations with using more than one hash. OTOH there are security benefits-- if only that birthday attacks become harder to mount because of the additional bits. The question then is, if we allow e.g. {sha1,sha256,tiger} each by itself, do we also allow every possible combination of the above? Or do we limit ourselves to a specified set of combinations, e.g. sha1+tiger but not sha1+sha256? I believe that there is no security gain from allowing the former but disallowing the latter. OTOH I could easily imagine that if sha1+tiger is popular, some people would like to use sha1+tiger+sha256 for added security. There is the issue of having less URNs per resource, of course, which is outside the security domain I think. I'm not sure how much a concern this is... opinions? If we allow all possible subsets, using URN namespace names becomes problematic; we'd have to register urn:sha1:... urn:sha256:... urn:tiger:... urn:sha1+sha256:... urn:sha1+tiger:... urn:sha256+tiger:... urn:sha1+sha256+tiger:... (urks). Or, we'd have to do something like, use urn:sha1:... for just one hash but urn:hashes:sha1+sha256:... for more than one hash. Then, we'd only have to register urn:sha1:... urn:sha256:... urn:tiger:... urn:hashes:... Opinions? Thanks, - Benja _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Tue Jul 15 20:15:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11998 for ; Tue, 15 Jul 2003 20:15:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cZwv-0002Q2-L4 for cfrg-archive@odin.ietf.org; Tue, 15 Jul 2003 20:15:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G0FDV3009297 for cfrg-archive@odin.ietf.org; Tue, 15 Jul 2003 20:15:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cZwv-0002Ps-Fd for cfrg-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 20:15:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11972 for ; Tue, 15 Jul 2003 20:15:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cZwt-0007SZ-00 for cfrg-web-archive@ietf.org; Tue, 15 Jul 2003 20:15:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cZwn-0007SW-00 for cfrg-web-archive@ietf.org; Tue, 15 Jul 2003 20:15:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cZwj-0002Oa-CC; Tue, 15 Jul 2003 20:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cZvk-0002Lz-I9 for cfrg@optimus.ietf.org; Tue, 15 Jul 2003 20:14:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11939 for ; Tue, 15 Jul 2003 20:13:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cZvi-0007Pf-00 for cfrg@ietf.org; Tue, 15 Jul 2003 20:13:58 -0400 Received: from onionnetworks.com ([207.195.206.201] helo=open-content.net) by ietf-mx with smtp (Exim 4.12) id 19cZvX-0007P3-00 for cfrg@ietf.org; Tue, 15 Jul 2003 20:13:47 -0400 Received: (qmail 31892 invoked from network); 16 Jul 2003 00:13:13 -0000 Received: from c-24-118-168-87.mn.client2.attbi.com (HELO chapweske.com) (24.118.168.87) by onionnetworks.com with SMTP; 16 Jul 2003 00:13:13 -0000 Message-ID: <3F14989C.2020501@chapweske.com> Date: Tue, 15 Jul 2003 19:13:16 -0500 From: Justin Chapweske User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: p2p-hackers@zgp.org CC: urn-nid@apps.ietf.org, thiemann@informatik.uni-freiburg.de, cfrg@ietf.org References: <3F0DC458.6090401@gmx.de> <3F1427B7.6010402@chapweske.com> <3F1486C8.3000706@gmx.de> In-Reply-To: <3F1486C8.3000706@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Cfrg] Re: [p2p-hackers] Cryptographic hashes in URNs 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > A large number of the P2P developers have agreed upon SHA1 for the time > > being, which could potentially enable very simple interoperability > >> between these systems. > > > True, but there are also the two technical points against using SHA1 alone: > > - Many systems today use hash trees for multisource downloading. (Of > course you can use a SHA1 hash tree, but that obviously doesn't give you > the interoperability with plain SHA1 systems.) > - Using just one function makes repair after the function is broken much > more difficult (again, more below). > As they are defined today (http://open-content.net/specs/draft-jchapweske-thex-02.html), the tree hashes are parametizable to allow different file segment (leaf) sizes to be specified. IFAIK other traditional digest algorithms are set in stone, allowing no parameterization(?). If appropriate, I would be interested in certain hash tree forms being validated and standardized as normal digest functions. This would allow hash tree forms to be incorporated into existing standards that rely on a normal digest function. In regards to using multiple functions, most current systems that output multiple functions simply output them as multiple seperate pieces of metadata. For instance, a system could output something like the following: X-Content-URN: urn:sha1:FAB6CX2GZSWOOWCPXXBYSFBUSN4LIGTF X-Content-URN: urn:tree:tiger:3FOBMWPE2JED5DUN2VA6J7DGSNJNJILE4HRF6SQ I believe that in many systems the hashes will simply be treated as pieces of meta-data that are used to verify the integrity of a file. Just because they contain 'urn' in them doesn't mean that they have to be used as identifiers. So, if you look at it from the meta-data perspective, I think its natural to use multiple independant hashes rather them glomming them all together. > (I don't see why Justin thinks that verifying only one hash would > introduce chosen-algorithm attacks, though. Assume that a verifier is > capable of verifying both g(.) and h(.), but verifies only g(.), which > happens to be insecure. I think it is reasonable to think that the > verifier would also accept a URN including *only* a g(.) hash; thus, the > double hash isn't necessary for the attack. And if the developer of the > verifier knew that g(.) was insecure, surely they wouldn't make their > program verify only g(.) in the first place. Maybe someone can enlighten > me on chosen-algorithm attacks made possible by using two functions.) My point is subtle and perhaps irrelevant, but let me try to clarify: When I see something like: urn:hash:sha1.md5: This implies to me that I am obligated (not sure to whom) to verify both hashes. I believe these semantics are reasonable, however you will find very few developers will be willing to follow these semantics and verify both hashes. However, when I see something like: X-Content-URN: urn:md5:42J46YB3Y3OLLFYL52B4LNDE34 X-Content-URN: urn:sha1:FAB6CX2GZSWOOWCPXXBYSFBUSN4LIGTF X-Content-URN: urn:tree:tiger:3FOBMWPE2JED5DUN2VA6J7DGSNJNJILE4HRF6SQ X-Content-URN: urn:crc32: This implies to me that I should apply some sort of ranking between the algorithms and not use any that are below my standards. If I am not confident about any single hash, I am free to verify multiple of them. Obviously from a technical perspective, both approaches are the same, it just seems to me that the first approach invites developers to defy the semantics, while the second approach is likely to be a healthier approach. I am not a developer psychologist, so I'm very open to other viewpoints on this. -- Justin Chapweske, Onion Networks http://onionnetworks.com/ _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Tue Jul 15 21:06:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12998 for ; Tue, 15 Jul 2003 21:06:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cakM-0004Yy-Et for cfrg-archive@odin.ietf.org; Tue, 15 Jul 2003 21:06:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6G16It8017536 for cfrg-archive@odin.ietf.org; Tue, 15 Jul 2003 21:06:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cakK-0004XI-Us for cfrg-web-archive@optimus.ietf.org; Tue, 15 Jul 2003 21:06:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12984 for ; Tue, 15 Jul 2003 21:06:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cakH-00001e-00 for cfrg-web-archive@ietf.org; Tue, 15 Jul 2003 21:06:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cakB-00001b-00 for cfrg-web-archive@ietf.org; Tue, 15 Jul 2003 21:06:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cak4-0004UQ-KP; Tue, 15 Jul 2003 21:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cajD-0004U1-1G for cfrg@optimus.ietf.org; Tue, 15 Jul 2003 21:05:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12965 for ; Tue, 15 Jul 2003 21:05:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cajA-00000y-00 for cfrg@ietf.org; Tue, 15 Jul 2003 21:05:04 -0400 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx with smtp (Exim 4.12) id 19caiz-00000b-00 for cfrg@ietf.org; Tue, 15 Jul 2003 21:04:53 -0400 Received: (qmail 30279 invoked by uid 65534); 16 Jul 2003 01:03:52 -0000 Received: from pD9E12AAC.dip.t-dialin.net (EHLO gmx.de) (217.225.42.172) by mail.gmx.net (mp021) with SMTP; 16 Jul 2003 03:03:52 +0200 Message-ID: <3F14A421.5010502@gmx.de> Date: Wed, 16 Jul 2003 03:02:25 +0200 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030704 Debian/1.4-1 X-Accept-Language: en MIME-Version: 1.0 To: p2p-hackers@zgp.org CC: urn-nid@apps.ietf.org, thiemann@informatik.uni-freiburg.de, cfrg@ietf.org References: <3F0DC458.6090401@gmx.de> <3F1427B7.6010402@chapweske.com> <3F1486C8.3000706@gmx.de> <3F14989C.2020501@chapweske.com> In-Reply-To: <3F14989C.2020501@chapweske.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Cfrg] Re: [p2p-hackers] Cryptographic hashes in URNs 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Justin Chapweske wrote: > If appropriate, I would be interested in certain hash tree forms being > validated and standardized as normal digest functions. This would allow > hash tree forms to be incorporated into existing standards that rely on > a normal digest function. Seems appropriate to me. > In regards to using multiple functions, most current systems that output > multiple functions simply output them as multiple seperate pieces of > metadata. For instance, a system could output something like the > following: > > X-Content-URN: urn:sha1:FAB6CX2GZSWOOWCPXXBYSFBUSN4LIGTF > X-Content-URN: urn:tree:tiger:3FOBMWPE2JED5DUN2VA6J7DGSNJNJILE4HRF6SQ > > I believe that in many systems the hashes will simply be treated as > pieces of meta-data that are used to verify the integrity of a file. > Just because they contain 'urn' in them doesn't mean that they have to > be used as identifiers. So, if you look at it from the meta-data > perspective, I think its natural to use multiple independant hashes > rather them glomming them all together. Well, I use them as context-less names that resolve to something; and you simply cannot give two different URNs in one . If you use them as metadata about a different resource, then I agree you don't need to put different hashes into a single URN. (OTOH, if you go the other way around, and want to give RDF metadata about a resource identified by a hash-URN-- e.g., ratings or locations--, there are good reasons for using a URN with more than one hash again, so that the resource name you store information about doesn't need to become invalid if one hash function is broken.) >> (I don't see why Justin thinks that verifying only one hash would >> introduce chosen-algorithm attacks, though. Assume that a verifier is >> capable of verifying both g(.) and h(.), but verifies only g(.), which >> happens to be insecure. I think it is reasonable to think that the >> verifier would also accept a URN including *only* a g(.) hash; thus, >> the double hash isn't necessary for the attack. And if the developer >> of the verifier knew that g(.) was insecure, surely they wouldn't make >> their program verify only g(.) in the first place. Maybe someone can >> enlighten me on chosen-algorithm attacks made possible by using two >> functions.) > > My point is subtle and perhaps irrelevant, but let me try to clarify: > > When I see something like: > > urn:hash:sha1.md5: > > This implies to me that I am obligated (not sure to whom) to verify both > hashes. I believe these semantics are reasonable, however you will find > very few developers will be willing to follow these semantics and verify > both hashes. I dunno... if the spec explains how this is a security leak, and the developers still do it, I think there's little I can do... > However, when I see something like: > > X-Content-URN: urn:md5:42J46YB3Y3OLLFYL52B4LNDE34 > X-Content-URN: urn:sha1:FAB6CX2GZSWOOWCPXXBYSFBUSN4LIGTF > X-Content-URN: urn:tree:tiger:3FOBMWPE2JED5DUN2VA6J7DGSNJNJILE4HRF6SQ > X-Content-URN: urn:crc32: > > This implies to me that I should apply some sort of ranking between the > algorithms and not use any that are below my standards. If I am not > confident about any single hash, I am free to verify multiple of them. I would actually agree with your assessments of the meaning of both statements -- the first implies you have to verify both, the second implies you have to verify as many as you deem necessary. So your point is: Because many developers will-- maybe-- use the second kind of semantics always, having the form aiming for the first kind of semantics is futile. I need the first kind of semantics, though, if I want to use hash URNs as reliable, trusted, *context-less* identifiers. (I.e., without being able to give more than one URN in an .) I think having a way to convey these semantics would be good, even if some people will implement it in an insecure way. Seems to me like this is generally useful where people use URNs for identifiers. I mean, when I post a URN in a forum, giving two URNs seems less practical and posting a number of URNs and saying "Download as many of these as you need to meet your security requirements, and verify that they are all equal" seems weird. :-) You should click on it and your software should handle the rest. My current thinking is that if the spec explains in which way verifying only one hash is a security leak, and if developers still do it, then it's an issue between the developers and their users-- if the users and developers are willing to accept the security leak of having somebody recommend a URN they haven't fully checked, then that's their problem, I'd think. - Benja _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Wed Jul 16 11:10:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05429 for ; Wed, 16 Jul 2003 11:10:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnv4-0000nP-IC for cfrg-archive@odin.ietf.org; Wed, 16 Jul 2003 11:10:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GFAE97003055 for cfrg-archive@odin.ietf.org; Wed, 16 Jul 2003 11:10:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnv4-0000nC-1r for cfrg-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 11:10:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05426 for ; Wed, 16 Jul 2003 11:10:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cnv1-0000L0-00 for cfrg-web-archive@ietf.org; Wed, 16 Jul 2003 11:10:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cnuv-0000Kx-00 for cfrg-web-archive@ietf.org; Wed, 16 Jul 2003 11:10:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnuq-0000m8-PA; Wed, 16 Jul 2003 11:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cnuG-0000li-Nr for cfrg@optimus.ietf.org; Wed, 16 Jul 2003 11:09:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05400 for ; Wed, 16 Jul 2003 11:09:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cnuE-0000Kn-00 for cfrg@ietf.org; Wed, 16 Jul 2003 11:09:22 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 19cnu3-0000JR-00 for cfrg@ietf.org; Wed, 16 Jul 2003 11:09:11 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h6GF45d26515; Wed, 16 Jul 2003 15:04:05 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with ESMTP id h6GEVII27116; Wed, 16 Jul 2003 14:31:18 GMT Received: from cellison-mobl ([134.134.40.119]) by nwlxmail01.jf.intel.com (8.12.9/8.12.9/MailSET/Hub) with SMTP id h6GF69vl012306; Wed, 16 Jul 2003 08:06:09 -0700 Message-Id: <3.0.5.32.20030716080607.018df0c8@mailbox.jf.intel.com> X-Sender: cme@mailbox.jf.intel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 16 Jul 2003 08:06:07 -0700 To: Benja Fallenstein From: Carl Ellison Subject: Re: [Cfrg] Cryptographic hashes in URNs (was: Comments on draft-thiemann-cbuid-urn-00) Cc: p2p-hackers@zgp.org, urn-nid@apps.ietf.org, thiemann@informatik.uni-freiburg.de, cfrg@ietf.org In-Reply-To: <3F1486C8.3000706@gmx.de> References: <3F0DC458.6090401@gmx.de> <3F1427B7.6010402@chapweske.com> 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: , -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benja, I apparently don't know the rules for URN formation. I thought it was completely free after the "urn:". Is that not true? I'm skipping most of this conversation, to comment on a single point at the end.. Is urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8= not now legal? At 12:57 AM 7/16/2003 +0200, Benja Fallenstein wrote: >If we allow all possible subsets, using URN namespace names becomes >problematic; we'd have to register > > urn:sha1:... > urn:sha256:... > urn:tiger:... > urn:sha1+sha256:... > urn:sha1+tiger:... > urn:sha256+tiger:... > urn:sha1+sha256+tiger:... > >(urks). Or, we'd have to do something like, use urn:sha1:... for >just one hash but urn:hashes:sha1+sha256:... for more than one >hash. Then, we'd only have to register > > urn:sha1:... > urn:sha256:... > urn:tiger:... > urn:hashes:... > >Opinions? When you combine hash functions, you need to specify the combining function also. I assume you were assuming mere concatenation, here. It's often more than that. So, the concatenation function would have to be listed also. My personal preference is for anyone who wants to do this to declare a new hash function name and define it as the particular combination function of the particular other hash functions, but use that new hash function name in things like the URN construct. We've seen a couple of these, but not very many and I don't see a reason to encourage people to do this kind of concatenation. - Carl -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBPxVp38xqBGb+WvJAEQJWqQCeNMYjkGsZgVJ+AdxGD4qC9nApCWEAnjlm BVlE+QHYq0g1jzd1rXJdfKgO =pvcn -----END PGP SIGNATURE----- +--------------------------------------------------------+ |Carl Ellison Intel R & D E: cme@jf.intel.com | |2111 NE 25th Ave T: +1-503-264-2900 | |Hillsboro OR 97124 F: +1-503-264-3375 | |PGP Key ID: 0xFE5AF240 | | 1FDB 2770 08D7 8540 E157 AAB4 CC6A 0466 FE5A F240 | +--------------------------------------------------------+ _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Wed Jul 16 11:39:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06340 for ; Wed, 16 Jul 2003 11:39:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coN6-0002WP-LD for cfrg-archive@odin.ietf.org; Wed, 16 Jul 2003 11:39:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GFdClG009687 for cfrg-archive@odin.ietf.org; Wed, 16 Jul 2003 11:39:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coN5-0002Vm-4y for cfrg-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 11:39:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06320 for ; Wed, 16 Jul 2003 11:39:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coN4-0000a0-00 for cfrg-web-archive@ietf.org; Wed, 16 Jul 2003 11:39:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19coMy-0000Zx-00 for cfrg-web-archive@ietf.org; Wed, 16 Jul 2003 11:39:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coMu-0002SO-NC; Wed, 16 Jul 2003 11:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19coMR-0002Rw-Aw for cfrg@optimus.ietf.org; Wed, 16 Jul 2003 11:38:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06296 for ; Wed, 16 Jul 2003 11:38:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19coMQ-0000Zb-00 for cfrg@ietf.org; Wed, 16 Jul 2003 11:38:30 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx with smtp (Exim 4.12) id 19coMF-0000ZL-00 for cfrg@ietf.org; Wed, 16 Jul 2003 11:38:19 -0400 Received: (qmail 12150 invoked by uid 65534); 16 Jul 2003 15:37:18 -0000 Received: from pD9E12BA5.dip.t-dialin.net (EHLO gmx.de) (217.225.43.165) by mail.gmx.net (mp027) with SMTP; 16 Jul 2003 17:37:18 +0200 Message-ID: <3F1570D6.8080601@gmx.de> Date: Wed, 16 Jul 2003 17:35:50 +0200 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030704 Debian/1.4-1 X-Accept-Language: en MIME-Version: 1.0 To: Carl Ellison CC: p2p-hackers@zgp.org, urn-nid@apps.ietf.org, thiemann@informatik.uni-freiburg.de, cfrg@ietf.org Subject: Re: [Cfrg] Cryptographic hashes in URNs References: <3F0DC458.6090401@gmx.de> <3F1427B7.6010402@chapweske.com> <3.0.5.32.20030716080607.018df0c8@mailbox.jf.intel.com> In-Reply-To: <3.0.5.32.20030716080607.018df0c8@mailbox.jf.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Carl, Carl Ellison wrote: > I apparently don't know the rules for URN formation. I thought it > was completely free after the "urn:". Is that not true? No. After the "urn:" comes a "namespace identifier," a colon, and a "namespace-specific string," i.e. urn:: Assignment of namespace ids is a manged process, i.e., you cannot just create your own, you have to register it with the IETF. Normally this requires an RFC. The namespace registration explains how the namespace-specific string is interpreted. For more info, see RFCs 2141 and 3406. The official registry of namespace ids is at: http://www.iana.org/assignments/urn-namespaces > Is urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8= not now legal? No, since there is no registered 'sha1' namespace. > At 12:57 AM 7/16/2003 +0200, Benja Fallenstein wrote: >> urn:sha1:... >> urn:sha256:... >> urn:tiger:... >> urn:sha1+sha256:... >> urn:sha1+tiger:... >> urn:sha256+tiger:... >> urn:sha1+sha256+tiger:... [...] >>Opinions? > > When you combine hash functions, you need to specify the combining > function also. I assume you were assuming mere concatenation, here. > It's often more than that. So, the concatenation function would have > to be listed also. Hm, can you explain what else would be needed? Do we really need other combinations than concatenation in URNs-- what would be the applications? (I'm not familiar with other ways in which you would want to combine hash functions.) > My personal preference is for anyone who wants to do this to declare > a new hash function name and define it as the particular combination > function of the particular other hash functions, but use that new > hash function name in things like the URN construct. We've seen a > couple of these, but not very many and I don't see a reason to > encourage people to do this kind of concatenation. Hm. Maybe you're right. My one point against this would be that if you use urn:sha1.tigertree:... it's easier for a developer who supports only SHA-1 to realize that they can provide at least partial verification than it is if you use urn:bitprint:... and define 'bitprint' as, 'SHA-1 concatenated with a Tiger tree-hash.' But I think I'd be fine with the latter, if it is consensus. - Benja _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Wed Jul 16 13:17:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09039 for ; Wed, 16 Jul 2003 13:17:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cptj-0008Cp-Cr for cfrg-archive@odin.ietf.org; Wed, 16 Jul 2003 13:16:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GHGxCp031537 for cfrg-archive@odin.ietf.org; Wed, 16 Jul 2003 13:16:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cptj-0008Ca-8G for cfrg-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 13:16:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09009 for ; Wed, 16 Jul 2003 13:16:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cptc-0001Kj-00 for cfrg-web-archive@ietf.org; Wed, 16 Jul 2003 13:16:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cptC-0001KV-00 for cfrg-web-archive@ietf.org; Wed, 16 Jul 2003 13:16:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cpsn-00088B-QY; Wed, 16 Jul 2003 13:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cpsA-00082M-Jq for cfrg@optimus.ietf.org; Wed, 16 Jul 2003 13:15:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08969 for ; Wed, 16 Jul 2003 13:15:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cps3-0001K6-00 for cfrg@ietf.org; Wed, 16 Jul 2003 13:15:15 -0400 Received: from onionnetworks.com ([207.195.206.201] helo=open-content.net) by ietf-mx with smtp (Exim 4.12) id 19cprd-0001HL-00 for cfrg@ietf.org; Wed, 16 Jul 2003 13:14:49 -0400 Received: (qmail 2729 invoked from network); 16 Jul 2003 17:12:35 -0000 Received: from c-24-118-168-87.mn.client2.attbi.com (HELO chapweske.com) (24.118.168.87) by onionnetworks.com with SMTP; 16 Jul 2003 17:12:35 -0000 Message-ID: <3F158787.6020902@chapweske.com> Date: Wed, 16 Jul 2003 12:12:39 -0500 From: Justin Chapweske User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carl Ellison CC: Benja Fallenstein , p2p-hackers@zgp.org, urn-nid@apps.ietf.org, thiemann@informatik.uni-freiburg.de, cfrg@ietf.org Subject: Re: [Cfrg] Cryptographic hashes in URNs References: <3F0DC458.6090401@gmx.de> <3F1427B7.6010402@chapweske.com> <3.0.5.32.20030716080607.018df0c8@mailbox.jf.intel.com> In-Reply-To: <3.0.5.32.20030716080607.018df0c8@mailbox.jf.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I'm skipping most of this conversation, to comment on a single point > at the end.. > > Is urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8= not now legal? > The sha1 urn scheme is not yet registered, but its de facto usage utilizes a Base32 encoding, not Base64. -- Justin Chapweske, Onion Networks http://onionnetworks.com/ _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Wed Jul 16 13:37:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09695 for ; Wed, 16 Jul 2003 13:37:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqDL-0000hp-2H for cfrg-archive@odin.ietf.org; Wed, 16 Jul 2003 13:37:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GHbFKt002707 for cfrg-archive@odin.ietf.org; Wed, 16 Jul 2003 13:37:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqDK-0000hS-OA for cfrg-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 13:37:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09659 for ; Wed, 16 Jul 2003 13:37:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cqDI-0001Uq-00 for cfrg-web-archive@ietf.org; Wed, 16 Jul 2003 13:37:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cqDC-0001Un-00 for cfrg-web-archive@ietf.org; Wed, 16 Jul 2003 13:37:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqD8-0000bO-5W; Wed, 16 Jul 2003 13:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqCz-0000aL-6H for cfrg@optimus.ietf.org; Wed, 16 Jul 2003 13:36:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09648 for ; Wed, 16 Jul 2003 13:36:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cqCx-0001UX-00 for cfrg@ietf.org; Wed, 16 Jul 2003 13:36:51 -0400 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by ietf-mx with smtp (Exim 4.12) id 19cqCm-0001Th-00 for cfrg@ietf.org; Wed, 16 Jul 2003 13:36:40 -0400 Received: (qmail 8592 invoked by uid 65534); 16 Jul 2003 17:34:03 -0000 Received: from pD9E12BA5.dip.t-dialin.net (EHLO gmx.de) (217.225.43.165) by mail.gmx.net (mp012) with SMTP; 16 Jul 2003 19:34:03 +0200 Message-ID: <3F158C33.4070604@gmx.de> Date: Wed, 16 Jul 2003 19:32:35 +0200 From: Benja Fallenstein User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030704 Debian/1.4-1 X-Accept-Language: en MIME-Version: 1.0 To: p2p-hackers@zgp.org CC: Carl Ellison , urn-nid@apps.ietf.org, thiemann@informatik.uni-freiburg.de, cfrg@ietf.org Subject: Re: [p2p-hackers] Re: [Cfrg] Cryptographic hashes in URNs References: <3F0DC458.6090401@gmx.de> <3F1427B7.6010402@chapweske.com> <3.0.5.32.20030716080607.018df0c8@mailbox.jf.intel.com> <3F158787.6020902@chapweske.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Zooko, Zooko wrote: > Coincidentally, there is an active (and contentious) discussion of > cryptography-based naming at the "cryptography" mailing list. > > Three different concrete proposals, including one already deployed and one > newly announced, have been mentioned. Is there an archive? > majordomo@wasabisystems.com "subscribe cryptography" gives: **** subscribe: unknown list 'cryptography'. - Benja _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Wed Jul 16 13:53:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10374 for ; Wed, 16 Jul 2003 13:53:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqSm-0001xZ-LE for cfrg-archive@odin.ietf.org; Wed, 16 Jul 2003 13:53:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GHrC7G007501 for cfrg-archive@odin.ietf.org; Wed, 16 Jul 2003 13:53:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqSm-0001wK-Gw for cfrg-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 13:53:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10364 for ; Wed, 16 Jul 2003 13:53:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cqSk-0001ex-00 for cfrg-web-archive@ietf.org; Wed, 16 Jul 2003 13:53:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cqSe-0001eu-00 for cfrg-web-archive@ietf.org; Wed, 16 Jul 2003 13:53:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqSb-0001um-9O; Wed, 16 Jul 2003 13:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cqRf-0001u9-Ji for cfrg@optimus.ietf.org; Wed, 16 Jul 2003 13:52:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10340 for ; Wed, 16 Jul 2003 13:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cqRd-0001eI-00 for cfrg@ietf.org; Wed, 16 Jul 2003 13:52:01 -0400 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19cqRS-0001dj-00 for cfrg@ietf.org; Wed, 16 Jul 2003 13:51:50 -0400 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h6GI5oJh021096; Wed, 16 Jul 2003 14:05:50 -0400 Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h6GHoZV26619; Wed, 16 Jul 2003 13:50:35 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 23A027B4D; Wed, 16 Jul 2003 19:50:34 +0200 (CEST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Benja Fallenstein Cc: p2p-hackers@zgp.org, Carl Ellison , urn-nid@apps.ietf.org, thiemann@informatik.uni-freiburg.de, cfrg@ietf.org Subject: Re: [p2p-hackers] Re: [Cfrg] Cryptographic hashes in URNs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 2003 19:50:34 +0200 From: "Steven M. Bellovin" Message-Id: <20030716175034.23A027B4D@berkshire.research.att.com> 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: , In message <3F158C33.4070604@gmx.de>, Benja Fallenstein writes: > >Hi Zooko, > >Zooko wrote: >> Coincidentally, there is an active (and contentious) discussion of >> cryptography-based naming at the "cryptography" mailing list. >> >> Three different concrete proposals, including one already deployed and one >> newly announced, have been mentioned. > >Is there an archive? > >> majordomo@wasabisystems.com > >"subscribe cryptography" gives: >**** subscribe: unknown list 'cryptography'. It's now at metzdowd.com --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Wed Jul 16 18:56:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21965 for ; Wed, 16 Jul 2003 18:56:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cvC5-0003zB-FP for cfrg-archive@odin.ietf.org; Wed, 16 Jul 2003 18:56:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GMuHOU015315 for cfrg-archive@odin.ietf.org; Wed, 16 Jul 2003 18:56:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cvC5-0003yw-4c for cfrg-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 18:56:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21948 for ; Wed, 16 Jul 2003 18:56:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cvC1-0004OM-00 for cfrg-web-archive@ietf.org; Wed, 16 Jul 2003 18:56:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19cvBv-0004OJ-00 for cfrg-web-archive@ietf.org; Wed, 16 Jul 2003 18:56:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cvBq-0003wZ-8V; Wed, 16 Jul 2003 18:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cq4c-00008L-67 for cfrg@optimus.ietf.org; Wed, 16 Jul 2003 13:28:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09315 for ; Wed, 16 Jul 2003 13:28:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cq4a-0001OJ-00 for cfrg@ietf.org; Wed, 16 Jul 2003 13:28:12 -0400 Received: from vorpal.notabug.com ([63.149.73.20] ident=qmailr) by ietf-mx with smtp (Exim 4.12) id 19cq4P-0001No-00 for cfrg@ietf.org; Wed, 16 Jul 2003 13:28:01 -0400 Received: (qmail 17255 invoked from network); 16 Jul 2003 17:26:59 -0000 Received: (ofmipd 64.231.177.197); 16 Jul 2003 17:26:37 -0000 Received: from localhost ([127.0.0.1] helo=zooko.com) by localhost with esmtp (Exim 3.36 #1 (Debian)) id 19cq2G-0008Uh-00; Wed, 16 Jul 2003 13:25:48 -0400 Date: 16 Jul 2003 13:25:48 -0400 Message-Id: From: "Zooko" To: p2p-hackers@zgp.org Cc: "Carl Ellison" , "Benja Fallenstein" , urn-nid@apps.ietf.org, thiemann@informatik.uni-freiburg.de, cfrg@ietf.org Subject: Re: [p2p-hackers] Re: [Cfrg] Cryptographic hashes in URNs In-Reply-To: Message from Justin Chapweske of "Wed, 16 Jul 2003 12:12:39 CDT." <3F158787.6020902@chapweske.com> References: <3F0DC458.6090401@gmx.de> <3F1427B7.6010402@chapweske.com> <3.0.5.32.20030716080607.018df0c8@mailbox.jf.intel.com> <3F158787.6020902@chapweske.com> 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: , Coincidentally, there is an active (and contentious) discussion of cryptography-based naming at the "cryptography" mailing list. Three different concrete proposals, including one already deployed and one newly announced, have been mentioned. majordomo@wasabisystems.com _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Mon Jul 21 13:19:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04366 for ; Mon, 21 Jul 2003 13:19:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eeJ6-0005ZV-F6 for cfrg-archive@odin.ietf.org; Mon, 21 Jul 2003 13:18:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LHIejC021411 for cfrg-archive@odin.ietf.org; Mon, 21 Jul 2003 13:18:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eeJ4-0005Z0-Gb for cfrg-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 13:18:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04267 for ; Mon, 21 Jul 2003 13:15:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eeFq-0004mp-00 for cfrg-web-archive@ietf.org; Mon, 21 Jul 2003 13:15:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eeFk-0004mY-00 for cfrg-web-archive@ietf.org; Mon, 21 Jul 2003 13:15:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eeFZ-0005Kz-5K; Mon, 21 Jul 2003 13:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eJFT-0006zv-Hf for cfrg@optimus.ietf.org; Sun, 20 Jul 2003 14:49:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24339 for ; Sun, 20 Jul 2003 14:49:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eJFQ-0004Rg-00 for cfrg@ietf.org; Sun, 20 Jul 2003 14:49:28 -0400 Received: from fia224-72.dsl.hccnet.nl ([62.251.72.224] helo=foem.leiden.webweaving.org ident=chuck) by ietf-mx with esmtp (Exim 4.12) id 19eJFF-0004RH-00 for cfrg@ietf.org; Sun, 20 Jul 2003 14:49:18 -0400 Received: from foem (foem [10.11.0.2]) by foem.leiden.webweaving.org (8.12.6/8.12.6) with ESMTP id h6KImUqq077536 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 20 Jul 2003 20:48:30 +0200 (CEST) (envelope-from dirkx@webweaving.org) Date: Sun, 20 Jul 2003 20:48:30 +0200 (CEST) From: Dirk-Willem van Gulik X-X-Sender: dirkx@foem To: Carl Ellison cc: Benja Fallenstein , , , , Subject: Re: [Cfrg] Cryptographic hashes in URNs (was: Comments on draft-thiemann-cbuid-urn-00) In-Reply-To: <3.0.5.32.20030716080607.018df0c8@mailbox.jf.intel.com> Message-ID: <20030720204545.T1449-100000@foem> 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: , On Wed, 16 Jul 2003, Carl Ellison wrote: > Is urn:sha1:dRDPBgZzTFq7Jl2Q2N/YNghcfj8= not now legal? Until there is a registered URN namespace/authority called 'sha1' - nope. You could use x-sha1 - but that is kind of frowned upon. > > urn:sha1:... > > urn:sha256:... > > urn:tiger:... > > urn:sha1+sha256:... > > urn:sha1+tiger:... > > urn:sha256+tiger:... > > urn:sha1+sha256+tiger:... Or regigster urn:assortedhashes:.... or urn:hash:.... and write an RFC which would document that it has to have the shape: urn:hash:[a-z\+]+: And then in that RFC either define all of the above; or devise a scheme by which additional A+B+C's can be added to that block. Obviously in the above replace s/hash/by-whatever/ you want. Dw. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From exim@www1.ietf.org Mon Jul 21 13:19:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04375 for ; Mon, 21 Jul 2003 13:19:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eeJ4-0005ZG-Pj for cfrg-archive@odin.ietf.org; Mon, 21 Jul 2003 13:18:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LHIcOx021396 for cfrg-archive@odin.ietf.org; Mon, 21 Jul 2003 13:18:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eeJ4-0005Z1-JR for cfrg-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 13:18:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04269 for ; Mon, 21 Jul 2003 13:15:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eeFq-0004ms-00 for cfrg-web-archive@ietf.org; Mon, 21 Jul 2003 13:15:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eeFk-0004mZ-00 for cfrg-web-archive@ietf.org; Mon, 21 Jul 2003 13:15:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eeFZ-0005L9-It; Mon, 21 Jul 2003 13:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eMoH-0004T7-Tt for cfrg@optimus.ietf.org; Sun, 20 Jul 2003 18:37:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29923 for ; Sun, 20 Jul 2003 18:37:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eMoE-0005d5-00 for cfrg@ietf.org; Sun, 20 Jul 2003 18:37:39 -0400 Received: from [209.10.143.221] (helo=neonym.net) by ietf-mx with esmtp (Exim 4.12) id 19eMnz-0005cu-00 for cfrg@ietf.org; Sun, 20 Jul 2003 18:37:23 -0400 Received: from [207.120.28.115] ([::ffff:207.120.28.115]) (AUTH: PLAIN michael, ) by neonym.net with esmtp; Sun, 20 Jul 2003 04:22:08 -0400 Subject: Re: [Cfrg] Cryptographic hashes in URNs (was: Comments on draft-thiemann-cbuid-urn-00) From: Michael Mealling To: Carl Ellison Cc: Benja Fallenstein , p2p-hackers@zgp.org, urn-nid@apps.ietf.org, thiemann@informatik.uni-freiburg.de, cfrg@ietf.org In-Reply-To: <3.0.5.32.20030716080607.018df0c8@mailbox.jf.intel.com> References: <3F0DC458.6090401@gmx.de> <3F1427B7.6010402@chapweske.com> <3.0.5.32.20030716080607.018df0c8@mailbox.jf.intel.com> Organization: Harriman Heavy Industries, Inc. Message-Id: <1058740510.3214.1.camel@blackdell.neonym.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.2 Date: 20 Jul 2003 18:35:10 -0400 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2003-07-16 at 11:06, Carl Ellison wrote: > I apparently don't know the rules for URN formation. I thought it > was completely free after the "urn:". Is that not true? Essentially, yes. There are syntactic restrictions that exist for all URIs but that's fairly generic. URNs still have to be persistent so you can put things like domain-names in there unless you time/date stamp them.... -Michael Mealling _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg