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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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" <wangxx@CISAT.JMU.EDU>
To: <cfrg@ietf.org>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"isiresearchsoft-com/cwyw" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C34613.AC9FC2A0">
<title>SAC 2003 - Accepted Papers and Registration Information Now =
Available</title>
<o:SmartTagType namespaceuri=3D"isiresearchsoft-com/cwyw" =
name=3D"citation"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:UseFELayout/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:\00CB\00CE\00CC\00E5;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:SimSun;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue style=3D'tab-interval:.5in'>

<div class=3DSection1>

<div>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'>Hi,<o:p></o:p></sp=
an></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'><o:p>&nbsp;</o:p><=
/span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'>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) =
</span></font><st1:citation><font
 color=3Dnavy><span style=3D'color:navy;mso-no-proof:yes'>{|| denotes =
string concatenation}</span></font></st1:citation><font
color=3Dnavy><span style=3D'color:navy;mso-no-proof:yes'>. 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?<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'><o:p>&nbsp;</o:p><=
/span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'>Thanks,<o:p></o:p>=
</span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'><o:p>&nbsp;</o:p><=
/span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy;mso-no-proof:yes'>Steve<o:p></o:p></=
span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><span =
style=3D'mso-spacerun:yes'>&nbsp;</span><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <canetti@watson.ibm.com>
To: "Wang, Steve" <wangxx@CISAT.JMU.EDU>
cc: cfrg@ietf.org
Subject: Re: [Cfrg] one question about hash
In-Reply-To: <95B156112CF89C4390AB7CF09E601906054D1F@exchange1.cisat.jmu.edu>
Message-ID: <Pine.A41.4.10.10307091502520.26970-100000@ornavella.watson.ibm.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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <cfrg@ietf.org>; 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 <cfrg@ietf.org>; 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 <david.hopwood@zetnet.co.uk>
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: <Pine.A41.4.10.10307091502520.26970-100000@ornavella.watson.ibm.com>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <david.hopwood@zetnet.co.uk>

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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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" <John.Black@Colorado.EDU>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=subscribe>

> Date: Wed, 9 Jul 2003 15:15:24 -0400 (EDT)
> From: canetti <canetti@watson.ibm.com>
> 
> 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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <hugo@ee.technion.ac.il>
To: "John R. Black" <John.Black@Colorado.EDU>
cc: canetti@watson.ibm.com, cfrg@ietf.org
Subject: Re: [Cfrg] Re: one question about hash
In-Reply-To: <20030710112029.B4793@cs>
Message-ID: <Pine.GSO.4.21.0307102249110.27122-100000@ee.technion.ac.il>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <canetti@watson.ibm.com>
> > 
> > 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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <NV99KVKJ>; Fri, 11 Jul 2003 07:03:54 -0700
Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2312@mou1wnexm02.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Hugo Krawczyk'" <hugo@ee.technion.ac.il>,
        "John R. Black"
	 <John.Black@Colorado.EDU>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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" <astiglic@okiok.com>
To: "Hugo Krawczyk" <hugo@ee.technion.ac.il>,
        "John R. Black" <John.Black@Colorado.EDU>
Cc: <canetti@watson.ibm.com>, <cfrg@ietf.org>
References: <Pine.GSO.4.21.0307102249110.27122-100000@ee.technion.ac.il>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <cfrg@ietf.org>; 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 <cfrg@ietf.org>; 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 <shaih@watson.ibm.com>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <hugo@ee.technion.ac.il>
To: Anton Stiglic <astiglic@okiok.com>
cc: cfrg@ietf.org
Subject: Re: [Cfrg] Re: one question about hash
In-Reply-To: <004101c347c3$2c6c8490$3f00a8c0@p1038mobile>
Message-ID: <Pine.GSO.4.21.0307112053520.20436-100000@ee.technion.ac.il>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <hugo@ee.technion.ac.il>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
cc: cfrg@ietf.org
Subject: RE: [Cfrg] Re: one question about hash
In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2312@mou1wnexm02.verisign.com>
Message-ID: <Pine.GSO.4.21.0307112337500.20436-100000@ee.technion.ac.il>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <hugo@ee.technion.ac.il>
To: Shai Halevi <shaih@watson.ibm.com>
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: <Pine.GSO.4.21.0307112106500.20436-100000@ee.technion.ac.il>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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?= <henrick@streamsec.se>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <NV99MJTA>; Fri, 11 Jul 2003 16:18:17 -0700
Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D231C@mou1wnexm02.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "'Hugo Krawczyk'" <hugo@ee.technion.ac.il>,
        "Hallam-Baker, Phillip"
	 <pbaker@verisign.com>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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" <astiglic@okiok.com>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>,
        "'Hugo Krawczyk'" <hugo@ee.technion.ac.il>
Cc: <cfrg@ietf.org>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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" <pbaker@verisign.com>
To: "'Hugo Krawczyk'" <hugo@ee.technion.ac.il>; "Hallam-Baker, Phillip"
<pbaker@verisign.com>
Cc: <cfrg@ietf.org>
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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <cfrg@ietf.org>; 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 <cfrg@ietf.org>; 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 <dhopwood@iplusd.net>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <david.hopwood@zetnet.co.uk>

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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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" <astiglic@okiok.com>
To: "David Hopwood" <dhopwood@iplusd.net>, <cfrg@ietf.org>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


