From mailnull@www1.ietf.org Fri Jan 3 04:12:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05615 for ; Fri, 3 Jan 2003 04:12:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h039LcQ10987 for cfrg-archive@odin.ietf.org; Fri, 3 Jan 2003 04:21:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h039LbJ10984 for ; Fri, 3 Jan 2003 04:21:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05594 for ; Fri, 3 Jan 2003 04:12:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h039K0J10856; Fri, 3 Jan 2003 04:20:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h039FCJ10706 for ; Fri, 3 Jan 2003 04:15:12 -0500 Received: from exch-gw-aa.EXCHPROD.USA.NET (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05461 for ; Fri, 3 Jan 2003 04:05:59 -0500 (EST) Received: from EXCH-MR-AB.EXCHPROD.USA.NET ([10.26.48.52]) by exch-gw-aa.EXCHPROD.USA.NET with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Jan 2003 02:09:11 -0700 Received: from 10.26.48.52 by EXCH-MR-AB.EXCHPROD.USA.NET (InterScan E-Mail VirusWall NT); Fri, 03 Jan 2003 02:09:11 -0700 (Mountain Standard Time) Received: from golden ([66.124.226.212]) by EXCH-MR-AB.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Jan 2003 02:09:10 -0700 Message-ID: <019101c2b307$c8a0f590$640a000a@golden> From: "Gordon Mohr" To: Date: Fri, 3 Jan 2003 01:09:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 03 Jan 2003 09:09:10.0531 (UTC) FILETIME=[C70AC530:01C2B307] Content-Transfer-Encoding: 7bit Subject: [Cfrg] Bit-rotation to create alternative secure hash? (was re: Merkle Hash Tree Weakness - Request for Advice) Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In the context of designing a tree hash over a file, for the purpose of incremental subrange verification, and ensuring that there are no trivial collisions as will occur when the exact same function is applied to leaves and concatenated internal nodes... Justin Chapweske wrote: > The quote from Dr. Wagner follows: > > " > The standard fix is to do one or the other of the following. > (1) Include a depth, i.e., we compute the hash value at a > node of depth d as Hash(d,l,r) where l represents the > hash value at the left child and r the right child's hash. > (2) Use a different hash function at the leaves than at > internal nodes. In other words, we compute the hash value > at a leaf node as Hash("leaf",x) where x is the data > associated at that leaf; we compute the hash value at > an internal node as Hash("internal",l,r) where l,r are > as above. > If I recall correctly, both of these can be proven secure if > the underlying hash is modelled as a random oracle. However, > I haven't checked this, so I could be wrong. > " Consider the secure hash created by taking an existing secure hash, and applying a final 1-bit-left-rotation step to its output, with wraparound. In approach (2) above, would it be reasonable to use a standard secure hash as the "leaf" function , and the shifted version of the same secure hash as the "internal" function? - Gordon _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Fri Jan 3 08:57:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09251 for ; Fri, 3 Jan 2003 08:57:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03E6E326728 for cfrg-archive@odin.ietf.org; Fri, 3 Jan 2003 09:06:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03E6EJ26725 for ; Fri, 3 Jan 2003 09:06:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09242 for ; Fri, 3 Jan 2003 08:56:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03E2PJ26557; Fri, 3 Jan 2003 09:02:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03E1kJ26509 for ; Fri, 3 Jan 2003 09:01:46 -0500 Received: from woodstock.binhost.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09153 for ; Fri, 3 Jan 2003 08:52:28 -0500 (EST) Received: (qmail 5577 invoked from network); 3 Jan 2003 13:55:21 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.164.17) by woodstock.binhost.com with SMTP; 3 Jan 2003 13:55:21 -0000 Message-Id: <5.2.0.9.2.20030103085341.00b7ca00@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 03 Jan 2003 08:54:34 -0500 To: "Gordon Mohr" , From: Russ Housley Subject: Re: [Cfrg] Bit-rotation to create alternative secure hash? (was re: Merkle Hash Tree Weakness - Request for Advice) In-Reply-To: <019101c2b307$c8a0f590$640a000a@golden> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Gordon: It would be much more efficient to rotate by a byte, rather than a bit. Is there any reason you chose a bit rotation? Russ At 01:09 AM 1/3/2003 -0800, Gordon Mohr wrote: >In the context of designing a tree hash over a file, for the >purpose of incremental subrange verification, and ensuring >that there are no trivial collisions as will occur when the >exact same function is applied to leaves and concatenated >internal nodes... > >Justin Chapweske wrote: > > The quote from Dr. Wagner follows: > > > > " > > The standard fix is to do one or the other of the following. > > (1) Include a depth, i.e., we compute the hash value at a > > node of depth d as Hash(d,l,r) where l represents the > > hash value at the left child and r the right child's hash. > > (2) Use a different hash function at the leaves than at > > internal nodes. In other words, we compute the hash value > > at a leaf node as Hash("leaf",x) where x is the data > > associated at that leaf; we compute the hash value at > > an internal node as Hash("internal",l,r) where l,r are > > as above. > > If I recall correctly, both of these can be proven secure if > > the underlying hash is modelled as a random oracle. However, > > I haven't checked this, so I could be wrong. > > " > >Consider the secure hash created by taking an existing secure >hash, and applying a final 1-bit-left-rotation step to its output, >with wraparound. > >In approach (2) above, would it be reasonable to use a standard >secure hash as the "leaf" function , and the shifted version of >the same secure hash as the "internal" function? > >- Gordon >_______________________________________________ >Cfrg mailing list >Cfrg@ietf.org >https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Fri Jan 3 14:58:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17800 for ; Fri, 3 Jan 2003 14:58:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h03K7dZ21427 for cfrg-archive@odin.ietf.org; Fri, 3 Jan 2003 15:07:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03K7cJ21424 for ; Fri, 3 Jan 2003 15:07:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17797 for ; Fri, 3 Jan 2003 14:58:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JxhJ20558; Fri, 3 Jan 2003 14:59:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03JwXJ20512 for ; Fri, 3 Jan 2003 14:58:33 -0500 Received: from exch-gw-ab.EXCHPROD.USA.NET (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17620 for ; Fri, 3 Jan 2003 14:49:07 -0500 (EST) Received: from EXCH-MR-AA.EXCHPROD.USA.NET ([10.26.48.53]) by exch-gw-ab.EXCHPROD.USA.NET with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Jan 2003 12:52:12 -0700 Received: from 10.26.48.53 by EXCH-MR-AA.EXCHPROD.USA.NET (InterScan E-Mail VirusWall NT); Fri, 03 Jan 2003 12:52:12 -0700 (Mountain Standard Time) Received: from golden ([67.121.76.22]) by EXCH-MR-AA.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Jan 2003 12:52:12 -0700 Message-ID: <004601c2b361$9e570d60$640a000a@golden> From: "Gordon Mohr" To: , "Russ Housley" References: <5.2.0.9.2.20030103085341.00b7ca00@mail.binhost.com> Subject: Re: [Cfrg] Bit-rotation to create alternative secure hash? (was re: Merkle Hash Tree Weakness - Request for Advice) Date: Fri, 3 Jan 2003 11:52:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 03 Jan 2003 19:52:12.0406 (UTC) FILETIME=[9BA1B160:01C2B361] Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Good point. I only highlighted the 1-bit approach as a sort of "minimal representation" of the technique... if a 1-bit shift is OK, then just about any other n-bit shift (n < hash width) should be OK too. - Gordon ----- Original Message ----- From: "Russ Housley" To: "Gordon Mohr" ; Sent: Friday, January 03, 2003 5:54 AM Subject: Re: [Cfrg] Bit-rotation to create alternative secure hash? (was re: Merkle Hash Tree Weakness - Request for Advice) > Gordon: > > It would be much more efficient to rotate by a byte, rather than a bit. Is > there any reason you chose a bit rotation? > > Russ > > At 01:09 AM 1/3/2003 -0800, Gordon Mohr wrote: > >In the context of designing a tree hash over a file, for the > >purpose of incremental subrange verification, and ensuring > >that there are no trivial collisions as will occur when the > >exact same function is applied to leaves and concatenated > >internal nodes... > > > >Justin Chapweske wrote: > > > The quote from Dr. Wagner follows: > > > > > > " > > > The standard fix is to do one or the other of the following. > > > (1) Include a depth, i.e., we compute the hash value at a > > > node of depth d as Hash(d,l,r) where l represents the > > > hash value at the left child and r the right child's hash. > > > (2) Use a different hash function at the leaves than at > > > internal nodes. In other words, we compute the hash value > > > at a leaf node as Hash("leaf",x) where x is the data > > > associated at that leaf; we compute the hash value at > > > an internal node as Hash("internal",l,r) where l,r are > > > as above. > > > If I recall correctly, both of these can be proven secure if > > > the underlying hash is modelled as a random oracle. However, > > > I haven't checked this, so I could be wrong. > > > " > > > >Consider the secure hash created by taking an existing secure > >hash, and applying a final 1-bit-left-rotation step to its output, > >with wraparound. > > > >In approach (2) above, would it be reasonable to use a standard > >secure hash as the "leaf" function , and the shifted version of > >the same secure hash as the "internal" function? > > > >- Gordon > >_______________________________________________ > >Cfrg mailing list > >Cfrg@ietf.org > >https://www1.ietf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@ietf.org > https://www1.ietf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Sun Jan 5 01:49:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21516 for ; Sun, 5 Jan 2003 01:49:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h056xFt00395 for cfrg-archive@odin.ietf.org; Sun, 5 Jan 2003 01:59:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h056xEJ00392 for ; Sun, 5 Jan 2003 01:59:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21513 for ; Sun, 5 Jan 2003 01:49:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h056wIJ00374; Sun, 5 Jan 2003 01:58:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h056ulJ00332 for ; Sun, 5 Jan 2003 01:56:47 -0500 Received: from sunbeam.cs.biu.ac.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21433 for ; Sun, 5 Jan 2003 01:46:39 -0500 (EST) Received: from biu-xjbs42banj6.herzberg.name ([132.70.4.58]) by sunbeam.cs.biu.ac.il with ESMTP id h056noZ10858 for ; Sun, 5 Jan 2003 08:49:50 +0200 (IST) Message-Id: <5.1.1.6.0.20030105084442.00ab75d8@mailhost.cs.biu.ac.il> X-Sender: herzbea@mailhost.cs.biu.ac.il X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sun, 05 Jan 2003 08:55:14 +0200 To: cfrg@ietf.org From: Amir Herzberg In-Reply-To: <20030104170005.28816.24379.Mailman@www1.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Cfrg] Weakness in rotation to create alternative secure hash? Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , I think David Wagner's second suggestion requires the two hash functions to be `independant` (and only known proof is in the random oracle model): > > > (2) Use a different hash function at the leaves than at > > > internal nodes. In other words, we compute the hash value > > > at a leaf node as Hash("leaf",x) where x is the data > > > associated at that leaf; we compute the hash value at > > > an internal node as Hash("internal",l,r) where l,r are > > > as above. Considering Gordon's suggestion/question re a using two highly related hash functions, namely the leaf function being identical to the internal function except for rotation... this specific proposal seems very weak, in fact insecure for any specific hash function (i.e. even in the `random oracle model`). This is most trivial if you consider rotation of size n, where n is the length of the output of the hash (e.g. 160 bits); in this case we just permutated the order of the blocks to the internal hash function... In fact, this seems to work also for any rotation e.g. one bit (or one byte). Or did I get it wrong (I admit I haven't checked all details...)? Best, Amir Herzberg _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Sun Jan 5 02:12:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28008 for ; Sun, 5 Jan 2003 02:12:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h057Ldw11234 for cfrg-archive@odin.ietf.org; Sun, 5 Jan 2003 02:21:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h057LcJ11231 for ; Sun, 5 Jan 2003 02:21:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27696 for ; Sun, 5 Jan 2003 02:11:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h057B6J05363; Sun, 5 Jan 2003 02:11:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h057ASJ05108 for ; Sun, 5 Jan 2003 02:10:28 -0500 Received: from sunbeam.cs.biu.ac.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21799 for ; Sun, 5 Jan 2003 02:00:19 -0500 (EST) Received: from biu-xjbs42banj6.herzberg.name ([132.70.4.58]) by sunbeam.cs.biu.ac.il with ESMTP id h0573TZ11260 for ; Sun, 5 Jan 2003 09:03:30 +0200 (IST) Message-Id: <5.1.1.6.0.20030105090622.00b1fbe8@mailhost.cs.biu.ac.il> X-Sender: herzbea@mailhost.cs.biu.ac.il X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sun, 05 Jan 2003 09:08:54 +0200 To: cfrg@ietf.org From: Amir Herzberg Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Cfrg] 2nd CFP: Security, Cryptography and Privacy Track in PODC 2003 Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Dear Colleagues, Please note that the deadline for submitting to PODC 2003, and in particular to the special track on Security in Distributed Computing, is rapidly approaching - Jan 31, 2003. This event is an excellent opportunity for interaction between the security, cryptography and distributed computing communities, and I hope many of you will send excellent submissions and of course participate. PODC will be held on Sunday July 13th - Wednesday July 16th, 2003, in Boston, Massachusetts. The registration fee includes two interesting pre-conference tutorials on Sunday, July 13. Both are on very active areas in security in distributed computing: Incentives and Internet Computation by Joan Feigenbaum and Scott Shenker, and Content Protection Technologies by Jeffrey B. Lotspiech, Tushar Chandra, and Donald E. Leake Jr.. Abstracts are included below, and can also be found, with bios of the speakers, from the webpage: http://www.podc.org/podc2003 Expect lively discussion on these and other issues related to security and privacy in distributed systems, following these tutorials, as well as our very special invited speakers on security: Ross Anderson (U. of Cambridge), Butler Lampson (Microsoft), and Silvio Micali (MIT), all of which are known for their sometimes conflicting but always interesting views. This year, PODC will also feature a series of lectures illustrating and celebrating the impact of the work of Michael Fischer, in honor of his sixtieth birthday, by: Leslie Lamport, Microsoft, Nancy Lynch, MIT, Albert Meyer, MIT, and Rebecca Wright, Stevens Inst. of Tech.. Topics are not announced yet but considering the speakers, I am sure these presentations will also be of interest to crypto/security folks. So, please participate and submit and encourage others to do so; e.g. please post the CFP in relevant forums. PODC especially encourages student participation, and a prize will be given to the best student paper; we may be able also to partially sponsor some of the students participating and presenting, depending on budget. PODC'03 received generous support from Microsoft and Sun Microsystems. If you are interested in making additional contributions, possibly for sponsoring a specific purpose, please contact the general chair, Elizabeth Borowsky, borowsky@cs.bc.edu (Boston College). Looking forward to your submissions and to see you in PODC 2003! Amir Herzberg http://amir.herzberg.name >Content Protection Technologies >Jeffrey B. Lotspiech, Tushar Chandra, Donald E. Leake Jr. > >Abstract > >The entertainment industry is in the midst of a digital revolution, >the growth of which seems only limited by concerns about the >unauthorized redistribution of perfect copies that digital technology >enables. Several content protection technologies have been deployed >already in consumer electronic devices, and more are in the works. In >the near future, the average person's encounter with cryptography >will not be restricted to access to ATM machines, but will include his >TV, his stereo, and his home entertainment network. We trace the >history of digital content protection technologies, starting with Copy >Generation Management System found on Digital Audio Tape, to the >Content Scrambling System used on DVD video, and moving on to more >cryptographically sound technologies like Digital Transmission Content >Protection used on the IEEE digital 1394 bus, and Content Protection >for Recordable Media used on DVD Audio, DVD video recorders, and the >Secure Digital Memory Card. It turns out that the relatively new area >of cryptography called broadcast encryption has found an enthusiastic >acceptance in content protection applications. In fact, the content >protection application has inspired recent theoretical advances in >this area. > >One newly-defined problem in content protection is called "authorized >domains". The idea is that the consumer's extended home becomes a >domain in which content can be copied and moved without restriction. >The consumer only encounters technical obstacles when he/she tries to >widely redistribute the copyrighted content. This requires that the >entertainment devices in the home, which may be only intermittently >connected, act as a distributed system to agree upon common >cryptographic keys. Although public-key systems can provide this >function, it turns out that broadcast encryption can also work in this >application, and has some intriguing advantages. > >However, not all content protection is based on cryptography. We >discuss signal-processing based technologies like MacroVision and >digital watermarking. Our view is that cryptography and signal-based >technologies are not competitors, but instead complement each >other. Cryptographic solutions should dominate while the content >remains in the digital domain. Once the content is rendered in >analogue form for viewing or listening, signal processing takes over, >to provide the last line of defense. > >As technologists we would like to think that content protection is >fundamentally about solving the technical problems, but we have come >to realize that is actually the lawyers, not engineers, that have the >tougher job. A complete content protection solution is mainly about >licensing, not about the technology. The technology acts as the >licensing "hook". It is the license that the manufacturer signs to, >for example, obtain keys to play a DVD audio, that obligates him to >build devices that obey the copying rules. In an ideal world, all the >licenses for all the different copy protection schemes interlock to >form a chain of license obligations, from the original source down to >the final rendering in the user's home. > >---------------------------- > >Incentives and Internet Computation >Joan Feigenbaum and Scott Shenker > >Traditional treatments of distributed computation typically assume >nodes to be either cooperative (i.e., they execute the prescribed >algorithm) or Byzantine (i.e., they can act in an arbitrary fashion). >However, to properly model the Internet, in which distributed >computation and autonomous agents prevail, one must also consider >selfish agents that maximize their own utility. To cope with selfish >agents, system designers must develop mechanisms in which cooperation >is in each agent's self-interest; we call such mechanisms >incentive-compatible. This tutorial will first introduce the >computer-science audience to the economic theory that forms the basis >for the design and analysis of incentive-compatible Internet >algorithms. It will then review previous results in this area, >including those on interdomain routing and multicast cost sharing. >Finally, it will present several promising research directions and >pose some specific open problems. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Sun Jan 5 02:21:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01698 for ; Sun, 5 Jan 2003 02:21:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h057UeY11853 for cfrg-archive@odin.ietf.org; Sun, 5 Jan 2003 02:30:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h057UeJ11850 for ; Sun, 5 Jan 2003 02:30:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01681 for ; Sun, 5 Jan 2003 02:20:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h057U6J11829; Sun, 5 Jan 2003 02:30:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h057TAJ11795 for ; Sun, 5 Jan 2003 02:29:10 -0500 Received: from exch-gw-ab.EXCHPROD.USA.NET (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01672 for ; Sun, 5 Jan 2003 02:19:01 -0500 (EST) Received: from EXCH-MR-AA.EXCHPROD.USA.NET ([10.26.48.53]) by exch-gw-ab.EXCHPROD.USA.NET with Microsoft SMTPSVC(5.0.2195.5329); Sun, 5 Jan 2003 00:22:08 -0700 Received: from 10.26.48.53 by EXCH-MR-AA.EXCHPROD.USA.NET (InterScan E-Mail VirusWall NT); Sun, 05 Jan 2003 00:22:08 -0700 (Mountain Standard Time) Received: from golden ([67.119.27.168]) by EXCH-MR-AA.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Sun, 5 Jan 2003 00:22:07 -0700 Message-ID: <014901c2b48b$2ab712d0$640a000a@golden> From: "Gordon Mohr" To: , "Amir Herzberg" References: <5.1.1.6.0.20030105084442.00ab75d8@mailhost.cs.biu.ac.il> Subject: Re: [Cfrg] Weakness in rotation to create alternative secure hash? Date: Sat, 4 Jan 2003 23:22:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 05 Jan 2003 07:22:07.0835 (UTC) FILETIME=[27A4A2B0:01C2B48B] Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Amir Herzberg writes: > I think David Wagner's second suggestion requires the two hash functions to > be `independant` (and only known proof is in the random oracle model): > > > > > (2) Use a different hash function at the leaves than at > > > > internal nodes. In other words, we compute the hash value > > > > at a leaf node as Hash("leaf",x) where x is the data > > > > associated at that leaf; we compute the hash value at > > > > an internal node as Hash("internal",l,r) where l,r are > > > > as above. > > Considering Gordon's suggestion/question re a using two highly related hash > functions, namely the leaf function being identical to the internal > function except for rotation... this specific proposal seems very weak, in > fact insecure for any specific hash function (i.e. even in the `random > oracle model`). This is most trivial if you consider rotation of size n, > where n is the length of the output of the hash (e.g. 160 bits); in this > case we just permutated the order of the blocks to the internal hash > function... In fact, this seems to work also for any rotation e.g. one bit > (or one byte). Or did I get it wrong (I admit I haven't checked all > details...)? Clearly the case where the rotation r = the output hash length n, you've got a null transformation, and the derived hash is not usefully different. I'm conjecturing that for any r < n, the derived (rotated) hash is just as secure -- with regard to the base (unrotated) hash -- as a completely independent hash algorithm would be. At least in the case of avoiding collisions at the end of a tree-hash process, I haven't yet found a problematic situation. But I could easily be missing something. - Gordon _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Sun Jan 5 06:05:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03891 for ; Sun, 5 Jan 2003 06:05:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h05BEqQ27050 for cfrg-archive@odin.ietf.org; Sun, 5 Jan 2003 06:14:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05BEqJ27047 for ; Sun, 5 Jan 2003 06:14:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03887 for ; Sun, 5 Jan 2003 06:04:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05BDeJ27032; Sun, 5 Jan 2003 06:13:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05BBSJ26992 for ; Sun, 5 Jan 2003 06:11:28 -0500 Received: from sunbeam.cs.biu.ac.il (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03819 for ; Sun, 5 Jan 2003 06:01:13 -0500 (EST) Received: from biu-xjbs42banj6.herzberg.name ([132.70.4.58]) by sunbeam.cs.biu.ac.il with ESMTP id h05B4MZ19717; Sun, 5 Jan 2003 13:04:23 +0200 (IST) Message-Id: <5.1.1.6.0.20030105115205.00b26c60@mailhost.cs.biu.ac.il> X-Sender: herzbea@mailhost.cs.biu.ac.il X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sun, 05 Jan 2003 13:09:47 +0200 To: "Gordon Mohr" , From: Amir Herzberg Subject: Re: [Cfrg] Weakness in rotation to create alternative secure hash? In-Reply-To: <014901c2b48b$2ab712d0$640a000a@golden> References: <5.1.1.6.0.20030105084442.00ab75d8@mailhost.cs.biu.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Gordon and all: Reading before I somehow missed and thought you apply the rotation to the inputs... sorry! Of course you apply it to the outputs... This design seem secure if the hash function is collision resistant as well as resistant to rotated collision, i.e. to finding x, y s.t. h(x)=r(h(y)) where r() is the rotation function. Both properties hold under the `random oracle analysis`. However, I think for any real application it is desirable to minimize the assumptions and requirements from the hash function; I'm therefore not sure if there's sufficient motivation for using this construction. It is easy to demonstrate an artificial (impractical) example of a collision resistant hash where finding `rotated collisions` is easy. Best, Amir _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Thu Jan 9 15:46:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25796 for ; Thu, 9 Jan 2003 15:46:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09KwNY24419 for cfrg-archive@odin.ietf.org; Thu, 9 Jan 2003 15:58:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09KwNJ24416 for ; Thu, 9 Jan 2003 15:58:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25749 for ; Thu, 9 Jan 2003 15:45:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09KvLJ24356; Thu, 9 Jan 2003 15:57:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09KtrJ24295 for ; Thu, 9 Jan 2003 15:55:53 -0500 Received: from woodstock.binhost.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25686 for ; Thu, 9 Jan 2003 15:43:31 -0500 (EST) Received: (qmail 7772 invoked from network); 9 Jan 2003 20:46:26 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.217.223) by woodstock.binhost.com with SMTP; 9 Jan 2003 20:46:26 -0000 Message-Id: <5.2.0.9.2.20030109154422.020f0840@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 09 Jan 2003 15:46:45 -0500 To: cfrg@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Cfrg] Moving forward with draft-housley-ccm-mode-01.txt Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , I have posted the CCM specification in draft-housley-ccm-mode-01.txt. At the IETF in Atlanta, I gave a presentation on the mode at the CFRG. I asked for comments to be sent to the list. So far, no one has posted any. I would like to proceed with publication as an RFC, so if anyone has comments, please send them now. Russ _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Mon Jan 13 17:50:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27183 for ; Mon, 13 Jan 2003 17:50:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DN4ku29986 for cfrg-archive@odin.ietf.org; Mon, 13 Jan 2003 18:04:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DN4kJ29983 for ; Mon, 13 Jan 2003 18:04:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27143 for ; Mon, 13 Jan 2003 17:50:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DN0FJ29535; Mon, 13 Jan 2003 18:00:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0CMrdJ29624 for ; Sun, 12 Jan 2003 17:53:39 -0500 Received: from mx2.cypherpunks.ca (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16140 for ; Sun, 12 Jan 2003 17:39:41 -0500 (EST) X-Envelope-To: cfrg@ietf.org Received: (from news@localhost) by mx2.cypherpunks.ca (8.11.0/8.11.0) id h0CMJRE04853 for cfrg@ietf.org; Sun, 12 Jan 2003 14:19:27 -0800 To: cfrg@ietf.org Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-cfrg Subject: Re: [Cfrg] Bit-rotation to create alternative secure hash? (was re: Merkle Hash Tree Weakness - Request for Advice) Date: 12 Jan 2003 22:19:27 GMT Organization: University of California, Berkeley Lines: 25 Distribution: isaac Message-ID: References: <019101c2b307$c8a0f590$640a000a@golden> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1042409967 4804 128.32.153.211 (12 Jan 2003 22:19:27 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 12 Jan 2003 22:19:27 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Gordon Mohr wrote: >Consider the secure hash created by taking an existing secure >hash, and applying a final 1-bit-left-rotation step to its output, >with wraparound. > >In approach (2) above, would it be reasonable to use a standard >secure hash as the "leaf" function , and the shifted version of >the same secure hash as the "internal" function? I don't know, but I'm a bit confused why you're asking. What advantages does bit-rotation have over the input separation method I described in my email? This is not intended to be a hostile question. I just want to understand why you are asking. We know that the input separation method I described works. The bit-rotation method might work, or it might not, it would require some thought and analysis to decide which is the case. Before I put in the time to do that kind of analysis, I want to understand what the motivation might be. In general, when we have a well-analyzed method that is known to work, I'm reluctant to invent new methods, if the standard method works acceptable well. I'll note that performance can't be the answer. Both the bit-rotation and input separation methods should have comparable performance characteristics. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg From mailnull@www1.ietf.org Mon Jan 13 18:46:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28611 for ; Mon, 13 Jan 2003 18:46:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E00jv00819 for cfrg-archive@odin.ietf.org; Mon, 13 Jan 2003 19:00:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E00iJ00816 for ; Mon, 13 Jan 2003 19:00:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28561 for ; Mon, 13 Jan 2003 18:46:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DNxFJ00739; Mon, 13 Jan 2003 18:59:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DNwkJ00722 for ; Mon, 13 Jan 2003 18:58:46 -0500 Received: from exch-gw-ab.EXCHPROD.USA.NET (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28507 for ; Mon, 13 Jan 2003 18:44:21 -0500 (EST) Received: from EXCH-MR-AA.EXCHPROD.USA.NET ([10.26.48.53]) by exch-gw-ab.EXCHPROD.USA.NET with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 16:47:40 -0700 Received: from 10.26.48.53 by EXCH-MR-AA.EXCHPROD.USA.NET (InterScan E-Mail VirusWall NT); Mon, 13 Jan 2003 16:47:40 -0700 (Mountain Standard Time) Received: from golden ([66.124.227.51]) by EXCH-MR-AA.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 16:47:39 -0700 Message-ID: <011401c2bb5e$2815c330$640a000a@golden> From: "Gordon Mohr" To: Subject: Fw: [Cfrg] Bit-rotation to create alternative secure hash? (was re: Merkle Hash Tree Weakness - Request for Advice) Date: Mon, 13 Jan 2003 15:47:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 13 Jan 2003 23:47:39.0999 (UTC) FILETIME=[2876CEF0:01C2BB5E] Content-Transfer-Encoding: 7bit Sender: cfrg-admin@ietf.org Errors-To: cfrg-admin@ietf.org X-BeenThere: cfrg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Crypto Forum Research Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David Wagner writes: > Gordon Mohr wrote: > >Consider the secure hash created by taking an existing secure > >hash, and applying a final 1-bit-left-rotation step to its output, > >with wraparound. > > > >In approach (2) above, would it be reasonable to use a standard > >secure hash as the "leaf" function , and the shifted version of > >the same secure hash as the "internal" function? > > I don't know, but I'm a bit confused why you're asking. What advantages > does bit-rotation have over the input separation method I described in > my email? Some speculative thoughts were... - It could be beneficial for the hash of leaf segments to be a common, unaltered original hash algorithm; this would allow cross- referencing of leaf segments with other applications which use only that plain algorithm. - It will avoid trivially predictable cross-algorithm collisions between different inputs. That is, with the "different salt for leaves and nodes" method, you establish that for short input, tree(alg)( input ) == alg( 0x00 || input ). If in fact some applications or the system as a whole is using a mixture of tree(alg)() and alg(), some coders may assuming that collisions between hashes are as hard to find as collisions within any one hash. There thus might be places where a single lookup structure is keyed by multiple hashes, and thus where confusion/collisions between related (but non-identical) inputs could occur. While due care and proper labelling of keys can avoid this problem, it also seems that using bit-rotation to create the separate hash function can avoid the problem. - Some future application might have use for a file (and verification tree) stitched together with mixed-size and arbitrarily-large leaves. For example, "assemble a file from the segment with hash W, segment with hash X, segment with hash Y, and segment with hash Z -- where each segment may be either a byte range of any length with that hash, or a composite of other segments with that treehash." Such a scenario would probably want to use an unsalted, standard, cross-referenceable algorithm for all bytes ranges of any length, and would need a truly independent algorithm for the node combinations -- and it seems like a bit-rotated version of the first algorithm could be sufficiently independent, while any input-salted version unavoidably has collisions with the unsalted version. > This is not intended to be a hostile question. I just want to > understand why you are asking. We know that the input separation method > I described works. The bit-rotation method might work, or it might not, > it would require some thought and analysis to decide which is the case. > Before I put in the time to do that kind of analysis, I want to understand > what the motivation might be. In general, when we have a well-analyzed > method that is known to work, I'm reluctant to invent new methods, > if the standard method works acceptable well. In fact, Justin and I have pretty much settled on the approach of prefixing leaf input with a 0x00 byte, and node concatenation input with a 0x01 byte, as that seems the safe, well-worn approach. However, I remain curious about the bit-rotation transformation as a potential remedy -- if not here and now, then perhaps in some other future case where similar cross-hash issues become important. I don't see any obvious problems, but I don't trust my own analysis -- so I wanted to throw the idea out for wider consideration while the topic remained fresh. Thanks, - Gordon _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg