From hash-bounces@lists.ietf.org Wed Jul 06 11:43:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC45-00076c-6F; Wed, 06 Jul 2005 11:43:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC43-00074y-D6 for hash@megatron.ietf.org; Wed, 06 Jul 2005 11:43:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12172 for ; Wed, 6 Jul 2005 11:43:53 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqCRN-00024I-Tj for hash@ietf.org; Wed, 06 Jul 2005 12:08:02 -0400 Received: from [63.249.99.114] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66Fe0lM072791 for ; Wed, 6 Jul 2005 08:40:02 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 6 Jul 2005 08:39:31 -0700 To: Hash WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Hash] Beginning work on truncation and salting X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org Our tentative charter has the following two issues for work: The DSA signature algorithm requires a hash function whose output is 160 bits. The working group will consider at least two approaches to strengthen one-way hash functions for use in DSA: 1) Truncate a larger one-way hash function output so that it can be used as a secure replacement of a shorter one-way hash function output. 2) Including a random value in the hash function computation. The random value used is transferred at appropriate points in the protocol (ideally once for each use of the hash function). This approach is sometimes called a "salted" or "randomized" hash function. The working group may also consider other potential solutions, and one or more standards-track mechanism will be selected. This would be a good time to start looking at Internet Drafts and external references to both issues. In specific: - Are there papers that focus on truncation? Are there explanations or proofs that show that simple truncation is sufficient? Or that it definitely is not sufficient? - There are probably many methods for including random values in hashes. The one I know of in the IETF is by Shai Halevi and Hugo Krawczyk. Are there others? If so, what are the similarities and differences? - Moving a bit into our longer-term work, where is the strengthening actually needed? Is it needed in protocols that rely on the preimaging and second-preimagin strength of a hash, or only in protocols that rely on the collision resistance? - What other topics are relevant to this first part of our work? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Wed Jul 06 11:43:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC46-00077b-Cd; Wed, 06 Jul 2005 11:43:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC43-00075b-Lz for hash@megatron.ietf.org; Wed, 06 Jul 2005 11:43:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12167 for ; Wed, 6 Jul 2005 11:43:52 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqCRO-00024C-1G for hash@ietf.org; Wed, 06 Jul 2005 12:08:03 -0400 Received: from [63.249.99.114] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66Fe0lI072791 for ; Wed, 6 Jul 2005 08:40:00 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 6 Jul 2005 08:22:15 -0700 To: Hash WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Hash] Next steps for the Hash BOF X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org We seem to have settled on a charter that is acceptable. So the next two steps are: - the agenda for our BOF in Paris - the real work, based on the charter I will start two separate threads for these. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Wed Jul 06 11:43:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC46-00078q-NH; Wed, 06 Jul 2005 11:43:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC43-00075k-U6 for hash@megatron.ietf.org; Wed, 06 Jul 2005 11:43:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12171 for ; Wed, 6 Jul 2005 11:43:53 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqCRO-00024G-1f for hash@ietf.org; Wed, 06 Jul 2005 12:08:02 -0400 Received: from [63.249.99.114] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66Fe0lK072791 for ; Wed, 6 Jul 2005 08:40:01 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 6 Jul 2005 08:27:38 -0700 To: Hash WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Hash] Proposed agenda for IETF 63 in Paris X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org We have asked for a one-hour slot for the BOF because there is not much to work out yet. I propose that the hour be spent as: 1) 30 minutes - charter agreement 2) 30 minutes - presentation(s) on truncation and salting proposals and issues Because this is a BOF, not a working group, we need to be sure we have agreement on the charter before the IESG considers whether or not to really form the WG. We'll start with the last charter I posted (amended as Ben pointed out to make it less ASN.1esque) and see how the folks in the room feel. Does this agenda make sense? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Tue Jul 12 22:37:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsX7s-0002XH-IE; Tue, 12 Jul 2005 22:37:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsX7p-0002X8-62 for hash@megatron.ietf.org; Tue, 12 Jul 2005 22:37:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18310 for ; Tue, 12 Jul 2005 22:37:27 -0400 (EDT) Received: from mta3.pgp.com ([209.237.226.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsXa7-0001D4-CT for hash@ietf.org; Tue, 12 Jul 2005 23:06:45 -0400 Received: from localhost (ns1.pgp.com [63.251.255.3]) by mta3.pgp.com (Postfix) with ESMTP id 78750A62F for ; Tue, 12 Jul 2005 19:37:10 -0700 (PDT) Received: from mta3.pgp.com ([10.216.2.26]) by localhost (garfish-1.pgp.com [63.251.255.3]) (amavisd-new, port 10024) with LMTP id 85566-03 for ; Tue, 12 Jul 2005 19:37:04 -0700 (PDT) Received: from bonnie.pgp.com (keys.pgp.com [63.251.255.8]) by mta3.pgp.com (Postfix) with ESMTP id B3625A646 for ; Tue, 12 Jul 2005 19:37:04 -0700 (PDT) Received: from exchange.corp.pgp.com ([10.214.0.35]) by bonnie.pgp.com (PGP Universal service); Tue, 12 Jul 2005 19:37:04 -0700 Received: from bonnie.pgp.com ([63.251.255.8]) by exchange.corp.pgp.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 19:36:38 -0700 Received: from [172.16.1.2] ([10.214.2.201]) by bonnie.pgp.com (PGP Universal service); Tue, 12 Jul 2005 19:36:46 -0700 X-PGP-Universal: processed; by bonnie.pgp.com on Tue, 12 Jul 2005 19:36:46 -0700 Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: Jon Callas Date: Tue, 12 Jul 2005 10:47:20 -0700 To: hash@ietf.org X-Mailer: Apple Mail (2.622) Content-Type: text/plain; charset="utf-8"; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 13 Jul 2005 02:36:38.0752 (UTC) FILETIME=[B1F3FE00:01C58753] X-Spam-Score: 0.6 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hash] BOF Goals X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org In=20my=20involvement=20with=20IETF=20groups,=20one=20thing=20that=20has=20= always=20struck=20me=20=20 as=20a=20good=20thing=20is=20its=20decisions=20to=20stick=20to=20well-def= ined,=20practical=20=20 matters.=20Furthermore,=20these=20have=20been=20more=20in=20layout=20than= =20anything=20=20 else.=20We=20don't=20like=20APIs,=20we=20like=20message=20transactions.=20= Even=20when=20we=20=20 venture=20into=20advice,=20it's=20always=20actionable,=20meaning=20that=20= there=20are=20=20 specific=20things=20that=20a=20practitioner=20can=20do.=20These=20prefere= nces=20are=20=20 positively=20clich=C3=A9,=20none=20of=20us=20needs=20to=20read=20the=20wo= rds=20=22rough=20consensus=20=20 and=20working=20code=22=20--=20we've=20already=20been=20humming=20that=20= tune=20in=20our=20heads. It's=20therefore=20a=20bit=20unusual=20for=20me=20to=20ask=20one=20of=20m= y=20own=20clich=C3=A9=20=20 questions:=20What=20problem=20are=20we=20trying=20to=20solve?=20and=20hav= e=20that=20be=20both=20=20 genuine=20and=20backed=20with=20my=20own=20puzzlement.=20I=20don't=20know= =20what=20we=20are=20=20 doing,=20expect,=20plan,=20or=20even=20hope. Yes,=20cryptographic=20engineering=20is=20in=20the=20uncomfortable=20situ= ation=20=20 presently=20that=20we're=20staring=20at=20embarrassing=20surprises=20with= =20our=20present=20=20 suite=20of=20hash=20functions.=20But=20the=20present-day=20workarounds=20= are=20clear=3B=20we=20=20 have=20hash=20functions=20that=20are=20good=20enough=20for=20the=20short=20= and=20medium-term=20=20 future.=20We=20also=20know=20that=20some=20uses=20of=20the=20present=20ha= sh=20functions=20work=20=20 just=20fine,=20thank=20you.=20(HMAC-MD5=20springs=20to=20mind.) As=20it=20has=20been=20stated,=20there=20are=20two=20problems=20we're=20l= ooking=20at: (1)=20truncating=20existing=20wide=20hashes=20for=20use=20in=20systems=20= like=20DSA. (2)=20to=20explore=20=22randomized=22=20hashes. The=20first=20one=20is=20pretty=20easy=20to=20deal=20with,=20in=20the=20g= eneral=20case.=20We=20=20 already=20addressed=20this=20in=20OpenPGP. FIPS-180,=20which=20describes=20all=20of=20the=20SHA-family=20hashes=20[1= ]=20answers=20this=20=20 question=20on=20page=2073: =20=20=20=20=20=22Some=20applications=20may=20require=20a=20hash=20functi= on=20with=20an=20output=20size =20=20=20=20=20(i.e.,=20message=20digest=20size)=20different=20than=20tho= se=20provided=20by=20the =20=20=20=20=20hash=20functions=20in=20this=20Standard.=20In=20such=20cas= es,=20a=20truncated=20hash =20=20=20=20=20output=20may=20be=20used,=20whereby=20a=20hash=20function=20= with=20a=20larger=20output =20=20=20=20=20size=20is=20applied=20to=20the=20data=20to=20be=20hashed,=20= and=20the=20resulting=20output =20=20=20=20=20(i.e.,=20message=20digest)=20is=20truncated=20by=20selecti= ng=20an=20appropriate =20=20=20=20=20number=20of=20the=20leftmost=20bits.=20For=20example,=20if= =20an=20output=20of=2096=20bits=20is =20=20=20=20=20desired,=20the=20SHA256=20hash=20function=20could=20be=20u= sed=20(e.g.,=20because=20it=20is =20=20=20=20=20available=20to=20the=20application),=20and=20the=20leftmos= t=2096=20bits=20of=20the =20=20=20=20=20output=20are=20selected=20as=20the=20message=20digest,=20d= iscarding=20the=20rightmost =20=20=20=20=20160=20bits=20of=20the=20SHA-256=20output.=22 Now,=20I=20should=20add=20that=20we=20decided=20not=20to=20do=20this=20in= =20PGP's=20products,=20nor=20=20 in=20OpenPGP.=20At=20PGP=20Corporation,=20we=20coded=20such=20a=20truncat= ion=20into=20our=20DSA=20=20 implementation=20for=20early=20releases=20of=20PGP=209.=20However,=20when= =20I=20mentioned=20=20 this=20a=20senior=20NIST=20person,=20I=20was=20asked=20not=20to.=20We=20a= ccidentally=20let=20the=20=20 truncated-SHA-256=20version=20of=20DSA=20escape=20in=20one=20beta=20test,= =20but=20we=20don't=20=20 have=20it=20in=20there. The=20reason=20we=20decided=20to=20stick=20with=20DSA=20as-is=20is=20that= =20DSA=20does=20not=20=20 include=20hash=20information=20in=20the=20signature=20itself.=20Consequen= tly,=20there's=20=20 a=20chance=20of=20cross-hash=20collisions=20in=20addition=20to=20the=20no= rmal=20chance=20of=20=20 hash=20collisions.=20I=20think=20that=20the=20risk=20of=20this=20is=20low= =20when=20the=20hash=20=20 functions=20are=20strong,=20and=20higher=20if=20the=20hash=20functions=20= are=20weak.=20Thus,=20=20 truncating=20SHA-256=20conceivably=20makes=20the=20overall=20system=20=2A= less=2A=20secure=20=20 by=20opening=20up=20the=20possibility=20of=20cross-hash=20collisions. NIST=20is=20supposed=20to=20release=20an=20addendum=20to=20DSA=20for=20wi= de=20hashes=20and=20keys=20=20 bigger=20than=201024=20bits.=20The=20=2Acorrect=2A=20thing=20for=20us=20t= o=20do=20is=20wait=20for=20=20 that.=20That=20they=20haven't=20done=20so=20yet=20is=20disappointing.=20I= =20was=20asking=20for=20=20 it=20pretty-please=20with=20sugar=20on=20top=20in=20August=20'04=20at=20C= rypto,=20and=20we're=20=20 still=20waiting.=20But=20--=20they=20have=20their=20reasons,=20whatever=20= they=20are.=20If=20=20 someone=20finds=20the=20wait=20unacceptable,=20then=20there's=20an=20obvi= ous=20workaround=20=20 --=20use=20RSA=20with=20SHA-256. I=20don't=20think=20we=20need=20to=20do=20anything=20with=20the=20truncat= ion=20issue.=20The=20=20 answer=20of=20how=20to=20truncate=20the=20wide=20SHAs=20is=20answered=20f= or=20us=20in=20FIPS=20180.=20=20 The=20answer=20of=20what=20to=20do=20with=20DSA=20is=20=22Don't.=22=20We=20= can=20wait=20for=20NIST.=20If=20=20 we=20don't=20we're=20going=20to=20have=20to=20do=20what=20they=20say,=20a= nyway.=20Why=20make=20more=20=20 work? The=20second=20issue,=20using=20salted=20hashes=20(I=20prefer=20this=20to= =20=22randomized=22),=20=20 is=20more=20interesting=20technologically,=20but=20there=20are=20still=20= a=20number=20of=20=20 extremely=20important=20issues=20open=20about=20them. The=20first=20open=20issue=20is=20their=20expected=20security=20when=20co= mpared=20both=20to=20=20 the=20unsalted=20version=20and=20comparable=20other=20functions.=20For=20= example,=20we=20=20 know=20that=20SHA-1=20should=20have=2080=20bits=20of=20security=20and=20d= oesn't.=20Will=20as=20=20 salted=20SHA-1=20have=2080=20bits=20of=20security?=20What=20makes=20us=20= think=20so?=20SHA-256=20=20 should=20have=20128=20bits=20of=20security,=20and=20many=20of=20us=20(I=20= know=20I=20am=20one)=20=20 expect=20it=20to=20have=20flaws.=20However,=20do=20we=20expect=20it=20to=20= have=20less=20than=2080=20=20 bits=20of=20security?=20I=20don't. It=20is=20a=20fair=20criticism=20of=20our=20history=20of=20designing=20ha= sh=20functions=20that=20=20 we've=20tweaked=20them=20rather=20than=20redesign=20them.=20But=20salting= =20the=20hash=20is=20=20 also=20a=20tweak.=20If=20SHA-256=20is=20so=20broken=20that=20alone=20it=20= has=20less=20security=20=20 than=2080=20bits,=20what=20could=20possibly=20make=20us=20think=20that=20= a=20tweak=20like=20=20 salting=20will=20actually=20increase=20security?=20I=20wrote=20a=20long=20= note=20to=20the=20=20 CFRG=20list=20on=20this=20theme,=20which=20I=20will=20be=20happy=20to=20r= epost=20here.=20I=20=20 believe=20that=20whatever=20flaws=20SHA-256=20might=20have,=20it=20has=20= enough=20security=20=20 to=20last=20us=20for=20five=20to=20fifteen=20years=20at=2080=20to=20100=20= bits=20of=20security.=20My=20=20 rationale=20for=20my=20opinion=20is=20in=20that=20CFRG=20email. The=20second=20issue=20is=20the=20performance=20of=20the=20salted=20hash=20= functions.=20In=20=20 discussions=20in=20the=20CFRG=20list,=20Dan=20Bernstein=20has=20suggested= =20that=20salted=20=20 MD5=20has=20similar=20performance=20to=20unsalted=20SHA-256.=20If=20this=20= is=20so,=20then=20=20 whyever=20would=20you=20use=20salted=20MD5?=20Surely=20no=20one=20suggest= s=20that=20SHA-256=20=20 has=20fewer=20than=2064=20bits=20of=20security,=20do=20they?=20If=20salte= d=20MD5=20and=20SHA-256=20=20 are=20similar=20in=20performance,=20then=20the=20=2Aonly=2A=20reason=20to= =20consider=20using=20=20 salted=20MD5=20is=20that=20whatever=20protocol=20you're=20using=20can=20s= upport=20a=20128-bit=20=20 hash,=20but=20not=20a=20256-bit=20hash.=20And=20even=20in=20that=20case,=20= the=20=2Areal=2A=20=20 question=20we=20should=20be=20asking=20is=20whether=20truncated=20SHA-256= =20has=2064=20bits=20=20 of=20security=21 It=20seems=20to=20me=20that=20if=20there=20are=20questions=20that=20a=20h= ashing=20working=20group=20=20 should=20be=20asking,=20they=20are=20not=20the=20ones=20we're=20asking,=20= but=20other=20ones=20=20 that=20include: =2A=20What=20is=20the=20security=20of=20a=20salted=20hash=20function?=20D= oes=20salted=20MD5=20have=20=20 64=20bits=20of=20security?=20Does=20salted=20SHA-1=20have=2080=20bits=20o= f=20security?=20Does=20=20 salted=20SHA-256=20have=20128=20bits=20of=20security?=20Why=20do=20we=20t= hink=20this?=20I've=20=20 seen=20no=20reasoning=20nor=20metrics. =2A=20What=20is=20the=20security=20of=20a=20truncated=20hash=20function?=20= Examples:=20Suppose=20=20 SHA-256=20has=20110=20bits=20of=20security=20(if=20it=20is=20as=20broken=20= as=20SHA-1,=20this=20is=20=20 my=20predicted=20security=20value).=20If=20you=20truncate=20SHA-256=20to=20= 128=20bits,=20does=20=20 that=20mean=20that=20it=20has=2055=20bits=20of=20security?=20Or=20does=20= it=20mean=20that=20it=20has=20=20 64=20bits=20of=20security?=20Or=20something=20in=20the=20middle?=20Why=20= do=20we=20think=20this?=20=20 What=20do=20we=20expect=20its=20security=20to=20be=20if=20you=20truncate=20= it=20to=20160=20bits=20and=20=20 why? =2A=20What=20is=20the=20performance=20of=20a=20salted=20hash=20function?=20= Bernstein's=20claim=20=20 that=20salted=20MD5=20has=20similar=20performance=20to=20SHA-256=20has=20= gone=20=20 unchallenged,=20and=20he=20himself=20has=20noted=20this=20silence. =2A=20Are=20there=20other=20constructions=20we=20can=20perform=20that=20g= ive=20us=20security=20=20 over=20the=20naked=20hash=20function,=20but=20require=20less=20work=20tha= n=20salting?=20For=20=20 example,=20suppose=20we=20took=20SHA-256=20and=20folded=20its=20halves,=20= XORing=20them=20=20 together.=20Does=20this=20give=20us=20more=20security=20than=20straight=20= truncation?=20If=20=20 not,=20why=20not=20(since=20it=20seems=20intuitive=20that=20folding=20wou= ld=20have=20at=20least=20=20 an=20eensy=20bit=20more=20security)?=20What=20other=20constructions=20cou= ld=20we=20make=20=20 that=20improve=20over=20raw=20truncation=20without=20the=20cost=20of=20sa= lting? Without=20answers=20to=20these=20questions,=20I=20don't=20see=20how=20thi= s=20working=20group=20=20 can=20give=20any=20meaningful=20results.=20Worse,=20I=20don't=20see=20how= =20any=20=20 recommendation=20of=20this=20group=20can=20improve=20over=20the=20simple=20= advice=20of=20=22use=20=20 SHA-256.=22=20If=20this=20BOF=20results=20in=20a=20working=20group,=20I=20= believe=20it=20=2Amust=2A=20=20 address=20the=20questions=20I=20outlined=20above,=20as=20well=20as=20the=20= issues=20I=20and=20=20 Bernstein=20have=20brought=20up=20in=20CFRG. If=20salted=20hashes=20are=20slower=20than=20wider=20hashes=20and=20the=20= wider=20hash=20has=20=20 enough=20security=20(enough=20being=20greater=20than=2064=20bits=20for=20= an=20MD5=20=20 replacement=20and=20greater=20than=2080=20bits=20for=20a=20SHA-1=20replac= ement),=20then=20we=20=20 should=20just=20use=20the=20wider=20hash=20and=20be=20done=20with=20it=20= --=20except=20when=20=20 that's=20not=20reasonable. It=20is=20only=20when=20the=20actual=20size=20of=20the=20hash=20function=20= is=20an=20issue=20and=20=20 you=20can't=20just=20switch=20to=20RSA=20that=20the=20simple=20advice=20i= sn't=20worth=20taking.=20=20 I=20can=20think=20of=20one=20such=20instance,=20and=20it's=20a=20draft=20= that=20I=20work=20on=20--=20=20 syslog-sign.=20In=20syslog-sign,=20space=20is=20at=20a=20premium,=20and=20= it=20uses=20DSA=20for=20=20 this=20reason.=20(A=20DSA=20signature=20is=20twice=20the=20size=20of=20th= e=20hash=20function=20=20 rather=20than=20proportional=20to=20the=20size=20of=20the=20key,=20and=20= syslog=20packets=20are=20=20 teenie.)=20Furthermore,=20the=20way=20that=20syslog-sign=20is=20used,=20i= t=20is=20far=20=20 better=20to=20have=20a=20160-bit=20hash=20with=2080=20bits=20of=20securit= y=20than=20it=20is=20to=20=20 have=20anything=20else=3B=20space=20is=20at=20that=20much=20of=20a=20prem= ium.=20In=20=2Athis=2A=20case,=20=20 I'd=20be=20happy=20to=20seemingly=20contradict=20my=20previous=20grouchin= ess=20and=20say,=20=20 =22Aw,=20just=20truncate=20SHA-256=20to=20160=20bits=20and=20use=20that=20= in=20DSA.=22=20There=20may=20=20 be=20other=20cases=20where=20the=20use=20model=20of=20the=20protocol=20mi= ght=20warrant=20that. But=20in=20the=20vast=20majority=20of=20cases,=20the=20simple=20advice: (1)=20If=20you're=20using=20DSA,=20grin=20and=20bear=20it=20until=20NIST=20= comes=20out=20with=20=20 wide=20DSA (2)=20If=20you're=20using=20RSA,=20switch=20to=20using=20SHA-256 (3)=20If=20you're=20using=20DSA=20and=20don't=20like=20(1),=20switch=20to= =20(2) is=20perfectly=20fine=20advice. =09Jon [1]=20=20 =3Chttp://csrc.nist.gov/publications/fips/fips180-2/fips180=20 -2withchangenotice.pdf=3E --=20 Jon=20Callas CTO,=20CSO PGP=20Corporation=20=20=20=20=20=20=20=20=20Tel:=20+1=20(650)=20319-9016 3460=20West=20Bayshore=20=20=20=20=20=20Fax:=20+1=20(650)=20319-9001 Palo=20Alto,=20CA=2094303=20=20=20=20=20PGP:=20ed15=205bdf=20cd41=20adfc=20= 00f3 USA=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=2028b6=2052bf=205a46=20bc98=20e63d --=20 Jon=20Callas CTO,=20CSO PGP=20Corporation=20=20=20=20=20=20=20=20=20Tel:=20+1=20(650)=20319-9016 3460=20West=20Bayshore=20=20=20=20=20=20Fax:=20+1=20(650)=20319-9001 Palo=20Alto,=20CA=2094303=20=20=20=20=20PGP:=20ed15=205bdf=20cd41=20adfc=20= 00f3 USA=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=2028b6=2052bf=205a46=20bc98=20e63d =0A ________________________________________________________________ This=20message=20could=20have=20been=20secured=20by=20PGP=20Universal.=20= To=20secure future=20messages=20from=20this=20sender,=20please=20click=20this=20link: https://keys.pgp.com/b/b.e?r=3Dhash=2540ietf.org=26n=3DI6LW=252FTFegliptj= mtozrp=252Bg=253D=253D _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Tue Jul 12 22:38:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsX8j-0002k7-1y; Tue, 12 Jul 2005 22:38:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsX8g-0002jo-Et for hash@megatron.ietf.org; Tue, 12 Jul 2005 22:38:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18394 for ; Tue, 12 Jul 2005 22:38:20 -0400 (EDT) Received: from mta3.pgp.com ([209.237.226.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsXaz-0001F5-To for hash@ietf.org; Tue, 12 Jul 2005 23:07:38 -0400 Received: from localhost (ns1.pgp.com [63.251.255.3]) by mta3.pgp.com (Postfix) with ESMTP id 93AC9A653 for ; Tue, 12 Jul 2005 19:38:12 -0700 (PDT) Received: from mta3.pgp.com ([10.216.2.26]) by localhost (garfish-1.pgp.com [63.251.255.3]) (amavisd-new, port 10024) with LMTP id 85436-02-16 for ; Tue, 12 Jul 2005 19:38:10 -0700 (PDT) Received: from bonnie.pgp.com (keys.pgp.com [63.251.255.8]) by mta3.pgp.com (Postfix) with ESMTP id 5936CA62F for ; Tue, 12 Jul 2005 19:38:10 -0700 (PDT) Received: from exchange.corp.pgp.com ([10.214.0.35]) by bonnie.pgp.com (PGP Universal service); Tue, 12 Jul 2005 19:38:10 -0700 Received: from bonnie.pgp.com ([63.251.255.8]) by exchange.corp.pgp.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 19:37:04 -0700 Received: from [172.16.1.2] ([10.214.2.201]) by bonnie.pgp.com (PGP Universal service); Tue, 12 Jul 2005 19:37:12 -0700 X-PGP-Universal: processed; by bonnie.pgp.com on Tue, 12 Jul 2005 19:37:12 -0700 Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <54646b48339836e44f8917d434bb3e5b@pgp.com> From: Jon Callas Date: Tue, 12 Jul 2005 19:37:00 -0700 To: hash@ietf.org X-Mailer: Apple Mail (2.622) Content-Type: text/plain; charset="utf-8"; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 13 Jul 2005 02:37:04.0955 (UTC) FILETIME=[C19240B0:01C58753] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hash] BOF Goals X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org In=20my=20involvement=20with=20IETF=20groups,=20one=20thing=20that=20has=20= always=20struck=20me=20=20 as=20a=20good=20thing=20is=20its=20decisions=20to=20stick=20to=20well-def= ined,=20practical=20=20 matters.=20Furthermore,=20these=20have=20been=20more=20in=20layout=20than= =20anything=20=20 else.=20We=20don't=20like=20APIs,=20we=20like=20message=20transactions.=20= Even=20when=20we=20=20 venture=20into=20advice,=20it's=20always=20actionable,=20meaning=20that=20= there=20are=20=20 specific=20things=20that=20a=20practitioner=20can=20do.=20These=20prefere= nces=20are=20=20 positively=20clich=C3=A9,=20none=20of=20us=20needs=20to=20read=20the=20wo= rds=20=22rough=20consensus=20=20 and=20working=20code=22=20--=20we've=20already=20been=20humming=20that=20= tune=20in=20our=20heads. It's=20therefore=20a=20bit=20unusual=20for=20me=20to=20ask=20one=20of=20m= y=20own=20clich=C3=A9=20=20 questions:=20What=20problem=20are=20we=20trying=20to=20solve?=20and=20hav= e=20that=20be=20both=20=20 genuine=20and=20backed=20with=20my=20own=20puzzlement.=20I=20don't=20know= =20what=20we=20are=20=20 doing,=20expect,=20plan,=20or=20even=20hope. Yes,=20cryptographic=20engineering=20is=20in=20the=20uncomfortable=20situ= ation=20=20 presently=20that=20we're=20staring=20at=20embarrassing=20surprises=20with= =20our=20present=20=20 suite=20of=20hash=20functions.=20But=20the=20present-day=20workarounds=20= are=20clear=3B=20we=20=20 have=20hash=20functions=20that=20are=20good=20enough=20for=20the=20short=20= and=20medium-term=20=20 future.=20We=20also=20know=20that=20some=20uses=20of=20the=20present=20ha= sh=20functions=20work=20=20 just=20fine,=20thank=20you.=20(HMAC-MD5=20springs=20to=20mind.) As=20it=20has=20been=20stated,=20there=20are=20two=20problems=20we're=20l= ooking=20at: (1)=20truncating=20existing=20wide=20hashes=20for=20use=20in=20systems=20= like=20DSA. (2)=20to=20explore=20=22randomized=22=20hashes. The=20first=20one=20is=20pretty=20easy=20to=20deal=20with,=20in=20the=20g= eneral=20case.=20We=20=20 already=20addressed=20this=20in=20OpenPGP. FIPS-180,=20which=20describes=20all=20of=20the=20SHA-family=20hashes=20[1= ]=20answers=20this=20=20 question=20on=20page=2073: =20=20=20=20=20=22Some=20applications=20may=20require=20a=20hash=20functi= on=20with=20an=20output=20size =20=20=20=20=20(i.e.,=20message=20digest=20size)=20different=20than=20tho= se=20provided=20by=20the =20=20=20=20=20hash=20functions=20in=20this=20Standard.=20In=20such=20cas= es,=20a=20truncated=20hash =20=20=20=20=20output=20may=20be=20used,=20whereby=20a=20hash=20function=20= with=20a=20larger=20output =20=20=20=20=20size=20is=20applied=20to=20the=20data=20to=20be=20hashed,=20= and=20the=20resulting=20output =20=20=20=20=20(i.e.,=20message=20digest)=20is=20truncated=20by=20selecti= ng=20an=20appropriate =20=20=20=20=20number=20of=20the=20leftmost=20bits.=20For=20example,=20if= =20an=20output=20of=2096=20bits=20is =20=20=20=20=20desired,=20the=20SHA256=20hash=20function=20could=20be=20u= sed=20(e.g.,=20because=20it=20is =20=20=20=20=20available=20to=20the=20application),=20and=20the=20leftmos= t=2096=20bits=20of=20the =20=20=20=20=20output=20are=20selected=20as=20the=20message=20digest,=20d= iscarding=20the=20rightmost =20=20=20=20=20160=20bits=20of=20the=20SHA-256=20output.=22 Now,=20I=20should=20add=20that=20we=20decided=20not=20to=20do=20this=20in= =20PGP's=20products,=20nor=20=20 in=20OpenPGP.=20At=20PGP=20Corporation,=20we=20coded=20such=20a=20truncat= ion=20into=20our=20DSA=20=20 implementation=20for=20early=20releases=20of=20PGP=209.=20However,=20when= =20I=20mentioned=20=20 this=20a=20senior=20NIST=20person,=20I=20was=20asked=20not=20to.=20We=20a= ccidentally=20let=20the=20=20 truncated-SHA-256=20version=20of=20DSA=20escape=20in=20one=20beta=20test,= =20but=20we=20don't=20=20 have=20it=20in=20there. The=20reason=20we=20decided=20to=20stick=20with=20DSA=20as-is=20is=20that= =20DSA=20does=20not=20=20 include=20hash=20information=20in=20the=20signature=20itself.=20Consequen= tly,=20there's=20=20 a=20chance=20of=20cross-hash=20collisions=20in=20addition=20to=20the=20no= rmal=20chance=20of=20=20 hash=20collisions.=20I=20think=20that=20the=20risk=20of=20this=20is=20low= =20when=20the=20hash=20=20 functions=20are=20strong,=20and=20higher=20if=20the=20hash=20functions=20= are=20weak.=20Thus,=20=20 truncating=20SHA-256=20conceivably=20makes=20the=20overall=20system=20=2A= less=2A=20secure=20=20 by=20opening=20up=20the=20possibility=20of=20cross-hash=20collisions. NIST=20is=20supposed=20to=20release=20an=20addendum=20to=20DSA=20for=20wi= de=20hashes=20and=20keys=20=20 bigger=20than=201024=20bits.=20The=20=2Acorrect=2A=20thing=20for=20us=20t= o=20do=20is=20wait=20for=20=20 that.=20That=20they=20haven't=20done=20so=20yet=20is=20disappointing.=20I= =20was=20asking=20for=20=20 it=20pretty-please=20with=20sugar=20on=20top=20in=20August=20'04=20at=20C= rypto,=20and=20we're=20=20 still=20waiting.=20But=20--=20they=20have=20their=20reasons,=20whatever=20= they=20are.=20If=20=20 someone=20finds=20the=20wait=20unacceptable,=20then=20there's=20an=20obvi= ous=20workaround=20=20 --=20use=20RSA=20with=20SHA-256. I=20don't=20think=20we=20need=20to=20do=20anything=20with=20the=20truncat= ion=20issue.=20The=20=20 answer=20of=20how=20to=20truncate=20the=20wide=20SHAs=20is=20answered=20f= or=20us=20in=20FIPS=20180.=20=20 The=20answer=20of=20what=20to=20do=20with=20DSA=20is=20=22Don't.=22=20We=20= can=20wait=20for=20NIST.=20If=20=20 we=20don't=20we're=20going=20to=20have=20to=20do=20what=20they=20say,=20a= nyway.=20Why=20make=20more=20=20 work? The=20second=20issue,=20using=20salted=20hashes=20(I=20prefer=20this=20to= =20=22randomized=22),=20=20 is=20more=20interesting=20technologically,=20but=20there=20are=20still=20= a=20number=20of=20=20 extremely=20important=20issues=20open=20about=20them. The=20first=20open=20issue=20is=20their=20expected=20security=20when=20co= mpared=20both=20to=20=20 the=20unsalted=20version=20and=20comparable=20other=20functions.=20For=20= example,=20we=20=20 know=20that=20SHA-1=20should=20have=2080=20bits=20of=20security=20and=20d= oesn't.=20Will=20as=20=20 salted=20SHA-1=20have=2080=20bits=20of=20security?=20What=20makes=20us=20= think=20so?=20SHA-256=20=20 should=20have=20128=20bits=20of=20security,=20and=20many=20of=20us=20(I=20= know=20I=20am=20one)=20=20 expect=20it=20to=20have=20flaws.=20However,=20do=20we=20expect=20it=20to=20= have=20less=20than=2080=20=20 bits=20of=20security?=20I=20don't. It=20is=20a=20fair=20criticism=20of=20our=20history=20of=20designing=20ha= sh=20functions=20that=20=20 we've=20tweaked=20them=20rather=20than=20redesign=20them.=20But=20salting= =20the=20hash=20is=20=20 also=20a=20tweak.=20If=20SHA-256=20is=20so=20broken=20that=20alone=20it=20= has=20less=20security=20=20 than=2080=20bits,=20what=20could=20possibly=20make=20us=20think=20that=20= a=20tweak=20like=20=20 salting=20will=20actually=20increase=20security?=20I=20wrote=20a=20long=20= note=20to=20the=20=20 CFRG=20list=20on=20this=20theme,=20which=20I=20will=20be=20happy=20to=20r= epost=20here.=20I=20=20 believe=20that=20whatever=20flaws=20SHA-256=20might=20have,=20it=20has=20= enough=20security=20=20 to=20last=20us=20for=20five=20to=20fifteen=20years=20at=2080=20to=20100=20= bits=20of=20security.=20My=20=20 rationale=20for=20my=20opinion=20is=20in=20that=20CFRG=20email. The=20second=20issue=20is=20the=20performance=20of=20the=20salted=20hash=20= functions.=20In=20=20 discussions=20in=20the=20CFRG=20list,=20Dan=20Bernstein=20has=20suggested= =20that=20salted=20=20 MD5=20has=20similar=20performance=20to=20unsalted=20SHA-256.=20If=20this=20= is=20so,=20then=20=20 whyever=20would=20you=20use=20salted=20MD5?=20Surely=20no=20one=20suggest= s=20that=20SHA-256=20=20 has=20fewer=20than=2064=20bits=20of=20security,=20do=20they?=20If=20salte= d=20MD5=20and=20SHA-256=20=20 are=20similar=20in=20performance,=20then=20the=20=2Aonly=2A=20reason=20to= =20consider=20using=20=20 salted=20MD5=20is=20that=20whatever=20protocol=20you're=20using=20can=20s= upport=20a=20128-bit=20=20 hash,=20but=20not=20a=20256-bit=20hash.=20And=20even=20in=20that=20case,=20= the=20=2Areal=2A=20=20 question=20we=20should=20be=20asking=20is=20whether=20truncated=20SHA-256= =20has=2064=20bits=20=20 of=20security=21 It=20seems=20to=20me=20that=20if=20there=20are=20questions=20that=20a=20h= ashing=20working=20group=20=20 should=20be=20asking,=20they=20are=20not=20the=20ones=20we're=20asking,=20= but=20other=20ones=20=20 that=20include: =2A=20What=20is=20the=20security=20of=20a=20salted=20hash=20function?=20D= oes=20salted=20MD5=20have=20=20 64=20bits=20of=20security?=20Does=20salted=20SHA-1=20have=2080=20bits=20o= f=20security?=20Does=20=20 salted=20SHA-256=20have=20128=20bits=20of=20security?=20Why=20do=20we=20t= hink=20this?=20I've=20=20 seen=20no=20reasoning=20nor=20metrics. =2A=20What=20is=20the=20security=20of=20a=20truncated=20hash=20function?=20= Examples:=20Suppose=20=20 SHA-256=20has=20110=20bits=20of=20security=20(if=20it=20is=20as=20broken=20= as=20SHA-1,=20this=20is=20=20 my=20predicted=20security=20value).=20If=20you=20truncate=20SHA-256=20to=20= 128=20bits,=20does=20=20 that=20mean=20that=20it=20has=2055=20bits=20of=20security?=20Or=20does=20= it=20mean=20that=20it=20has=20=20 64=20bits=20of=20security?=20Or=20something=20in=20the=20middle?=20Why=20= do=20we=20think=20this?=20=20 What=20do=20we=20expect=20its=20security=20to=20be=20if=20you=20truncate=20= it=20to=20160=20bits=20and=20=20 why? =2A=20What=20is=20the=20performance=20of=20a=20salted=20hash=20function?=20= Bernstein's=20claim=20=20 that=20salted=20MD5=20has=20similar=20performance=20to=20SHA-256=20has=20= gone=20=20 unchallenged,=20and=20he=20himself=20has=20noted=20this=20silence. =2A=20Are=20there=20other=20constructions=20we=20can=20perform=20that=20g= ive=20us=20security=20=20 over=20the=20naked=20hash=20function,=20but=20require=20less=20work=20tha= n=20salting?=20For=20=20 example,=20suppose=20we=20took=20SHA-256=20and=20folded=20its=20halves,=20= XORing=20them=20=20 together.=20Does=20this=20give=20us=20more=20security=20than=20straight=20= truncation?=20If=20=20 not,=20why=20not=20(since=20it=20seems=20intuitive=20that=20folding=20wou= ld=20have=20at=20least=20=20 an=20eensy=20bit=20more=20security)?=20What=20other=20constructions=20cou= ld=20we=20make=20=20 that=20improve=20over=20raw=20truncation=20without=20the=20cost=20of=20sa= lting? Without=20answers=20to=20these=20questions,=20I=20don't=20see=20how=20thi= s=20working=20group=20=20 can=20give=20any=20meaningful=20results.=20Worse,=20I=20don't=20see=20how= =20any=20=20 recommendation=20of=20this=20group=20can=20improve=20over=20the=20simple=20= advice=20of=20=22use=20=20 SHA-256.=22=20If=20this=20BOF=20results=20in=20a=20working=20group,=20I=20= believe=20it=20=2Amust=2A=20=20 address=20the=20questions=20I=20outlined=20above,=20as=20well=20as=20the=20= issues=20I=20and=20=20 Bernstein=20have=20brought=20up=20in=20CFRG. If=20salted=20hashes=20are=20slower=20than=20wider=20hashes=20and=20the=20= wider=20hash=20has=20=20 enough=20security=20(enough=20being=20greater=20than=2064=20bits=20for=20= an=20MD5=20=20 replacement=20and=20greater=20than=2080=20bits=20for=20a=20SHA-1=20replac= ement),=20then=20we=20=20 should=20just=20use=20the=20wider=20hash=20and=20be=20done=20with=20it=20= --=20except=20when=20=20 that's=20not=20reasonable. It=20is=20only=20when=20the=20actual=20size=20of=20the=20hash=20function=20= is=20an=20issue=20and=20=20 you=20can't=20just=20switch=20to=20RSA=20that=20the=20simple=20advice=20i= sn't=20worth=20taking.=20=20 I=20can=20think=20of=20one=20such=20instance,=20and=20it's=20a=20draft=20= that=20I=20work=20on=20--=20=20 syslog-sign.=20In=20syslog-sign,=20space=20is=20at=20a=20premium,=20and=20= it=20uses=20DSA=20for=20=20 this=20reason.=20(A=20DSA=20signature=20is=20twice=20the=20size=20of=20th= e=20hash=20function=20=20 rather=20than=20proportional=20to=20the=20size=20of=20the=20key,=20and=20= syslog=20packets=20are=20=20 teenie.)=20Furthermore,=20the=20way=20that=20syslog-sign=20is=20used,=20i= t=20is=20far=20=20 better=20to=20have=20a=20160-bit=20hash=20with=2080=20bits=20of=20securit= y=20than=20it=20is=20to=20=20 have=20anything=20else=3B=20space=20is=20at=20that=20much=20of=20a=20prem= ium.=20In=20=2Athis=2A=20case,=20=20 I'd=20be=20happy=20to=20seemingly=20contradict=20my=20previous=20grouchin= ess=20and=20say,=20=20 =22Aw,=20just=20truncate=20SHA-256=20to=20160=20bits=20and=20use=20that=20= in=20DSA.=22=20There=20may=20=20 be=20other=20cases=20where=20the=20use=20model=20of=20the=20protocol=20mi= ght=20warrant=20that. But=20in=20the=20vast=20majority=20of=20cases,=20the=20simple=20advice: (1)=20If=20you're=20using=20DSA,=20grin=20and=20bear=20it=20until=20NIST=20= comes=20out=20with=20=20 wide=20DSA (2)=20If=20you're=20using=20RSA,=20switch=20to=20using=20SHA-256 (3)=20If=20you're=20using=20DSA=20and=20don't=20like=20(1),=20switch=20to= =20(2) is=20perfectly=20fine=20advice. =09Jon [1]=20=20 =3Chttp://csrc.nist.gov/publications/fips/fips180-2/fips180=20 -2withchangenotice.pdf=3E --=20 Jon=20Callas CTO,=20CSO PGP=20Corporation=20=20=20=20=20=20=20=20=20Tel:=20+1=20(650)=20319-9016 3460=20West=20Bayshore=20=20=20=20=20=20Fax:=20+1=20(650)=20319-9001 Palo=20Alto,=20CA=2094303=20=20=20=20=20PGP:=20ed15=205bdf=20cd41=20adfc=20= 00f3 USA=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=2028b6=2052bf=205a46=20bc98=20e63d --=20 Jon=20Callas CTO,=20CSO PGP=20Corporation=20=20=20=20=20=20=20=20=20Tel:=20+1=20(650)=20319-9016 3460=20West=20Bayshore=20=20=20=20=20=20Fax:=20+1=20(650)=20319-9001 Palo=20Alto,=20CA=2094303=20=20=20=20=20PGP:=20ed15=205bdf=20cd41=20adfc=20= 00f3 USA=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=2028b6=2052bf=205a46=20bc98=20e63d =0A ________________________________________________________________ This=20message=20could=20have=20been=20secured=20by=20PGP=20Universal.=20= To=20secure future=20messages=20from=20this=20sender,=20please=20click=20this=20link: https://keys.pgp.com/b/b.e?r=3Dhash=2540ietf.org=26n=3DI6LW=252FTFegliptj= mtozrp=252Bg=253D=253D _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Tue Jul 12 22:38:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsX8m-0002km-O7; Tue, 12 Jul 2005 22:38:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsX8k-0002kc-Tp for hash@megatron.ietf.org; Tue, 12 Jul 2005 22:38:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18403 for ; Tue, 12 Jul 2005 22:38:25 -0400 (EDT) Received: from mta3.pgp.com ([209.237.226.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsXb4-0001FI-Io for hash@ietf.org; Tue, 12 Jul 2005 23:07:43 -0400 Received: from localhost (ns1.pgp.com [63.251.255.3]) by mta3.pgp.com (Postfix) with ESMTP id 2A070A672 for ; Tue, 12 Jul 2005 19:38:17 -0700 (PDT) Received: from mta3.pgp.com ([10.216.2.26]) by localhost (garfish-1.pgp.com [63.251.255.3]) (amavisd-new, port 10024) with LMTP id 85255-04-3 for ; Tue, 12 Jul 2005 19:38:12 -0700 (PDT) Received: from bonnie.pgp.com (keys.pgp.com [63.251.255.8]) by mta3.pgp.com (Postfix) with ESMTP id D1848A662 for ; Tue, 12 Jul 2005 19:38:12 -0700 (PDT) Received: from exchange.corp.pgp.com ([10.214.0.35]) by bonnie.pgp.com (PGP Universal service); Tue, 12 Jul 2005 19:38:12 -0700 Received: from bonnie.pgp.com ([63.251.255.8]) by exchange.corp.pgp.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 19:37:17 -0700 Received: from [172.16.1.2] ([10.214.2.201]) by bonnie.pgp.com (PGP Universal service); Tue, 12 Jul 2005 19:37:25 -0700 X-PGP-Universal: processed; by bonnie.pgp.com on Tue, 12 Jul 2005 19:37:25 -0700 Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <118c6b3536f4814dfe0be0ff3d27c8f6@pgp.com> From: Jon Callas Date: Tue, 12 Jul 2005 19:37:11 -0700 To: hash@ietf.org X-Mailer: Apple Mail (2.622) Content-Type: text/plain; charset="utf-8"; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 13 Jul 2005 02:37:17.0666 (UTC) FILETIME=[C925CC20:01C58753] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hash] BOF Goals X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org In=20my=20involvement=20with=20IETF=20groups,=20one=20thing=20that=20has=20= always=20struck=20me=20=20 as=20a=20good=20thing=20is=20its=20decisions=20to=20stick=20to=20well-def= ined,=20practical=20=20 matters.=20Furthermore,=20these=20have=20been=20more=20in=20layout=20than= =20anything=20=20 else.=20We=20don't=20like=20APIs,=20we=20like=20message=20transactions.=20= Even=20when=20we=20=20 venture=20into=20advice,=20it's=20always=20actionable,=20meaning=20that=20= there=20are=20=20 specific=20things=20that=20a=20practitioner=20can=20do.=20These=20prefere= nces=20are=20=20 positively=20clich=C3=A9,=20none=20of=20us=20needs=20to=20read=20the=20wo= rds=20=22rough=20consensus=20=20 and=20working=20code=22=20--=20we've=20already=20been=20humming=20that=20= tune=20in=20our=20heads. It's=20therefore=20a=20bit=20unusual=20for=20me=20to=20ask=20one=20of=20m= y=20own=20clich=C3=A9=20=20 questions:=20What=20problem=20are=20we=20trying=20to=20solve?=20and=20hav= e=20that=20be=20both=20=20 genuine=20and=20backed=20with=20my=20own=20puzzlement.=20I=20don't=20know= =20what=20we=20are=20=20 doing,=20expect,=20plan,=20or=20even=20hope. Yes,=20cryptographic=20engineering=20is=20in=20the=20uncomfortable=20situ= ation=20=20 presently=20that=20we're=20staring=20at=20embarrassing=20surprises=20with= =20our=20present=20=20 suite=20of=20hash=20functions.=20But=20the=20present-day=20workarounds=20= are=20clear=3B=20we=20=20 have=20hash=20functions=20that=20are=20good=20enough=20for=20the=20short=20= and=20medium-term=20=20 future.=20We=20also=20know=20that=20some=20uses=20of=20the=20present=20ha= sh=20functions=20work=20=20 just=20fine,=20thank=20you.=20(HMAC-MD5=20springs=20to=20mind.) As=20it=20has=20been=20stated,=20there=20are=20two=20problems=20we're=20l= ooking=20at: (1)=20truncating=20existing=20wide=20hashes=20for=20use=20in=20systems=20= like=20DSA. (2)=20to=20explore=20=22randomized=22=20hashes. The=20first=20one=20is=20pretty=20easy=20to=20deal=20with,=20in=20the=20g= eneral=20case.=20We=20=20 already=20addressed=20this=20in=20OpenPGP. FIPS-180,=20which=20describes=20all=20of=20the=20SHA-family=20hashes=20[1= ]=20answers=20this=20=20 question=20on=20page=2073: =20=20=20=20=20=22Some=20applications=20may=20require=20a=20hash=20functi= on=20with=20an=20output=20size =20=20=20=20=20(i.e.,=20message=20digest=20size)=20different=20than=20tho= se=20provided=20by=20the =20=20=20=20=20hash=20functions=20in=20this=20Standard.=20In=20such=20cas= es,=20a=20truncated=20hash =20=20=20=20=20output=20may=20be=20used,=20whereby=20a=20hash=20function=20= with=20a=20larger=20output =20=20=20=20=20size=20is=20applied=20to=20the=20data=20to=20be=20hashed,=20= and=20the=20resulting=20output =20=20=20=20=20(i.e.,=20message=20digest)=20is=20truncated=20by=20selecti= ng=20an=20appropriate =20=20=20=20=20number=20of=20the=20leftmost=20bits.=20For=20example,=20if= =20an=20output=20of=2096=20bits=20is =20=20=20=20=20desired,=20the=20SHA256=20hash=20function=20could=20be=20u= sed=20(e.g.,=20because=20it=20is =20=20=20=20=20available=20to=20the=20application),=20and=20the=20leftmos= t=2096=20bits=20of=20the =20=20=20=20=20output=20are=20selected=20as=20the=20message=20digest,=20d= iscarding=20the=20rightmost =20=20=20=20=20160=20bits=20of=20the=20SHA-256=20output.=22 Now,=20I=20should=20add=20that=20we=20decided=20not=20to=20do=20this=20in= =20PGP's=20products,=20nor=20=20 in=20OpenPGP.=20At=20PGP=20Corporation,=20we=20coded=20such=20a=20truncat= ion=20into=20our=20DSA=20=20 implementation=20for=20early=20releases=20of=20PGP=209.=20However,=20when= =20I=20mentioned=20=20 this=20a=20senior=20NIST=20person,=20I=20was=20asked=20not=20to.=20We=20a= ccidentally=20let=20the=20=20 truncated-SHA-256=20version=20of=20DSA=20escape=20in=20one=20beta=20test,= =20but=20we=20don't=20=20 have=20it=20in=20there. The=20reason=20we=20decided=20to=20stick=20with=20DSA=20as-is=20is=20that= =20DSA=20does=20not=20=20 include=20hash=20information=20in=20the=20signature=20itself.=20Consequen= tly,=20there's=20=20 a=20chance=20of=20cross-hash=20collisions=20in=20addition=20to=20the=20no= rmal=20chance=20of=20=20 hash=20collisions.=20I=20think=20that=20the=20risk=20of=20this=20is=20low= =20when=20the=20hash=20=20 functions=20are=20strong,=20and=20higher=20if=20the=20hash=20functions=20= are=20weak.=20Thus,=20=20 truncating=20SHA-256=20conceivably=20makes=20the=20overall=20system=20=2A= less=2A=20secure=20=20 by=20opening=20up=20the=20possibility=20of=20cross-hash=20collisions. NIST=20is=20supposed=20to=20release=20an=20addendum=20to=20DSA=20for=20wi= de=20hashes=20and=20keys=20=20 bigger=20than=201024=20bits.=20The=20=2Acorrect=2A=20thing=20for=20us=20t= o=20do=20is=20wait=20for=20=20 that.=20That=20they=20haven't=20done=20so=20yet=20is=20disappointing.=20I= =20was=20asking=20for=20=20 it=20pretty-please=20with=20sugar=20on=20top=20in=20August=20'04=20at=20C= rypto,=20and=20we're=20=20 still=20waiting.=20But=20--=20they=20have=20their=20reasons,=20whatever=20= they=20are.=20If=20=20 someone=20finds=20the=20wait=20unacceptable,=20then=20there's=20an=20obvi= ous=20workaround=20=20 --=20use=20RSA=20with=20SHA-256. I=20don't=20think=20we=20need=20to=20do=20anything=20with=20the=20truncat= ion=20issue.=20The=20=20 answer=20of=20how=20to=20truncate=20the=20wide=20SHAs=20is=20answered=20f= or=20us=20in=20FIPS=20180.=20=20 The=20answer=20of=20what=20to=20do=20with=20DSA=20is=20=22Don't.=22=20We=20= can=20wait=20for=20NIST.=20If=20=20 we=20don't=20we're=20going=20to=20have=20to=20do=20what=20they=20say,=20a= nyway.=20Why=20make=20more=20=20 work? The=20second=20issue,=20using=20salted=20hashes=20(I=20prefer=20this=20to= =20=22randomized=22),=20=20 is=20more=20interesting=20technologically,=20but=20there=20are=20still=20= a=20number=20of=20=20 extremely=20important=20issues=20open=20about=20them. The=20first=20open=20issue=20is=20their=20expected=20security=20when=20co= mpared=20both=20to=20=20 the=20unsalted=20version=20and=20comparable=20other=20functions.=20For=20= example,=20we=20=20 know=20that=20SHA-1=20should=20have=2080=20bits=20of=20security=20and=20d= oesn't.=20Will=20as=20=20 salted=20SHA-1=20have=2080=20bits=20of=20security?=20What=20makes=20us=20= think=20so?=20SHA-256=20=20 should=20have=20128=20bits=20of=20security,=20and=20many=20of=20us=20(I=20= know=20I=20am=20one)=20=20 expect=20it=20to=20have=20flaws.=20However,=20do=20we=20expect=20it=20to=20= have=20less=20than=2080=20=20 bits=20of=20security?=20I=20don't. It=20is=20a=20fair=20criticism=20of=20our=20history=20of=20designing=20ha= sh=20functions=20that=20=20 we've=20tweaked=20them=20rather=20than=20redesign=20them.=20But=20salting= =20the=20hash=20is=20=20 also=20a=20tweak.=20If=20SHA-256=20is=20so=20broken=20that=20alone=20it=20= has=20less=20security=20=20 than=2080=20bits,=20what=20could=20possibly=20make=20us=20think=20that=20= a=20tweak=20like=20=20 salting=20will=20actually=20increase=20security?=20I=20wrote=20a=20long=20= note=20to=20the=20=20 CFRG=20list=20on=20this=20theme,=20which=20I=20will=20be=20happy=20to=20r= epost=20here.=20I=20=20 believe=20that=20whatever=20flaws=20SHA-256=20might=20have,=20it=20has=20= enough=20security=20=20 to=20last=20us=20for=20five=20to=20fifteen=20years=20at=2080=20to=20100=20= bits=20of=20security.=20My=20=20 rationale=20for=20my=20opinion=20is=20in=20that=20CFRG=20email. The=20second=20issue=20is=20the=20performance=20of=20the=20salted=20hash=20= functions.=20In=20=20 discussions=20in=20the=20CFRG=20list,=20Dan=20Bernstein=20has=20suggested= =20that=20salted=20=20 MD5=20has=20similar=20performance=20to=20unsalted=20SHA-256.=20If=20this=20= is=20so,=20then=20=20 whyever=20would=20you=20use=20salted=20MD5?=20Surely=20no=20one=20suggest= s=20that=20SHA-256=20=20 has=20fewer=20than=2064=20bits=20of=20security,=20do=20they?=20If=20salte= d=20MD5=20and=20SHA-256=20=20 are=20similar=20in=20performance,=20then=20the=20=2Aonly=2A=20reason=20to= =20consider=20using=20=20 salted=20MD5=20is=20that=20whatever=20protocol=20you're=20using=20can=20s= upport=20a=20128-bit=20=20 hash,=20but=20not=20a=20256-bit=20hash.=20And=20even=20in=20that=20case,=20= the=20=2Areal=2A=20=20 question=20we=20should=20be=20asking=20is=20whether=20truncated=20SHA-256= =20has=2064=20bits=20=20 of=20security=21 It=20seems=20to=20me=20that=20if=20there=20are=20questions=20that=20a=20h= ashing=20working=20group=20=20 should=20be=20asking,=20they=20are=20not=20the=20ones=20we're=20asking,=20= but=20other=20ones=20=20 that=20include: =2A=20What=20is=20the=20security=20of=20a=20salted=20hash=20function?=20D= oes=20salted=20MD5=20have=20=20 64=20bits=20of=20security?=20Does=20salted=20SHA-1=20have=2080=20bits=20o= f=20security?=20Does=20=20 salted=20SHA-256=20have=20128=20bits=20of=20security?=20Why=20do=20we=20t= hink=20this?=20I've=20=20 seen=20no=20reasoning=20nor=20metrics. =2A=20What=20is=20the=20security=20of=20a=20truncated=20hash=20function?=20= Examples:=20Suppose=20=20 SHA-256=20has=20110=20bits=20of=20security=20(if=20it=20is=20as=20broken=20= as=20SHA-1,=20this=20is=20=20 my=20predicted=20security=20value).=20If=20you=20truncate=20SHA-256=20to=20= 128=20bits,=20does=20=20 that=20mean=20that=20it=20has=2055=20bits=20of=20security?=20Or=20does=20= it=20mean=20that=20it=20has=20=20 64=20bits=20of=20security?=20Or=20something=20in=20the=20middle?=20Why=20= do=20we=20think=20this?=20=20 What=20do=20we=20expect=20its=20security=20to=20be=20if=20you=20truncate=20= it=20to=20160=20bits=20and=20=20 why? =2A=20What=20is=20the=20performance=20of=20a=20salted=20hash=20function?=20= Bernstein's=20claim=20=20 that=20salted=20MD5=20has=20similar=20performance=20to=20SHA-256=20has=20= gone=20=20 unchallenged,=20and=20he=20himself=20has=20noted=20this=20silence. =2A=20Are=20there=20other=20constructions=20we=20can=20perform=20that=20g= ive=20us=20security=20=20 over=20the=20naked=20hash=20function,=20but=20require=20less=20work=20tha= n=20salting?=20For=20=20 example,=20suppose=20we=20took=20SHA-256=20and=20folded=20its=20halves,=20= XORing=20them=20=20 together.=20Does=20this=20give=20us=20more=20security=20than=20straight=20= truncation?=20If=20=20 not,=20why=20not=20(since=20it=20seems=20intuitive=20that=20folding=20wou= ld=20have=20at=20least=20=20 an=20eensy=20bit=20more=20security)?=20What=20other=20constructions=20cou= ld=20we=20make=20=20 that=20improve=20over=20raw=20truncation=20without=20the=20cost=20of=20sa= lting? Without=20answers=20to=20these=20questions,=20I=20don't=20see=20how=20thi= s=20working=20group=20=20 can=20give=20any=20meaningful=20results.=20Worse,=20I=20don't=20see=20how= =20any=20=20 recommendation=20of=20this=20group=20can=20improve=20over=20the=20simple=20= advice=20of=20=22use=20=20 SHA-256.=22=20If=20this=20BOF=20results=20in=20a=20working=20group,=20I=20= believe=20it=20=2Amust=2A=20=20 address=20the=20questions=20I=20outlined=20above,=20as=20well=20as=20the=20= issues=20I=20and=20=20 Bernstein=20have=20brought=20up=20in=20CFRG. If=20salted=20hashes=20are=20slower=20than=20wider=20hashes=20and=20the=20= wider=20hash=20has=20=20 enough=20security=20(enough=20being=20greater=20than=2064=20bits=20for=20= an=20MD5=20=20 replacement=20and=20greater=20than=2080=20bits=20for=20a=20SHA-1=20replac= ement),=20then=20we=20=20 should=20just=20use=20the=20wider=20hash=20and=20be=20done=20with=20it=20= --=20except=20when=20=20 that's=20not=20reasonable. It=20is=20only=20when=20the=20actual=20size=20of=20the=20hash=20function=20= is=20an=20issue=20and=20=20 you=20can't=20just=20switch=20to=20RSA=20that=20the=20simple=20advice=20i= sn't=20worth=20taking.=20=20 I=20can=20think=20of=20one=20such=20instance,=20and=20it's=20a=20draft=20= that=20I=20work=20on=20--=20=20 syslog-sign.=20In=20syslog-sign,=20space=20is=20at=20a=20premium,=20and=20= it=20uses=20DSA=20for=20=20 this=20reason.=20(A=20DSA=20signature=20is=20twice=20the=20size=20of=20th= e=20hash=20function=20=20 rather=20than=20proportional=20to=20the=20size=20of=20the=20key,=20and=20= syslog=20packets=20are=20=20 teenie.)=20Furthermore,=20the=20way=20that=20syslog-sign=20is=20used,=20i= t=20is=20far=20=20 better=20to=20have=20a=20160-bit=20hash=20with=2080=20bits=20of=20securit= y=20than=20it=20is=20to=20=20 have=20anything=20else=3B=20space=20is=20at=20that=20much=20of=20a=20prem= ium.=20In=20=2Athis=2A=20case,=20=20 I'd=20be=20happy=20to=20seemingly=20contradict=20my=20previous=20grouchin= ess=20and=20say,=20=20 =22Aw,=20just=20truncate=20SHA-256=20to=20160=20bits=20and=20use=20that=20= in=20DSA.=22=20There=20may=20=20 be=20other=20cases=20where=20the=20use=20model=20of=20the=20protocol=20mi= ght=20warrant=20that. But=20in=20the=20vast=20majority=20of=20cases,=20the=20simple=20advice: (1)=20If=20you're=20using=20DSA,=20grin=20and=20bear=20it=20until=20NIST=20= comes=20out=20with=20=20 wide=20DSA (2)=20If=20you're=20using=20RSA,=20switch=20to=20using=20SHA-256 (3)=20If=20you're=20using=20DSA=20and=20don't=20like=20(1),=20switch=20to= =20(2) is=20perfectly=20fine=20advice. =09Jon [1]=20=20 =3Chttp://csrc.nist.gov/publications/fips/fips180-2/fips180=20 -2withchangenotice.pdf=3E --=20 Jon=20Callas CTO,=20CSO PGP=20Corporation=20=20=20=20=20=20=20=20=20Tel:=20+1=20(650)=20319-9016 3460=20West=20Bayshore=20=20=20=20=20=20Fax:=20+1=20(650)=20319-9001 Palo=20Alto,=20CA=2094303=20=20=20=20=20PGP:=20ed15=205bdf=20cd41=20adfc=20= 00f3 USA=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=2028b6=2052bf=205a46=20bc98=20e63d --=20 Jon=20Callas CTO,=20CSO PGP=20Corporation=20=20=20=20=20=20=20=20=20Tel:=20+1=20(650)=20319-9016 3460=20West=20Bayshore=20=20=20=20=20=20Fax:=20+1=20(650)=20319-9001 Palo=20Alto,=20CA=2094303=20=20=20=20=20PGP:=20ed15=205bdf=20cd41=20adfc=20= 00f3 USA=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=2028b6=2052bf=205a46=20bc98=20e63d =0A ________________________________________________________________ This=20message=20could=20have=20been=20secured=20by=20PGP=20Universal.=20= To=20secure future=20messages=20from=20this=20sender,=20please=20click=20this=20link: https://keys.pgp.com/b/b.e?r=3Dhash=2540ietf.org=26n=3DI6LW=252FTFegliptj= mtozrp=252Bg=253D=253D _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Tue Jul 12 22:56:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXQ8-0004MW-9M; Tue, 12 Jul 2005 22:56:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXQ7-0004MR-5q for hash@megatron.ietf.org; Tue, 12 Jul 2005 22:56:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19329 for ; Tue, 12 Jul 2005 22:56:21 -0400 (EDT) Received: from mta3.pgp.com ([209.237.226.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsXsQ-0001n0-Fo for hash@ietf.org; Tue, 12 Jul 2005 23:25:39 -0400 Received: from localhost (ns1.pgp.com [63.251.255.3]) by mta3.pgp.com (Postfix) with ESMTP id 17E46A6ED for ; Tue, 12 Jul 2005 19:56:13 -0700 (PDT) Received: from mta3.pgp.com ([10.216.2.26]) by localhost (garfish-1.pgp.com [63.251.255.3]) (amavisd-new, port 10024) with LMTP id 86714-02-7 for ; Tue, 12 Jul 2005 19:56:11 -0700 (PDT) Received: from bonnie.pgp.com (keys.pgp.com [63.251.255.8]) by mta3.pgp.com (Postfix) with ESMTP id 3DCA5A6DD for ; Tue, 12 Jul 2005 19:56:09 -0700 (PDT) Received: from exchange.corp.pgp.com ([10.214.0.35]) by bonnie.pgp.com (PGP Universal service); Tue, 12 Jul 2005 19:56:10 -0700 Received: from bonnie.pgp.com ([63.251.255.8]) by exchange.corp.pgp.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 19:55:38 -0700 Received: from [172.16.1.2] ([10.214.2.201]) by bonnie.pgp.com (PGP Universal service); Tue, 12 Jul 2005 19:55:46 -0700 X-PGP-Universal: processed; by bonnie.pgp.com on Tue, 12 Jul 2005 19:55:46 -0700 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: Message-Id: <7a3a8ec3bddece6efc9986d48093837c@pgp.com> From: Jon Callas Date: Tue, 12 Jul 2005 19:56:00 -0700 To: hash@ietf.org X-Mailer: Apple Mail (2.622) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 13 Jul 2005 02:55:38.0715 (UTC) FILETIME=[596C8AB0:01C58756] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hash] Sorry about multiples. X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org Apologies=20for=20three=20copies.=20I'm=20on=20a=20flaky=20hotel=20networ= k. =09Jon --=20 Jon=20Callas CTO,=20CSO PGP=20Corporation=20=20=20=20=20=20=20=20=20Tel:=20+1=20(650)=20319-9016 3460=20West=20Bayshore=20=20=20=20=20=20Fax:=20+1=20(650)=20319-9001 Palo=20Alto,=20CA=2094303=20=20=20=20=20PGP:=20ed15=205bdf=20cd41=20adfc=20= 00f3 USA=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=2028b6=2052bf=205a46=20bc98=20e63d =0A ________________________________________________________________ This=20message=20could=20have=20been=20secured=20by=20PGP=20Universal.=20= To=20secure future=20messages=20from=20this=20sender,=20please=20click=20this=20link: https://keys.pgp.com/b/b.e?r=3Dhash=2540ietf.org=26n=3DI6LW=252FTFegliptj= mtozrp=252Bg=253D=253D _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Wed Jul 13 15:20:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsmmU-0002TS-Ez; Wed, 13 Jul 2005 15:20:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsmmS-0002Rh-W9 for hash@megatron.ietf.org; Wed, 13 Jul 2005 15:20:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13558 for ; Wed, 13 Jul 2005 15:20:27 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsnEv-0007o1-Dq for hash@ietf.org; Wed, 13 Jul 2005 15:49:54 -0400 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DJKLxr071341; Wed, 13 Jul 2005 12:20:21 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <54646b48339836e44f8917d434bb3e5b@pgp.com> References: <54646b48339836e44f8917d434bb3e5b@pgp.com> Date: Wed, 13 Jul 2005 12:19:49 -0700 To: Jon Callas , hash@ietf.org From: Paul Hoffman Subject: Re: [Hash] BOF Goals Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id j6DJKLxr071341 X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org This guidance is provided for unforeseen applications in order to=20 provide interoperability. A standard method for truncating hash=20 function outputs is provided strictly as a convenience for=20 implementers and application developers. No claims are made about the=20 suitability of truncating the hash output or about the security level=20 obtained by truncating the hash output. The proper use of truncated=20 hash outputs is an application-level issue. Truncating the hash function output can impact the security of an=20 application. For example, applications that use the truncated hash=20 output risk attacks based on confusion between different parties=20 about the specific amount of truncation used, and the specific hash=20 function whose output was truncated. Any application using truncated=20 hash output is responsible for ensuring that the truncation amount=20 and the hash function used are known to all parties, with no chance=20 of ambiguity. Truncated hash output shall not be used in place of the full hash=20 output by standardized applications that reference this Standard,=20 e.g. digital signatures (FIPS 186-2) or keyed hash functions used for=20 message authentication (FIPS 198). At 7:37 PM -0700 7/12/05, Jon Callas wrote: >It's therefore a bit unusual for me to ask one of my own clich=E9=20 >questions: What problem are we trying to solve? and have that be=20 >both genuine and backed with my own puzzlement. I don't know what we=20 >are doing, expect, plan, or even hope. This is not a Working Group to produce a protocol. As the proposed=20 charter says, "The proposed working group responds to the current=20 state of research in this area. However, additional research is=20 likely to provide new insights as the working group progresses." In=20 other words, our job is to help in an area that people didn't feel=20 the need for help before, namely the use of hashes in protocols. >As it has been stated, there are two problems we're looking at: > >(1) truncating existing wide hashes for use in systems like DSA. > >(2) to explore "randomized" hashes. Those are only the first two. There is a third problem we may be=20 looking at in the longer term: "The optional second phase will=20 identify one or more standards-track one-way hash functions that=20 fulfill the requirements stated in the BCP documents developed in the=20 first phase. Guidance will also be developed to assist protocol developers in the selection among the=20 standards-track one-way hash functions." >FIPS-180, which describes all of the SHA-family hashes [1] answers=20 >this question on page 73: > > "Some applications may require a hash function with an output size > (i.e., message digest size) different than those provided by the > hash functions in this Standard. In such cases, a truncated hash > output may be used, whereby a hash function with a larger output > size is applied to the data to be hashed, and the resulting output > (i.e., message digest) is truncated by selecting an appropriate > number of the leftmost bits. For example, if an output of 96 bits i= s > desired, the SHA256 hash function could be used (e.g., because it i= s > available to the application), and the leftmost 96 bits of the > output are selected as the message digest, discarding the rightmost > 160 bits of the SHA-256 output." >NIST is supposed to release an addendum to DSA for wide hashes and=20 >keys bigger than 1024 bits. I see nothing on the NIST site that says that they will release this=20 addendum, nor have I heard it from the NIST folks I have spoken with.=20 That is not to say that they aren't working on it, just that we=20 shouldn't assume that the addendum is a fact. >The *correct* thing for us to do is wait for that. Some folks at NIST have told us (quite informally) that us working on=20 the truncation issue would be a good thing. Certainly, if it turns=20 out that simple truncation can be shown to be as safe as any other=20 shortening method, that would help DSA because it would make the=20 algorithm much simpler. This is why I asked in the previous message=20 for input on research in this area. >If someone finds the wait unacceptable, then there's an obvious=20 >workaround -- use RSA with SHA-256. This is simplistic on a couple of levels. - There are many properties where DSA and RSA differ, and a protocol=20 developer may have chose DSA for one of those. - The assumption of SHA-256 seems rash. In particular, we don't yet=20 have information preimage attacks on SHA-1, we haven't specified=20 which kinds of uses of hashes with digital signatures are affected by=20 the reduction in collision strength, and we haven't looked at whether=20 other formulations of hashes might appear to more immune to attacks=20 related to the ones we know now. - Changing protocols is very difficult for typical users. They may be=20 using a protocol in which there is no identifier for "RSA with=20 SHA-256". They may be using the algorithm for long-lived signatures,=20 where switching means using multiple protocols with different=20 properties. Having some users change while others don't can cause=20 long-term problems for both groups: that's why the IETF tries to be=20 clear which algorithms to use, and when. >The answer of how to truncate the wide SHAs is answered for us in FIPS 1= 80. If you only read the paragraph you quoted, yes. The rest of that=20 section from FIPS 180 says: >This guidance is provided for unforeseen applications in order to=20 >provide interoperability. A standard method for truncating hash=20 >function outputs is provided strictly as a convenience for=20 >implementers and application developers. No claims are made about=20 >the suitability of truncating the hash output or about the security=20 >level obtained by truncating the hash output. The proper use of=20 >truncated hash outputs is an application-level issue. > >Truncating the hash function output can impact the security of an=20 >application. For example, applications that use the truncated hash=20 >output risk attacks based on confusion between different parties=20 >about the specific amount of truncation used, and the specific hash=20 >function whose output was truncated. Any application using=20 >truncated hash output is responsible for ensuring that the=20 >truncation amount and the hash function used are known to all=20 >parties, with no chance of ambiguity. > >Truncated hash output shall not be used in place of the full hash=20 >output by standardized applications that reference this Standard,=20 >e.g. digital signatures (FIPS 186-2) or keyed hash functions used=20 >for message authentication (FIPS 198). Not wearing my BOF chair hat: the little that is said in FIPS 180 is=20 not sufficient to decide that we know enough about the issue to=20 decide anything. The cryptographic community is certainly able to=20 deal with this issue better than the first paragraph of the section=20 in FIPS 180. >The answer of what to do with DSA is "Don't." We can wait for NIST.=20 >If we don't we're going to have to do what they say, anyway. Why=20 >make more work? Because the "more work" may be valuable research, even for NIST. To be clear: I'm not saying we should have truncation in our WG=20 charter, and Jon is the first so far to speak up to say we shouldn't.=20 Hearing from others on the mailing list would be useful. >The second issue, using salted hashes (I prefer this to=20 >"randomized"), is more interesting technologically, but there are=20 >still a number of extremely important issues open about them. Exactly! >The first open issue is their expected security when compared both=20 >to the unsalted version and comparable other functions. For example,=20 >we know that SHA-1 should have 80 bits of security and doesn't. Will=20 >as salted SHA-1 have 80 bits of security? What makes us think so?=20 >SHA-256 should have 128 bits of security, and many of us (I know I=20 >am one) expect it to have flaws. However, do we expect it to have=20 >less than 80 bits of security? I don't. This paragraph again assumes a move to SHA-256. It might be better to=20 deal with the tradeoffs, as is done in the one Internet Draft we=20 have,=20 . >In discussions in the CFRG list, Dan Bernstein has suggested that=20 >salted MD5 has similar performance to unsalted SHA-256. Seeing actual numbers on this would be a great boon to the discussion. >It seems to me that if there are questions that a hashing working=20 >group should be asking, they are not the ones we're asking, but=20 >other ones that include: > >* What is the security of a salted hash function? Does salted MD5=20 >have 64 bits of security? Does salted SHA-1 have 80 bits of=20 >security? Does salted SHA-256 have 128 bits of security? Why do we=20 >think this? I've seen no reasoning nor metrics. Good questions, and ones we should answer. >* What is the security of a truncated hash function? Examples:=20 >Suppose SHA-256 has 110 bits of security (if it is as broken as=20 >SHA-1, this is my predicted security value). If you truncate SHA-256=20 >to 128 bits, does that mean that it has 55 bits of security? Or does=20 >it mean that it has 64 bits of security? Or something in the middle?=20 >Why do we think this? What do we expect its security to be if you=20 >truncate it to 160 bits and why? Good questions, and ones we should answer. So, now you want to keep=20 the item in the WG charter? :-) >* What is the performance of a salted hash function? Bernstein's=20 >claim that salted MD5 has similar performance to SHA-256 has gone=20 >unchallenged, and he himself has noted this silence. These should not be difficult values to start generating. >* Are there other constructions we can perform that give us security=20 >over the naked hash function, but require less work than salting?=20 >For example, suppose we took SHA-256 and folded its halves, XORing=20 >them together. Does this give us more security than straight=20 >truncation? If not, why not (since it seems intuitive that folding=20 >would have at least an eensy bit more security)? What other=20 >constructions could we make that improve over raw truncation without=20 >the cost of salting? Good questions, and ones we should answer. >Without answers to these questions, I don't see how this working=20 >group can give any meaningful results. Worse, I don't see how any=20 >recommendation of this group can improve over the simple advice of=20 >"use SHA-256." If this BOF results in a working group, I believe it=20 >*must* address the questions I outlined above, as well as the issues=20 >I and Bernstein have brought up in CFRG. A specific list of issues on *this* list, not on CFRG, would help us=20 finalize the charter. >If salted hashes are slower than wider hashes and the wider hash has=20 >enough security (enough being greater than 64 bits for an MD5=20 >replacement and greater than 80 bits for a SHA-1 replacement), then=20 >we should just use the wider hash and be done with it -- except when=20 >that's not reasonable. Having a description of when it is reasonable also seems to be=20 valuable to be written down. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Fri Jul 15 08:45:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtPZ0-000498-7E; Fri, 15 Jul 2005 08:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtPYz-000491-CU for hash@megatron.ietf.org; Fri, 15 Jul 2005 08:45:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01552 for ; Fri, 15 Jul 2005 08:45:07 -0400 (EDT) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtQ1l-0007IN-Tw for hash@ietf.org; Fri, 15 Jul 2005 09:14:56 -0400 Received: (qmail 91496 invoked by uid 1016); 15 Jul 2005 12:45:30 -0000 Date: 15 Jul 2005 12:45:30 -0000 Message-ID: <20050715124530.91495.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: hash@ietf.org Subject: Re: [Hash] BOF Goals References: <54646b48339836e44f8917d434bb3e5b@pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org Another 160-bit possibility to consider is RIPEMD-160. RIPEMD-160 has been around since 1996 and is faster than 160-bit-truncated SHA-256. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Fri Jul 15 10:16:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQzE-0007H9-4Z; Fri, 15 Jul 2005 10:16:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQzC-0007E3-I9 for hash@megatron.ietf.org; Fri, 15 Jul 2005 10:16:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08692 for ; Fri, 15 Jul 2005 10:16:15 -0400 (EDT) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtRS0-0001tp-KO for hash@ietf.org; Fri, 15 Jul 2005 10:46:06 -0400 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j6FEGDrY029725; Fri, 15 Jul 2005 07:16:13 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j6FEGDLT029720; Fri, 15 Jul 2005 07:16:13 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 15 Jul 2005 07:16:13 -0700 (PDT) From: "william(at)elan.net" To: "D. J. Bernstein" Subject: Re: [Hash] BOF Goals In-Reply-To: <20050715124530.91495.qmail@cr.yp.to> Message-ID: References: <54646b48339836e44f8917d434bb3e5b@pgp.com> <20050715124530.91495.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: hash@ietf.org X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org On Fri, 15 Jul 2005, D. J. Bernstein wrote: > Another 160-bit possibility to consider is RIPEMD-160. RIPEMD-160 has > been around since 1996 and is faster than 160-bit-truncated SHA-256. If people don't know (and in the future please provide references to algorithms whenever possible), good page about RIPEMD160 is: http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html Regarding being faster then SHA256, that maybe true but RIPEMD itself is not as fast as SHA functions and there has not been enough study of RIPEMD to make certain it does not have same potential collision problems. -- William Leibzon Elan Networks william@elan.net _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Fri Jul 15 20:16:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtaMR-0005Ft-2q; Fri, 15 Jul 2005 20:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtaMP-0005Fo-4W for hash@megatron.ietf.org; Fri, 15 Jul 2005 20:16:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08968 for ; Fri, 15 Jul 2005 20:16:48 -0400 (EDT) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtapG-0004Ae-LY for hash@ietf.org; Fri, 15 Jul 2005 20:46:44 -0400 Received: by machshav.com (Postfix, from userid 512) id 1A86BFB28A; Fri, 15 Jul 2005 20:16:44 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DBC2DFB284; Fri, 15 Jul 2005 20:16:42 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id A7FE33BFEFC; Fri, 15 Jul 2005 20:16:41 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: hash From: "Steven M. Bellovin" To: Paul Hoffman Subject: Re: [Hash] Proposed agenda for IETF 63 in Paris In-Reply-To: Your message of "Wed, 06 Jul 2005 08:27:38 PDT." Mime-Version: 1.0 Content-Type: text/plain Date: Fri, 15 Jul 2005 20:16:41 -0400 Message-Id: <20050716001641.A7FE33BFEFC@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Hash WG X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org In message , Paul Hoffman writes: >We have asked for a one-hour slot for the BOF because there is not >much to work out yet. I propose that the hour be spent as: > >1) 30 minutes - charter agreement >2) 30 minutes - presentation(s) on truncation and salting proposals and issues > >Because this is a BOF, not a working group, we need to be sure we >have agreement on the charter before the IESG considers whether or >not to really form the WG. We'll start with the last charter I posted >(amended as Ben pointed out to make it less ASN.1esque) and see how >the folks in the room feel. > >Does this agenda make sense? > Paul, Eric Rescorla and I would like a few minutes to discuss our new paper "Deploying a New Hash Algorithm". A draft is available at http://www.cs.columbia.edu/~smb/papers/new-hash.ps and http://www.cs.columbia.edu/~smb/papers/new-hash.pdf . (Our apologies that it is not in I-D format -- it is aimed at the NIST Cryptographic Hash Workshop, which has different formatting requirements. Here's the abstract: As a result of recent discoveries, the strength of hash functions such as MD5 and SHA-1 have been called into question. Regardless of whether or not it is necessary to move away from those now, it is clear that it will be necessary to do so in the not-too-distant future. This poses a number of challenges, especially for certificate-based protocols. We analyze S/MIME, TLS, and IPsec. All three require protocol or implementation changes. We explain the necessary changes, show how the conversion can be done, and list what measures should be taken immediately. _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Sat Jul 16 14:15:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrCO-0006FO-Nt; Sat, 16 Jul 2005 14:15:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrCK-0006EQ-IB for hash@megatron.ietf.org; Sat, 16 Jul 2005 14:15:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18705 for ; Sat, 16 Jul 2005 14:15:33 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtqAM-00009k-4n for hash@ietf.org; Sat, 16 Jul 2005 13:09:31 -0400 Received: from [10.20.30.249] (d12-191.rb.gh.centurytel.net [69.29.203.191]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6GGdFJl059154; Sat, 16 Jul 2005 09:39:18 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050716001641.A7FE33BFEFC@berkshire.machshav.com> References: <20050716001641.A7FE33BFEFC@berkshire.machshav.com> Date: Sat, 16 Jul 2005 09:38:12 -0700 To: "Steven M. Bellovin" From: Paul Hoffman Subject: Re: [Hash] Proposed agenda for IETF 63 in Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Hash WG X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org At 8:16 PM -0400 7/15/05, Steven M. Bellovin wrote: >Paul, Eric Rescorla and I would like a few minutes to discuss our new >paper "Deploying a New Hash Algorithm". Sounds good to me. Are there other suggestions for the Hash BOF agenda? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Wed Jul 20 18:17:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvMsV-000124-5f; Wed, 20 Jul 2005 18:17:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvMsT-00011F-Bq for hash@megatron.ietf.org; Wed, 20 Jul 2005 18:17:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28051 for ; Wed, 20 Jul 2005 18:17:17 -0400 (EDT) Received: from mta3.pgp.com ([209.237.226.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvNMK-0005i3-5n for hash@ietf.org; Wed, 20 Jul 2005 18:48:13 -0400 Received: from localhost (ns1.pgp.com [63.251.255.3]) by mta3.pgp.com (Postfix) with ESMTP id 2A45BA663 for ; Wed, 20 Jul 2005 15:16:56 -0700 (PDT) Received: from mta3.pgp.com ([10.216.2.26]) by localhost (garfish-1.pgp.com [63.251.255.3]) (amavisd-new, port 10024) with LMTP id 01892-01-6 for ; Wed, 20 Jul 2005 15:16:44 -0700 (PDT) Received: from bonnie.pgp.com (keys.pgp.com [63.251.255.8]) by mta3.pgp.com (Postfix) with ESMTP id 0C9BCA66E for ; Wed, 20 Jul 2005 15:16:42 -0700 (PDT) Received: from exchange.corp.pgp.com ([10.214.0.35]) by bonnie.pgp.com (PGP Universal service); Wed, 20 Jul 2005 15:16:42 -0700 Received: from bonnie.pgp.com ([63.251.255.8]) by exchange.corp.pgp.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Jul 2005 15:16:10 -0700 Received: from [63.251.255.205] ([63.251.255.205]) by bonnie.pgp.com (PGP Universal service); Wed, 20 Jul 2005 15:16:10 -0700 X-PGP-Universal: processed; by bonnie.pgp.com on Wed, 20 Jul 2005 15:16:10 -0700 In-Reply-To: References: <54646b48339836e44f8917d434bb3e5b@pgp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <61c984f5d0b959ce1908b985a327a225@pgp.com> From: Jon Callas Subject: Re: [Hash] BOF Goals Date: Wed, 20 Jul 2005 15:16:21 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.622) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 20 Jul 2005 22:16:10.0014 (UTC) FILETIME=[A1CDD3E0:01C58D78] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable Cc: hash@ietf.org X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org Paul's=20asked=20me=20to=20discuss=20more,=20particularly=20so=20we=20can= =20have=20more=20email=20 discussions=20prior=20to=20Paris.=20He's=20also=20rightly=20pointed=20out= =20that=20my=20CFRG=20 discussion=20isn't=20here,=20and=20without=20good=20cross-referencing,=20= I=20shouldn't=20 assume=20people=20here=20have=20read=20it.=20So=20here's=20the=20note=20t= hat=20I=20sent=20some=20 time=20ago: Begin=20forwarded=20message: From:=20Jon=20Callas=20=3Cjon=40callas.org=3E Date:=2013=20June=202005=203:38:10=20PM=20PDT To:=20cfrg=40ietf.org Subject:=20Re:=20[Cfrg]=20new=20i-d:=20randomized=20hashing On=2013=20Jun=202005,=20at=207:18=20AM,=20Ben=20Laurie=20wrote: =3E=20D.=20J.=20Bernstein=20wrote: =3E=3E=20Ben=20Laurie=20writes: =3E=3E=3E=20It=20seems=20to=20me=20that=20life=20would=20be=20generally=20= easier=20if=20you=20defined=20a=20 =3E=3E=3E=20modified=20hash=20function=20H_r(m)=20and=20then=20constructe= d=20H'(m)=3D(r,H_r(m)).=20 =3E=3E=3E=20This=20way=20transport=20of=20r=20happens=20automatically,=20= but=20the=20hash=20gets=20 =3E=3E=3E=20wider. =3E=3E=20Even=20better,=20use=20the=20extra=20space=20for=20a=20longer=20= _deterministic_=20hash.=20 =3E=3E=20For =3E=3E=20example,=20instead=20of=20using=2096=20bits=20for=20r=20and=2016= 0=20bits=20for=20SHA-1=20output, =3E=3E=20simply=20use=20SHA-256. =3E =3E=20That=20assumes=20we're=20confident=20SHA-256=20won't=20have=20simil= ar=20flaws. =3E Ben=20brings=20up=20a=20good=20point,=20but=20I=20side=20with=20Dan=20Ber= nstein.=20I=20think=20 SHA-256=20is=20the=20right=20way=20to=20go,=20and=20we=20don't=20need=20a= nything=20else=20until=20 we=20get=20new=20hash=20functions=20that=20have=20the=20attributes=20we=20= want. I=20am=20quite=20confident=20that=20SHA-256=20has=20similar=20flaws=20to=20= SHA-1=20and=20all=20 the=20others,=20but=20I=20think=20the=20right=20thing=20to=20do=20for=20t= he=20time=20being=20is=20to=20 just=20use=20it.=20This=20is=20what=20we've=20done=20in=20PGP. Here's=20my=20reasoning=20why: SHA-1=20is=20supposed=20to=20have=2080=20bits=20of=20security.=20Our=20pr= esent=20knowledge=20of=20 it=20has=20it=20around=2069.=20(I=20will=20handwave=20what=20this=20means= ,=20because=20yes,=20I=20 know=20that=20this=20isn't=20pre-image=20collision,=20it=20doesn't=20appl= y=20to=20hmacs=20or=20 similar=20constructions,=20etc.)=20It's=20thus=20missing=2011=20bits=20of= =20security. SHA-256=20is=20supposed=20to=20have=20128=20bits=20of=20security.=20If=20= we=20assume=20a=20 similar=20flaw,=20SHA-256=20should=20be=20missing=20about=2017.6=20bits=20= of=20security.=20 (That's=20(11/80)=20=2A=20128.) Let's=20take=20that=2017.6=20and=20round=20it=20up=20to=2038.=20Yup,=20th= irty-eight.=20Not=20 twenty-eight,=20not=20eighteen.=20I=20have=20a=20cynical=20rounding=20fun= ction.=20That=20 gives=20us=2090=20bits=20of=20security. At=2090=20bits=20of=20security,=20I'm=20happy=20to=20live=20with=20SHA-25= 6=20for=20a=20while.=20I=20 believe=20that=20the=20hash=20function=20we=20=2Awant=2A=20to=20be=20usin= g=20hasn't=20been=20 written=20yet.=20(My=20guess=20is=20that=20it=20will=20be=20announced=20a= round=20the=20time=20of=20 Asiacrypt=20'06,=20and=20papers=20published=20in=20FSE=20'07.=20We're=20n= ot=20going=20to=20be=20 comfortable=20with=20it=20until=20early=20'08,=20but=20will=20still=20whi= ne=20and=20mutter=20 about=20it=20until=20September=20'09.=20The=20FIPS=20for=20it=20won't=20a= ppear=20--=20sorry,=20 I'm=20not=20going=20to=20make=20that=20cheap=20joke=3B=20NIST=20will=20ac= tually=20make=20a=20FIPS=20 before=20the=20whining=20stops.) At=2090=20bits=20of=20security,=20we=20can=20live=20with=20it=20for=20ano= ther=20five=20years.=20And=20 this=20assumes=20my=20rounding=20function,=20which=20scopes=20the=20=22si= milar=22=20flaw=20in=20 SHA-256=20to=20actually=20be=20a=20million=20times=20more=20devastating=20= than=20the=20SHA-1=20 one.=20If=20my=20rounding=20function=20should=20round=2017.6=20to=2028=20= instead,=20then=20 SHA-256=20will=20last=20for=20another=2015=20years=20just=20fine.=20I=20t= hink=20that=20factor=20 of=201024=20takes=20into=20account=20a=20additional=20decade=20of=20semic= onductor=20 improvements=20adequately.=20If=20my=20rounding=20function=20should=20rou= nd=2017.6=20to=20 18,=20then=20SHA-256,=20while=20flawed,=20can=20live=20out=20its=20natura= l=20life.=20Normal=20 engineering=20improvements=20can=20dispose=20of=20it=20sometime=20in=20th= e=20indefinite=20 future=20--=20probably=20around=20'09.=20(Oh,=20and=20if=20it=20were=2080= ,=20then=20we=20could=20 use=20it=20for=20all=20the=20same=20things=20we=20expect=20SHA-1=20to=20d= o=20at=20the=20mere=20cost=20 of=20being=20slow=20and=20big.) We=20also=20know=20that=20there's=20no=20real=20mathematical=20insight=20= that=20Wang=20and=20 others=20have.=20It=20is=20true=20that=20attacks=20don't=20get=20worse,=20= they=20only=20get=20 better,=20but=20there's=20no=20reason=20to=20think=20that=20the=20attacks= =20on=20any=20of=20the=20 hash=20functions=20are=20going=20to=20get=20different=20in=20kind,=20mere= ly=20in=20degree.=20I=20 believe=20that=20SHA-256=20has=20at=20least=20100=20bits=20of=20security=20= in=20it.=20That's=20 why=20my=20gedankenexperiment=20backs=20it=20down=20to=2090. Any=20number=20of=20people=20have=20observed=20that=20we=20have=20taken=20= one=20basic=20 construction=20for=20hash=20functions=20has=20been=20a=20bunch=20of=20twe= aks,=20rather=20than=20 a=20design=20change.=20Everything=20we=20have=20has=20at=20some=20level=20= the=20same=20 architecture.=20My=20concern=20about=20randomized=20hashing=20is=20that=20= I=20see=20it=20as=20 another=20tweak.=20Yes,=20it's=20a=20tweak=20in=20a=20higher=20level=20co= nstruct,=20but=20it's=20 still=20a=20tweak.=20It's=20a=20tweak=20that=20requires=20more=20fundamen= tal=20changes=20to=20 the=20protocols=20and=20systems=20that=20=2Ause=2A=20hash=20functions=20t= han=20merely=20 swapping=20in=20a=20new=20function.=20That=20one=20is=20bad=20enough.=20I= =20also=20see=20no=20 reason=20why=20this=20is=20going=20to=20change=20our=20core=20mechanisms=20= of=20operating.=20If=20 we=20learn=20how=20to=20make=20a=20good=20hash=20function=20sometime=20be= tween=202010=20and=20 2020,=20then=20that's=20within=20the=20pragmatic=20safety=20consideration= s=20of=20 SHA-256.=20If=20something=20extraordinary=20happens,=20then=20gosh=20darn= it,=20SHA-512=20 should=20work.=20I=20can't=20believe=20that=20SHA-512=20will=20have=20les= s=20than=20128=20bits=20 of=20security.=20I'm=20sorry,=20I=20don't.=20If=20I'm=20proved=20wrong,=20= then=20we=20really,=20 really=20don't=20know=20what=20we're=20doing,=20and=20there=20are=20many=20= dramatic=20things=20 in=20information=20security=20we=20have=20to=20change. So=20to=20sum=20up=20--=20this=20is=20all=20interesting,=20to=20make=20ra= ndomized=20hashing,=20 but=20why=20should=20I=20trust=20it,=20why=20should=20I=20convert=20to=20= it?=20Why=20am=20I=20not=20 jumping=20from=20the=20frying=20pan=20into=20another=20frying=20pan?=20Es= pecially=20when=20my=20 present=20plan=20is=20to=20use=20SHA-256,=20and=20if=20that=20is=20unacce= ptable,=20SHA-512.=20 Does=20anyone=20believe=20that=20they're=20really=20that=20broken?=20Or=20= to=20sum=20up=20my=20 summary,=20in=20waiting=20for=20the=20right=20hash=20function,=20am=20I=20= waiting=20for=20 Godot? =09Jon _______________________________________________ Cfrg=20mailing=20list Cfrg=40ietf.org https://www1.ietf.org/mailman/listinfo/cfrg =0A ________________________________________________________________ This=20message=20could=20have=20been=20secured=20by=20PGP=20Universal.=20= To=20secure future=20messages=20from=20this=20sender,=20please=20click=20this=20link: https://keys.pgp.com/b/b.e?r=3Dhash=2540ietf.org=26n=3DI6LW=252FTFegliptj= mtozrp=252Bg=253D=253D _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Wed Jul 20 19:26:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNxb-00061C-Rs; Wed, 20 Jul 2005 19:26:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNxa-000617-JQ for hash@megatron.ietf.org; Wed, 20 Jul 2005 19:26:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15419 for ; Wed, 20 Jul 2005 19:26:39 -0400 (EDT) Received: from mta3.pgp.com ([209.237.226.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvORU-0005VJ-KY for hash@ietf.org; Wed, 20 Jul 2005 19:57:38 -0400 Received: from localhost (ns1.pgp.com [63.251.255.3]) by mta3.pgp.com (Postfix) with ESMTP id 58AC9A65F for ; Wed, 20 Jul 2005 16:26:28 -0700 (PDT) Received: from mta3.pgp.com ([10.216.2.26]) by localhost (garfish-1.pgp.com [63.251.255.3]) (amavisd-new, port 10024) with LMTP id 04633-02 for ; Wed, 20 Jul 2005 16:26:21 -0700 (PDT) Received: from bonnie.pgp.com (keys.pgp.com [63.251.255.8]) by mta3.pgp.com (Postfix) with ESMTP id 41CD6A628 for ; Wed, 20 Jul 2005 16:26:21 -0700 (PDT) Received: from exchange.corp.pgp.com ([10.214.0.35]) by bonnie.pgp.com (PGP Universal service); Wed, 20 Jul 2005 16:26:21 -0700 Received: from bonnie.pgp.com ([63.251.255.8]) by exchange.corp.pgp.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Jul 2005 16:26:14 -0700 Received: from [63.251.255.205] ([63.251.255.205]) by bonnie.pgp.com (PGP Universal service); Wed, 20 Jul 2005 16:26:14 -0700 X-PGP-Universal: processed; by bonnie.pgp.com on Wed, 20 Jul 2005 16:26:14 -0700 In-Reply-To: References: <54646b48339836e44f8917d434bb3e5b@pgp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <13003cae1feec2d28df35bdabd033a30@pgp.com> From: Jon Callas Subject: Re: [Hash] BOF Goals Date: Wed, 20 Jul 2005 16:26:36 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.622) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 20 Jul 2005 23:26:14.0431 (UTC) FILETIME=[6BD4F2F0:01C58D82] X-Spam-Score: 0.0 (/) X-Scan-Signature: 94962611154c8404498b19f744990308 Content-Transfer-Encoding: quoted-printable Cc: hash@ietf.org X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org =3E=20This=20is=20not=20a=20Working=20Group=20to=20produce=20a=20protocol= .=20As=20the=20proposed=20 =3E=20charter=20says,=20=22The=20proposed=20working=20group=20responds=20= to=20the=20current=20 =3E=20state=20of=20research=20in=20this=20area.=20=20However,=20additiona= l=20research=20is=20 =3E=20likely=20to=20provide=20new=20insights=20as=20the=20working=20group= =20progresses.=22=20In=20 =3E=20other=20words,=20our=20job=20is=20to=20help=20in=20an=20area=20that= =20people=20didn't=20feel=20the=20 =3E=20need=20for=20help=20before,=20namely=20the=20use=20of=20hashes=20in= =20protocols. =3E Does=20it=20need=20a=20working=20group? I=20thought=20the=20I-D=20you=20and=20Bruce=20did=20was=20smashing.=20I=20= thought=20it=20 describes=20the=20current=20state=20of=20affairs=20quite=20well,=20especi= ally=20that=20the=20 main=20thing=20we=20know=20is=20the=20depth=20of=20what=20we=20don't=20kn= ow. Now,=20if=20what=20we'd=20do=20in=20this=20working=20group=20is=20to=20co= me=20up=20something=20that=20 was=20like=20that=20only=20better,=20fair=20enough.=20Then=20I=20have=20m= isunderstood=20what=20 this=20WG=20would=20accomplish,=20and=20apologize. =3E=20Those=20are=20only=20the=20first=20two.=20There=20is=20a=20third=20= problem=20we=20may=20be=20 =3E=20looking=20at=20in=20the=20longer=20term:=20=22The=20optional=20seco= nd=20phase=20will=20 =3E=20identify=20one=20or=20more=20standards-track=20one-way=20hash=20fun= ctions=20that=20 =3E=20fulfill=20the=20requirements=20stated=20in=20the=20BCP=20documents=20= developed=20in=20the=20 =3E=20first=20phase.=20=20Guidance=20will=20also=20be=20developed =3E=20to=20assist=20protocol=20developers=20in=20the=20selection=20among=20= the=20 =3E=20standards-track=20one-way=20hash=20functions.=22 =3E But=20that=20should=20be=20a=20separate=20thing=20that=20happens=20when=20= there's=20something=20 to=20say.=20Guidance=20is=20simple=20right=20now=20and=20will=20give=20us= =20a=20five-page=20RFC.=20 There=20are=20lots=20and=20lots=20of=20edge=20conditions=20that=20can't=20= be=20simply=20 addressed=20in=20a=20single=20document. =3E=3E=20NIST=20is=20supposed=20to=20release=20an=20addendum=20to=20DSA=20= for=20wide=20hashes=20and=20 =3E=3E=20keys=20bigger=20than=201024=20bits. =3E =3E=20I=20see=20nothing=20on=20the=20NIST=20site=20that=20says=20that=20t= hey=20will=20release=20this=20 =3E=20addendum,=20nor=20have=20I=20heard=20it=20from=20the=20NIST=20folks= =20I=20have=20spoken=20with.=20 =3E=20That=20is=20not=20to=20say=20that=20they=20aren't=20working=20on=20= it,=20just=20that=20we=20 =3E=20shouldn't=20assume=20that=20the=20addendum=20is=20a=20fact. At=20CRYPTO=20'04,=20I=20spoke=20to=20people=20and=20actually=20saw=20a=20= proposed=20DSS=20 update.=20Obviously,=20they=20haven't=20been=20happy=20with=20it.=20This=20= is=20 frustrating,=20but=20like=20it=20or=20not,=20they're=20the=20people=20who= =20produce=20DSS,=20 and=20when=20they=20come=20out=20with=20something,=20that's=20what=20to=20= do. If=20they=20don't=20come=20out=20with=20something=20before=20people=20rea= lly=20start=20 switching,=20that=20would=20be=20sad,=20but=20that=20puts=20the=20urgency= =20on=20them. =3E =3E=3E=20The=20=2Acorrect=2A=20thing=20for=20us=20to=20do=20is=20wait=20f= or=20that. =3E =3E=20Some=20folks=20at=20NIST=20have=20told=20us=20(quite=20informally)=20= that=20us=20working=20on=20 =3E=20the=20truncation=20issue=20would=20be=20a=20good=20thing.=20Certain= ly,=20if=20it=20turns=20out=20 =3E=20that=20simple=20truncation=20can=20be=20shown=20to=20be=20as=20safe= =20as=20any=20other=20 =3E=20shortening=20method,=20that=20would=20help=20DSA=20because=20it=20w= ould=20make=20the=20 =3E=20algorithm=20much=20simpler.=20This=20is=20why=20I=20asked=20in=20th= e=20previous=20message=20 =3E=20for=20input=20on=20research=20in=20this=20area. =3E (I=20hope=20I'm=20not=20repeating=20myself.)=20Last=20summer,=20at=20PGP,= =20we=20coded=20up=20DSA=20 with=20truncated=20SHA-256.=20When=20the=20new=20results=20came=20out=20i= n=20February,=20we=20 put=20it=20into=20alphas=20of=20PGP=209.=20I=20told=20some=20NIST=20peopl= e,=20who=20gave=20me=20the=20 most=20dreadful=20look,=20and=20we=20took=20it=20out.=20(Actually,=20we=20= didn't=20fully=20take=20 it=20out=20in=20Beta=201,=20and=20so=20there=20were=20a=20few=20DSA-SHA25= 6=20signatures=20that=20 leaked=20out=20into=20the=20world.) The=20reason=20we=20didn't=20was=20that=20we=20decided=20that=20truncatin= g=20wasn't=20the=20 right=20thing,=20and=20sticking=20to=20SHA-1=20is=20all=20right=20for=20t= he=20time=20being. =3E=3E=20If=20someone=20finds=20the=20wait=20unacceptable,=20then=20there= 's=20an=20obvious=20 =3E=3E=20workaround=20--=20use=20RSA=20with=20SHA-256. =3E =3E=20This=20is=20simplistic=20on=20a=20couple=20of=20levels. =3E =3E=20-=20There=20are=20many=20properties=20where=20DSA=20and=20RSA=20dif= fer,=20and=20a=20protocol=20 =3E=20developer=20may=20have=20chose=20DSA=20for=20one=20of=20those. =3E =3E=20-=20The=20assumption=20of=20SHA-256=20seems=20rash.=20In=20particul= ar,=20we=20don't=20yet=20 =3E=20have=20information=20preimage=20attacks=20on=20SHA-1,=20we=20haven'= t=20specified=20which=20 =3E=20kinds=20of=20uses=20of=20hashes=20with=20digital=20signatures=20are= =20affected=20by=20the=20 =3E=20reduction=20in=20collision=20strength,=20and=20we=20haven't=20looke= d=20at=20whether=20 =3E=20other=20formulations=20of=20hashes=20might=20appear=20to=20more=20i= mmune=20to=20attacks=20 =3E=20related=20to=20the=20ones=20we=20know=20now. =3E =3E=20-=20Changing=20protocols=20is=20very=20difficult=20for=20typical=20= users.=20They=20may=20be=20 =3E=20using=20a=20protocol=20in=20which=20there=20is=20no=20identifier=20= for=20=22RSA=20with=20 =3E=20SHA-256=22.=20They=20may=20be=20using=20the=20algorithm=20for=20lon= g-lived=20signatures,=20 =3E=20where=20switching=20means=20using=20multiple=20protocols=20with=20d= ifferent=20 =3E=20properties.=20Having=20some=20users=20change=20while=20others=20don= 't=20can=20cause=20 =3E=20long-term=20problems=20for=20both=20groups:=20that's=20why=20the=20= IETF=20tries=20to=20be=20 =3E=20clear=20which=20algorithms=20to=20use,=20and=20when. =3E I=20worried=20about=20my=20last=20missive=20being=20far=20too=20long,=20a= nd=20drastically=20 truncated=20it=20before=20I=20sent=20it.=20I'll=20try=20to=20avoid=20that= =20error=20again=20 (which=20is=20part=20of=20why=20I=20risked=20repeating=20myself=20above,=20= because=20even=20if=20 I=20am,=20it's=20emphasis). I'm=20the=20one=20responsible=20for=20the=20pithy=20comment=20about=20SHA= -1=20that=20it's=20 time=20to=20walk,=20not=20run=20to=20the=20exit.=20I=20know=20that=20ther= e=20are=20complications.=20 Believe=20me. I'm=20the=20author=20of=20both=20OpenPGP=20(which=20possibly=20has=20the=20= widest=20use=20of=20 DSA),=20and=20syslog-sign=20(which=20depends=20on=20DSA=20because=20it's=20= really,=20really=20 important=20to=20short=20signatures=20in=20a=20syslog=20packet). In=20the=20OpenPGP=20case,=20it's=20cold=20comfort=20indeed=20to=20be=20t= old=20=22make=20another=20 key,=20then.=22=20I=20haven't.=20Heck,=20I=20got=20chewed=20out=20last=20= weekend=20for=20our=20 deprecating=20MD5.=20People=20get=20emotional=20about=20this. In=20the=20syslog-sign=20case,=20we're=20in=20a=20bad=20spot.=20It's=20re= ally,=20really=20 important=20to=20have=20short=20signatures.=20Moving=20to=20SHA-256=20is=20= not=20 convenient,=20and=2040-byte=20sigs=20are=20important.=20This=20is=20a=20p= lace=20were=20 truncation=20or=20something=20else=20would=20be=20good.=20However=20--=20= I=20still=20say=20to=20 stay=20the=20course=20on=20SHA-1.=20It's=20good=20enough=20for=20now.=20I= =20repeat,=20for=20now. Yes,=20this=20is=20not=20simple,=20and=20that's=20my=20point=21=20If=20yo= u=20want=20a=20simple=20 answer,=20I=20gave=20one.=20That=20the=20simple=20answer=20is=20simplisti= c=20only=20 underscores=20my=20questions=20about=20the=20WG's=20purpose=20and=20exist= ence. =3E=3E=20The=20answer=20of=20how=20to=20truncate=20the=20wide=20SHAs=20is= =20answered=20for=20us=20in=20 =3E=3E=20FIPS=20180. =3E =3E=20If=20you=20only=20read=20the=20paragraph=20you=20quoted,=20yes.=20T= he=20rest=20of=20that=20 =3E=20section=20from=20FIPS=20180=20says: =3E [elided] =3E Thank=20you=21=20This=20is=20precisely=20my=20point.=20This=20is=20part=20= of=20why=20we=20decided=20 to=20not=20use=20truncated=20SHA-256.=20FIPS=20180=20tells=20us=20=2Ahow=2A= =20to=20do=20it.=20It=20does=20 not=20tell=20us=20=2Awhen=2A=20to,=20=2Awhy=2A=20to,=20or=20other=20thing= s.=20But=20that's=20not=20what=20I=20 said.=20I=20said=20that=20if=20one=20of=20the=20goals=20of=20the=20WG=20i= s=20=2Ahow=2A=20to=20truncate=20 the=20wide=20SHAs,=20FIPS=20180=20tells=20us. =3E=20Not=20wearing=20my=20BOF=20chair=20hat:=20the=20little=20that=20is=20= said=20in=20FIPS=20180=20is=20 =3E=20not=20sufficient=20to=20decide=20that=20we=20know=20enough=20about=20= the=20issue=20to=20decide=20 =3E=20anything.=20The=20cryptographic=20community=20is=20certainly=20able= =20to=20deal=20with=20 =3E=20this=20issue=20better=20than=20the=20first=20paragraph=20of=20the=20= section=20in=20FIPS=20180. =3E =3E=3E=20The=20answer=20of=20what=20to=20do=20with=20DSA=20is=20=22Don't.= =22=20We=20can=20wait=20for=20NIST.=20 =3E=3E=20If=20we=20don't=20we're=20going=20to=20have=20to=20do=20what=20t= hey=20say,=20anyway.=20Why=20make=20 =3E=3E=20more=20work? =3E =3E=20Because=20the=20=22more=20work=22=20may=20be=20valuable=20research,= =20even=20for=20NIST. =3E Then=20this=20should=20be=20in=20the=20IRTF,=20not=20the=20IETF. =3E=20To=20be=20clear:=20I'm=20not=20saying=20we=20should=20have=20trunca= tion=20in=20our=20WG=20 =3E=20charter,=20and=20Jon=20is=20the=20first=20so=20far=20to=20speak=20u= p=20to=20say=20we=20shouldn't.=20 =3E=20Hearing=20from=20others=20on=20the=20mailing=20list=20would=20be=20= useful. =3E =3E=3E=20The=20second=20issue,=20using=20salted=20hashes=20(I=20prefer=20= this=20to=20 =3E=3E=20=22randomized=22),=20is=20more=20interesting=20technologically,=20= but=20there=20are=20 =3E=3E=20still=20a=20number=20of=20extremely=20important=20issues=20open=20= about=20them. =3E =3E=20Exactly=21 =3E Thanks. =3E=3E=20The=20first=20open=20issue=20is=20their=20expected=20security=20= when=20compared=20both=20to=20 =3E=3E=20the=20unsalted=20version=20and=20comparable=20other=20functions.= =20For=20example,=20we=20 =3E=3E=20know=20that=20SHA-1=20should=20have=2080=20bits=20of=20security=20= and=20doesn't.=20Will=20as=20 =3E=3E=20salted=20SHA-1=20have=2080=20bits=20of=20security?=20What=20make= s=20us=20think=20so?=20 =3E=3E=20SHA-256=20should=20have=20128=20bits=20of=20security,=20and=20ma= ny=20of=20us=20(I=20know=20I=20am=20 =3E=3E=20one)=20expect=20it=20to=20have=20flaws.=20However,=20do=20we=20e= xpect=20it=20to=20have=20less=20 =3E=3E=20than=2080=20bits=20of=20security?=20I=20don't. =3E =3E=20This=20paragraph=20again=20assumes=20a=20move=20to=20SHA-256.=20It=20= might=20be=20better=20to=20 =3E=20deal=20with=20the=20tradeoffs,=20as=20is=20done=20in=20the=20one=20= Internet=20Draft=20we=20have,=20 =3E=20=3Chttp://www.ietf.org/internet-drafts/draft-irtf-cfrg-rhash-00.txt= =3E=2E =3E I=20read=20it.=20As=20a=20protocol=20author,=20I=20find=20it=20amazingly=20= unsatisfying. If=20my=20worry,=20that=20this=20WG=20would=20take=20that=20draft,=20turn= =20it=20into=20an=20RFC,=20 and=20then=20start=20recommending,=20coercing,=20whatevering=20people=20t= o=20use=20it=20is=20 an=20unfounded=20worry,=20then=20again,=20I=20apologize.=20I've=20been=20= seeing=20things=20 under=20the=20bed. =3E=3E=20In=20discussions=20in=20the=20CFRG=20list,=20Dan=20Bernstein=20h= as=20suggested=20that=20 =3E=3E=20salted=20MD5=20has=20similar=20performance=20to=20unsalted=20SHA= -256. =3E =3E=20Seeing=20actual=20numbers=20on=20this=20would=20be=20a=20great=20bo= on=20to=20the=20discussion. =3E My=20point,=20as=20well. =3E=3E=20It=20seems=20to=20me=20that=20if=20there=20are=20questions=20tha= t=20a=20hashing=20working=20 =3E=3E=20group=20should=20be=20asking,=20they=20are=20not=20the=20ones=20= we're=20asking,=20but=20other=20 =3E=3E=20ones=20that=20include: =3E=3E =3E=3E=20=2A=20What=20is=20the=20security=20of=20a=20salted=20hash=20func= tion?=20Does=20salted=20MD5=20 =3E=3E=20have=2064=20bits=20of=20security?=20Does=20salted=20SHA-1=20have= =2080=20bits=20of=20security?=20 =3E=3E=20Does=20salted=20SHA-256=20have=20128=20bits=20of=20security?=20W= hy=20do=20we=20think=20this?=20 =3E=3E=20I've=20seen=20no=20reasoning=20nor=20metrics. =3E =3E=20Good=20questions,=20and=20ones=20we=20should=20answer. =3E Again,=20I=20don't=20see=20that=20as=20what=20a=20working=20group=20does. =3E=3E=20=2A=20What=20is=20the=20security=20of=20a=20truncated=20hash=20f= unction?=20Examples:=20 =3E=3E=20Suppose=20SHA-256=20has=20110=20bits=20of=20security=20(if=20it=20= is=20as=20broken=20as=20 =3E=3E=20SHA-1,=20this=20is=20my=20predicted=20security=20value).=20If=20= you=20truncate=20SHA-256=20 =3E=3E=20to=20128=20bits,=20does=20that=20mean=20that=20it=20has=2055=20b= its=20of=20security?=20Or=20does=20 =3E=3E=20it=20mean=20that=20it=20has=2064=20bits=20of=20security?=20Or=20= something=20in=20the=20middle?=20 =3E=3E=20Why=20do=20we=20think=20this?=20What=20do=20we=20expect=20its=20= security=20to=20be=20if=20you=20 =3E=3E=20truncate=20it=20to=20160=20bits=20and=20why? =3E =3E=20Good=20questions,=20and=20ones=20we=20should=20answer.=20So,=20now=20= you=20want=20to=20keep=20 =3E=20the=20item=20in=20the=20WG=20charter?=20:-) My=20objection=20is=20to=20the=20WG=20charter,=20not=20its=20contents.=20= If,=20however,=20I=20 cannot=20affect=20the=20decision=20of=20=2Awhether=2A=20to=20have=20a=20c= harter=20and=20we=20are=20 indeed=20having=20one,=20then=20yes,=20I=20want=20it=20in=20the=20charter= . =3E =3E=3E=20=2A=20What=20is=20the=20performance=20of=20a=20salted=20hash=20f= unction?=20Bernstein's=20 =3E=3E=20claim=20that=20salted=20MD5=20has=20similar=20performance=20to=20= SHA-256=20has=20gone=20 =3E=3E=20unchallenged,=20and=20he=20himself=20has=20noted=20this=20silenc= e. =3E =3E=20These=20should=20not=20be=20difficult=20values=20to=20start=20gener= ating. =3E =3E=3E=20=2A=20Are=20there=20other=20constructions=20we=20can=20perform=20= that=20give=20us=20security=20 =3E=3E=20over=20the=20naked=20hash=20function,=20but=20require=20less=20w= ork=20than=20salting?=20For=20 =3E=3E=20example,=20suppose=20we=20took=20SHA-256=20and=20folded=20its=20= halves,=20XORing=20them=20 =3E=3E=20together.=20Does=20this=20give=20us=20more=20security=20than=20s= traight=20truncation?=20 =3E=3E=20If=20not,=20why=20not=20(since=20it=20seems=20intuitive=20that=20= folding=20would=20have=20at=20 =3E=3E=20least=20an=20eensy=20bit=20more=20security)?=20What=20other=20co= nstructions=20could=20we=20 =3E=3E=20make=20that=20improve=20over=20raw=20truncation=20without=20the=20= cost=20of=20salting? =3E =3E=20Good=20questions,=20and=20ones=20we=20should=20answer. =3E But=20that=20is=20at=20odds=20with=20one=20of=20the=20WG=20goals=20--=20t= o=20explore=20salted=20 hashing.=20I=20think=20it's=20far=20too=20early=20to=20do=20that. My=20perception=20is=20that=20we're=20getting=20the=20verdict=20first=20-= -=20 randomized/salted=20hashing=20--=20and=20collecting=20evidence=20later.=20= If=20my=20 perception=20is=20out=20of=20whack,=20please=20let=20me=20know. =3E=3E=20Without=20answers=20to=20these=20questions,=20I=20don't=20see=20= how=20this=20working=20 =3E=3E=20group=20can=20give=20any=20meaningful=20results.=20Worse,=20I=20= don't=20see=20how=20any=20 =3E=3E=20recommendation=20of=20this=20group=20can=20improve=20over=20the=20= simple=20advice=20of=20 =3E=3E=20=22use=20SHA-256.=22=20If=20this=20BOF=20results=20in=20a=20work= ing=20group,=20I=20believe=20it=20 =3E=3E=20=2Amust=2A=20address=20the=20questions=20I=20outlined=20above,=20= as=20well=20as=20the=20issues=20 =3E=3E=20I=20and=20Bernstein=20have=20brought=20up=20in=20CFRG. =3E =3E=20A=20specific=20list=20of=20issues=20on=20=2Athis=2A=20list,=20not=20= on=20CFRG,=20would=20help=20us=20 =3E=20finalize=20the=20charter. =3E Mea=20culpa.=20I=20forwarded=20my=20previous=20CFRG=20note=20here. =3E=3E=20If=20salted=20hashes=20are=20slower=20than=20wider=20hashes=20an= d=20the=20wider=20hash=20has=20 =3E=3E=20enough=20security=20(enough=20being=20greater=20than=2064=20bits= =20for=20an=20MD5=20 =3E=3E=20replacement=20and=20greater=20than=2080=20bits=20for=20a=20SHA-1= =20replacement),=20then=20 =3E=3E=20we=20should=20just=20use=20the=20wider=20hash=20and=20be=20done=20= with=20it=20--=20except=20when=20 =3E=3E=20that's=20not=20reasonable. =3E =3E=20Having=20a=20description=20of=20when=20it=20is=20reasonable=20also=20= seems=20to=20be=20 =3E=20valuable=20to=20be=20written=20down. =3E =3E Assuming=20we=20have=20something=20to=20say=20that=20has=20a=20shelf=20li= fe=20longer=20than=20 bottled=20water,=20yes.=20I=20am=20not=20convinced=20we=20have=20that. =09Jon =0A ________________________________________________________________ This=20message=20could=20have=20been=20secured=20by=20PGP=20Universal.=20= To=20secure future=20messages=20from=20this=20sender,=20please=20click=20this=20link: https://keys.pgp.com/b/b.e?r=3Dhash=2540ietf.org=26n=3DI6LW=252FTFegliptj= mtozrp=252Bg=253D=253D _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Thu Jul 21 10:05:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvbgA-0000sy-EO; Thu, 21 Jul 2005 10:05:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvbg9-0000qn-5w for hash@megatron.ietf.org; Thu, 21 Jul 2005 10:05:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02385 for ; Thu, 21 Jul 2005 10:05:35 -0400 (EDT) Received: from sottmxsecs3.entrust.com ([216.191.252.14]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DvcAB-0001vT-Ed for hash@ietf.org; Thu, 21 Jul 2005 10:36:40 -0400 Received: (qmail 32241 invoked from network); 21 Jul 2005 14:05:11 -0000 Received: from robert.zuccherato@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.3.1; 21 Jul 2005 14:05:11 -0000 Received: from unknown (HELO sottmxs00.entrust.com) (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 21 Jul 2005 14:05:11 -0000 Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Jul 2005 10:05:12 -0400 Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F04274224@sottmxs05.entrust.com> From: Robert Zuccherato To: "'Jon Callas'" , Paul Hoffman Subject: RE: [Hash] BOF Goals Date: Thu, 21 Jul 2005 10:05:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: hash@ietf.org X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1695286684==" Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1695286684== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58DFD.36352DD9" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C58DFD.36352DD9 Content-Type: text/plain I would have to agree with Jon's comments. The two approaches suggested in the charter (hash truncation and randomized hashes) may very well end up being the final solutions that we decide on. However, there are still too many open questions regarding the security, efficiency and suitability of these constructions. Given that many (most?) applications can simply switch to using RSA with SHA-256 and that we have to wait for NIST on DSA anyway, I don't think that there is any need to rush into anything. Clearly there is important work to be done. As Jon said though, that work should probably be done in the IRTF rather than the IETF. In any case, it would probably be prudent to wait until after the Cryptographic Hash Workshop at NIST (October 31st-November 1st) before deciding upon any charter. It is not unreasonable to expect the results of that workshop to be relevant to what gets discussed here. Robert Zuccherato. ------_=_NextPart_001_01C58DFD.36352DD9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Hash] BOF Goals