----- Original Message ----- 
From: "David Hopwood" <dhopwood@iplusd.net>
[...]
> 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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <b.fallenstein@gmx.de>
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> <m3oezvu8iq.fsf@kailua.informatik.uni-freiburg.de>  <3F1427B7.6010402@chapweske.com> <E19cSuD-0005pu-00@localhost>
In-Reply-To: <E19cSuD-0005pu-00@localhost>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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:<md5-hash>.<sha1-hash>
>>
>> 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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <justin@chapweske.com>
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> <m3oezvu8iq.fsf@kailua.informatik.uni-freiburg.de>  <3F1427B7.6010402@chapweske.com> <E19cSuD-0005pu-00@localhost> <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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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:<foo>

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:<foo>

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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <b.fallenstein@gmx.de>
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> <m3oezvu8iq.fsf@kailua.informatik.uni-freiburg.de>  <3F1427B7.6010402@chapweske.com> <E19cSuD-0005pu-00@localhost> <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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <a href="...">. 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:<foo>
> 
> 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:<foo>
> 
> 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 <a href>.) 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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <b.fallenstein@gmx.de>
From: Carl Ellison <cme@jf.intel.com>
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: <E19cSuD-0005pu-00@localhost>
 <3F0DC458.6090401@gmx.de>
 <m3oezvu8iq.fsf@kailua.informatik.uni-freiburg.de>
 <3F1427B7.6010402@chapweske.com>
 <E19cSuD-0005pu-00@localhost>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <b.fallenstein@gmx.de>
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 <cme@jf.intel.com>
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: <E19cSuD-0005pu-00@localhost> <3F0DC458.6090401@gmx.de> <m3oezvu8iq.fsf@kailua.informatik.uni-freiburg.de> <3F1427B7.6010402@chapweske.com> <E19cSuD-0005pu-00@localhost> <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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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:<namespace id>:<namespace-specific string>

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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <justin@chapweske.com>
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 <cme@jf.intel.com>
CC: Benja Fallenstein <b.fallenstein@gmx.de>, 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: <E19cSuD-0005pu-00@localhost> <3F0DC458.6090401@gmx.de> <m3oezvu8iq.fsf@kailua.informatik.uni-freiburg.de> <3F1427B7.6010402@chapweske.com> <E19cSuD-0005pu-00@localhost> <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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <b.fallenstein@gmx.de>
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 <cme@jf.intel.com>, urn-nid@apps.ietf.org,
        thiemann@informatik.uni-freiburg.de, cfrg@ietf.org
Subject: Re: [p2p-hackers] Re: [Cfrg] Cryptographic hashes in URNs
References: <E19cSuD-0005pu-00@localhost> <3F0DC458.6090401@gmx.de> <m3oezvu8iq.fsf@kailua.informatik.uni-freiburg.de> <3F1427B7.6010402@chapweske.com> <E19cSuD-0005pu-00@localhost> <3.0.5.32.20030716080607.018df0c8@mailbox.jf.intel.com>  <3F158787.6020902@chapweske.com> <E19cq2G-0008Uh-00@localhost>
In-Reply-To: <E19cq2G-0008Uh-00@localhost>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <b.fallenstein@gmx.de>
Cc: p2p-hackers@zgp.org, Carl Ellison <cme@jf.intel.com>,
        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" <smb@research.att.com>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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: <E19cq2G-0008Uh-00@localhost>
From: "Zooko" <zooko@zooko.com>
To: p2p-hackers@zgp.org
Cc: "Carl Ellison" <cme@jf.intel.com>,
        "Benja Fallenstein" <b.fallenstein@gmx.de>, 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 <justin@chapweske.com> 
   of "Wed, 16 Jul 2003 12:12:39 CDT." <3F158787.6020902@chapweske.com> 
References: <E19cSuD-0005pu-00@localhost> <3F0DC458.6090401@gmx.de> <m3oezvu8iq.fsf@kailua.informatik.uni-freiburg.de> <3F1427B7.6010402@chapweske.com> <E19cSuD-0005pu-00@localhost> <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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <dirkx@webweaving.org>
X-X-Sender: dirkx@foem
To: Carl Ellison <cme@jf.intel.com>
cc: Benja Fallenstein <b.fallenstein@gmx.de>, <p2p-hackers@zgp.org>,
        <urn-nid@apps.ietf.org>, <thiemann@informatik.uni-freiburg.de>,
        <cfrg@ietf.org>
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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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\+]+:<base32string>

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 <cfrg-archive@odin.ietf.org>; 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 <cfrg-web-archive@ietf.org>; 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 <cfrg@ietf.org>; 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 <michael@neonym.net>
To: Carl Ellison <cme@jf.intel.com>
Cc: Benja Fallenstein <b.fallenstein@gmx.de>, 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: <E19cSuD-0005pu-00@localhost> <3F0DC458.6090401@gmx.de>
	 <m3oezvu8iq.fsf@kailua.informatik.uni-freiburg.de>
	 <3F1427B7.6010402@chapweske.com> <E19cSuD-0005pu-00@localhost>
	 <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: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>,
	<mailto:cfrg-request@ietf.org?subject=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