I would have to agree with Jon's comments.  The = two approaches suggested in the charter (hash truncation and randomized = hashes) may very well end up being the final solutions that we decide = on.  However, there are still too many open questions regarding = the security, efficiency and suitability of these constructions.  = Given that many (most?) applications can simply switch to using RSA = with SHA-256 and that we have to wait for NIST on DSA anyway, I don't = think that there is any need to rush into anything.  Clearly there = is important work to be done.  As Jon said though, that work = should probably be done in the IRTF rather than the IETF.

In any case, it would probably be prudent to wait = until after the Cryptographic Hash Workshop at NIST (October = 31st-November 1st) before deciding upon any charter.  It is not = unreasonable to expect the results of that workshop to be relevant to = what gets discussed here.

        Robert = Zuccherato.

------_=_NextPart_001_01C58DFD.36352DD9-- --===============1695286684== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash --===============1695286684==-- From hash-bounces@lists.ietf.org Thu Jul 21 11:42:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvdBs-00032x-42; Thu, 21 Jul 2005 11:42:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvdBr-00030W-8o for hash@megatron.ietf.org; Thu, 21 Jul 2005 11:42:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10938 for ; Thu, 21 Jul 2005 11:42:25 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvdfu-0008Qt-2T for hash@ietf.org; Thu, 21 Jul 2005 12:13:31 -0400 Received: from [165.227.249.220] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LFgG7V073500; Thu, 21 Jul 2005 08:42:17 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F04274224@sottmxs05.entrust.com> References: <7A3E1242FA9989439AD1F9B2D71C287F04274224@sottmxs05.entrust.com> Date: Thu, 21 Jul 2005 08:42:16 -0700 To: Robert Zuccherato , "'Jon Callas'" From: Paul Hoffman Subject: RE: [Hash] BOF Goals Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: hash@ietf.org X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org At 10:05 AM -0400 7/21/05, Robert Zuccherato wrote: >Given that many (most?) applications can simply switch to using RSA >with SHA-256 and that we have to wait for NIST on DSA anyway, I >don't think that there is any need to rush into anything. Fully agree. I don't think anything in the charter has "rush" implied in it. >Clearly there is important work to be done. As Jon said though, >that work should probably be done in the IRTF rather than the IETF. If the research is already being done in the cryptographic community, then it is fine to report on that research as input to an IETF Working Group. We do this all the time in other IETF contexts, such as commercial and academic research being done on real-time applications having an effect in the various SIP-related working groups. Lots of crypto research appears in other Security area working groups, of course. If the research is *not* being done yet, it is far from clear if we could get it to happen in an IRTF research group, particularly because the perceived need for the research is low. The CFRG has not produced much in the way of crypto research. In fact, the only active CFRG Internet Draft is the one we are talking about here in this WG. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Thu Jul 21 13:26:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvep0-0001Ox-Vc; Thu, 21 Jul 2005 13:26:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dveoz-0001N1-4a for hash@megatron.ietf.org; Thu, 21 Jul 2005 13:26:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20196 for ; Thu, 21 Jul 2005 13:26:54 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvfJ2-0007gp-Ve for hash@ietf.org; Thu, 21 Jul 2005 13:58:02 -0400 Received: from [165.227.249.220] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6LHQngk081407 for ; Thu, 21 Jul 2005 10:26:50 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 21 Jul 2005 10:26:47 -0700 To: Hash WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Hash] Possible disconnect on the proposed charter X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org In re-reading Jon's and Robert's messages, I realized that the organization of the proposed charter may be unclear, and that unclarity might be what's getting people stuck. (I could be wrong and they just don't like the idea of an IETF WG at all...). The charter's larger work of the proposed WG is: The working group will consider the suitability of one-way hash functions for use with IETF protocols. These requirements will be published as one or more BCP documents which specify the features and characteristics for standards-track one-way hash functions. The BCP documents will also identify information that must be included in any request for a hash function to be approved on the standards track. . . . The optional second phase will identify one or more standards-track one-way hash functions that fulfill the requirements stated in the BCP documents developed in the first phase. Guidance will also be developed to assist protocol developers in the selection among the standards-track one-way hash functions. The narrower, more immediate work is the salting/truncating work. It seems like there is general agreement that the narrower work is of limited utility, only aimed at DSA (and, apparently, not even ECDSA). Do people feel OK with chartering a WG with the larger work more emphasized? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Thu Jul 21 13:39:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvf1H-00076E-JE; Thu, 21 Jul 2005 13:39:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvf1F-00070D-B6 for hash@megatron.ietf.org; Thu, 21 Jul 2005 13:39:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20912 for ; Thu, 21 Jul 2005 13:39:34 -0400 (EDT) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvfVJ-00005v-AE for hash@ietf.org; Thu, 21 Jul 2005 14:10:42 -0400 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j6LHdNd0017669; Thu, 21 Jul 2005 10:39:23 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j6LHdNht017666; Thu, 21 Jul 2005 10:39:23 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 21 Jul 2005 10:39:23 -0700 (PDT) From: "william(at)elan.net" To: Paul Hoffman Subject: Re: [Hash] Possible disconnect on the proposed charter In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Hash WG X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org It is not entirely clear to me that we have understanding on what are good hash functions or have consensus for functional replacement for bad one. Perhaps it should be considered to first form a IRTF RG to study hash functions more and consider and compare alternatives to SHA1 algorithm with some testing done as well. Now this all does not mean we can't do such research and as part of IETF WG, but if WG is going to focus primarily on researching HASH functions, is it really appropriate for it to be called WG? On Thu, 21 Jul 2005, Paul Hoffman wrote: > In re-reading Jon's and Robert's messages, I realized that the organization > of the proposed charter may be unclear, and that unclarity might be what's > getting people stuck. (I could be wrong and they just don't like the idea of > an IETF WG at all...). > > The charter's larger work of the proposed WG is: > > The working group will consider the suitability of one-way hash > functions for use with IETF protocols. These requirements will be > published as one or more BCP documents which specify the features and > characteristics for standards-track one-way hash functions. The BCP > documents will also identify information that must be included in any > request for a hash function to be approved on the standards track. > > . . . > > The optional second phase will identify one or more standards-track > one-way hash functions that fulfill the requirements stated in the BCP > documents developed in the first phase. Guidance will also be developed > to assist protocol developers in the selection among the standards-track > one-way hash functions. > > The narrower, more immediate work is the salting/truncating work. It seems > like there is general agreement that the narrower work is of limited utility, > only aimed at DSA (and, apparently, not even ECDSA). > > Do people feel OK with chartering a WG with the larger work more emphasized? > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Hash mailing list > Hash@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hash > -- William Leibzon Elan Networks william@elan.net _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Tue Jul 26 11:20:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxREm-00016o-PP; Tue, 26 Jul 2005 11:20:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxREl-00016j-2y for hash@megatron.ietf.org; Tue, 26 Jul 2005 11:20:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27202 for ; Tue, 26 Jul 2005 11:20:49 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxRjj-0007qn-LI for hash@ietf.org; Tue, 26 Jul 2005 11:52:57 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6QFKf47037096 for ; Tue, 26 Jul 2005 08:20:42 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 26 Jul 2005 08:19:14 -0700 To: Hash WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Hash] Revised proposed agenda for IETF 63 in Paris X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: hash.lists.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org We are scheduled for Monday evening 1815-1945. I have received three requests to make short presentations. Given that we only have 90 minutes, and we still obviously have issues to deal with in the charter, think a better order will be: 1) Presentations (60 minutes): - Ran Canetti on draft-irtf-cfrg-rhash-00.txt - Russ Housley on a proposal for message preprocessing - Bellovin and Rescorla on IETF protocols and new hashing mechanisms - General discussion on tradeoffs of mechanisms and functions 2) Charter discussion (30 minutes); - What are the short term and long term objectives for the IETF? - Is it possible to set IETF requirements for hash functions? - Is a Working Group useful to the IETF? To the outside world? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash