From hash-bounces@lists.ietf.org Thu Jun 09 15:29:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgSiS-0002e6-VN; Thu, 09 Jun 2005 15:29:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgSiR-0002e1-IE for hash@megatron.ietf.org; Thu, 09 Jun 2005 15:29: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 PAA08023 for ; Thu, 9 Jun 2005 15:29:21 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DgT3w-0004em-U5 for hash@ietf.org; Thu, 09 Jun 2005 15:51:38 -0400 Received: (qmail 4902 invoked by uid 0); 9 Jun 2005 19:29:12 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.33.189) by woodstock.binhost.com with SMTP; 9 Jun 2005 19:29:12 -0000 Message-Id: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 09 Jun 2005 15:28:58 -0400 To: hash@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: [Hash] 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 There are now 41 members on this mail list. That seems like enough to get the discussion going. I have attached the proposed charter for the Hash WG. I have asked Paul Hoffman to act as chair for the Hash BoF in Paris. He has agreed. So, now I will let Paul lead a discussion about this proposed charter. Thanks, Russ Housley IETF Security Area Director = = = = = = = = = = One-way Hash Function BoF (hash) Security Area Director: Sam Hartman Russ Housley Security Area Advisor: Russ Housley Mailing Lists: General Discussion: hash@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/hash Archive: http://www.ietf.org/mail-archive/web/hash/index.html Description of Proposed Working Group: Recently, a team of researchers reported that the SHA-1 one-way hash function offers significantly less collision resistance than could be expected from a cryptographic hash function with an output of 160 bits. This result has inspired significant research activities in government and academia. Additional information regarding the security of current one-way hash functions, as well as proposals for new one-way hash functions, are expected. The proposed working group responds to the current state of research in this area. However, additional research is likely to provide new insights as the working group progresses. A three-phase approach is envisioned. The second and third phases will be pursued only if it is clear that the international cryptographic community is actively participating in the working group. The first phase of the working group will specify one or more standards- track mechanism replace or strengthen SHA-1. At least two approaches will be considered: 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. For example, as an alternative to SHA-1, the truncation mechanism could be used create a 160-bit result from the output of the SHA-256 one-way hash function. 2) Including a random value in the hash function computation. The random block used is transferred as a parameter in the algorithm identifier. This approach is sometimes called a "salted" or "randomized" hash function. The first phase may also consider other potential solutions, and one or more standards-track mechanism will be selected. The second phase 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 third phase will identify one or more standards-track one-way hash functions that fulfill the requirements stated in the BCP documents developed in phase two. Guidance will also be developed to assist protocol developers in the selection among the standards-track one-way hash functions. Goals and Milestones: September 2005: Charter to authorize phase one. October 2005: Submit initial draft of truncation mechanism. February 2006: WG Last Call on truncation mechanism. April 2006: Submit truncation mechanism as Proposed Standard. June 2006: Recharter to authorize phase two. _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Thu Jun 09 16:03:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgTFD-0002PW-1X; Thu, 09 Jun 2005 16:03:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgTFB-0002P8-LH for hash@megatron.ietf.org; Thu, 09 Jun 2005 16:03:13 -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 QAA12873 for ; Thu, 9 Jun 2005 16:03:11 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgTai-0006sr-24 for hash@ietf.org; Thu, 09 Jun 2005 16:25:28 -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 j59K35Q2067248 for ; Thu, 9 Jun 2005 13:03:07 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> References: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> Date: Thu, 9 Jun 2005 13:02:47 -0700 To: hash@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Subject: [Hash] Charter discussion, round 1 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 Thanks, Russ. So, there are a couple of questions about the charter that we can possibly run in parallel: - Did we leave anything out of phase 1 that would be both useful and possible for an IETF Working Group to achieve before we start phase 2? - Are the milestones for phase 1 reasonable? - Is the three-phase approach reasonable? - Do we need to change or add to phases 2 and 3 now, or can we wait until the already-scheduled recharter? For those of you planning on being at the Paris meeting, let's see where we get on the charter discussion before we start to set an agenda for our face-to-face meeting. --Paul Hoffman, Director --VPN Consortium --------------------------------------------------- One-way Hash Function BoF (hash) Security Area Director: Sam Hartman Russ Housley Security Area Advisor: Russ Housley Mailing Lists: General Discussion: hash@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/hash Archive: http://www.ietf.org/mail-archive/web/hash/index.html Description of Proposed Working Group: Recently, a team of researchers reported that the SHA-1 one-way hash function offers significantly less collision resistance than could be expected from a cryptographic hash function with an output of 160 bits. This result has inspired significant research activities in government and academia. Additional information regarding the security of current one-way hash functions, as well as proposals for new one-way hash functions, are expected. The proposed working group responds to the current state of research in this area. However, additional research is likely to provide new insights as the working group progresses. A three-phase approach is envisioned. The second and third phases will be pursued only if it is clear that the international cryptographic community is actively participating in the working group. The first phase of the working group will specify one or more standards- track mechanism replace or strengthen SHA-1. At least two approaches will be considered: 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. For example, as an alternative to SHA-1, the truncation mechanism could be used create a 160-bit result from the output of the SHA-256 one-way hash function. 2) Including a random value in the hash function computation. The random block used is transferred as a parameter in the algorithm identifier. This approach is sometimes called a "salted" or "randomized" hash function. The first phase may also consider other potential solutions, and one or more standards-track mechanism will be selected. The second phase 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 third phase will identify one or more standards-track one-way hash functions that fulfill the requirements stated in the BCP documents developed in phase two. Guidance will also be developed to assist protocol developers in the selection among the standards-track one-way hash functions. Goals and Milestones: September 2005: Charter to authorize phase one. October 2005: Submit initial draft of truncation mechanism. February 2006: WG Last Call on truncation mechanism. April 2006: Submit truncation mechanism as Proposed Standard. June 2006: Recharter to authorize phase two. _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash --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 Jun 14 18:15:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiJhM-0004v4-PY; Tue, 14 Jun 2005 18:15:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiJhK-0004uz-QC for hash@megatron.ietf.org; Tue, 14 Jun 2005 18:15:54 -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 SAA12160 for ; Tue, 14 Jun 2005 18:15:52 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiK3t-0006VZ-UX for hash@ietf.org; Tue, 14 Jun 2005 18:39:14 -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 j5EMFlib070610 for ; Tue, 14 Jun 2005 15:15:48 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> Date: Tue, 14 Jun 2005 15:15:43 -0700 To: hash@ietf.org From: Paul Hoffman Subject: Re: [Hash] Charter discussion, round 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 nudge, and a re-send for the new people on the list. While it would be lovely to think that there are absolutely no issues with the suggested charter, IETF history suggests there are probably at least a few comments. ]] Thanks, Russ. So, there are a couple of questions about the charter that we can possibly run in parallel: - Did we leave anything out of phase 1 that would be both useful and possible for an IETF Working Group to achieve before we start phase 2? - Are the milestones for phase 1 reasonable? - Is the three-phase approach reasonable? - Do we need to change or add to phases 2 and 3 now, or can we wait until the already-scheduled recharter? For those of you planning on being at the Paris meeting, let's see where we get on the charter discussion before we start to set an agenda for our face-to-face meeting. --Paul Hoffman, Director --VPN Consortium --------------------------------------------------- One-way Hash Function BoF (hash) Security Area Director: Sam Hartman Russ Housley Security Area Advisor: Russ Housley Mailing Lists: General Discussion: hash@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/hash Archive: http://www.ietf.org/mail-archive/web/hash/index.html Description of Proposed Working Group: Recently, a team of researchers reported that the SHA-1 one-way hash function offers significantly less collision resistance than could be expected from a cryptographic hash function with an output of 160 bits. This result has inspired significant research activities in government and academia. Additional information regarding the security of current one-way hash functions, as well as proposals for new one-way hash functions, are expected. The proposed working group responds to the current state of research in this area. However, additional research is likely to provide new insights as the working group progresses. A three-phase approach is envisioned. The second and third phases will be pursued only if it is clear that the international cryptographic community is actively participating in the working group. The first phase of the working group will specify one or more standards- track mechanism replace or strengthen SHA-1. At least two approaches will be considered: 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. For example, as an alternative to SHA-1, the truncation mechanism could be used create a 160-bit result from the output of the SHA-256 one-way hash function. 2) Including a random value in the hash function computation. The random block used is transferred as a parameter in the algorithm identifier. This approach is sometimes called a "salted" or "randomized" hash function. The first phase may also consider other potential solutions, and one or more standards-track mechanism will be selected. The second phase 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 third phase will identify one or more standards-track one-way hash functions that fulfill the requirements stated in the BCP documents developed in phase two. Guidance will also be developed to assist protocol developers in the selection among the standards-track one-way hash functions. Goals and Milestones: September 2005: Charter to authorize phase one. October 2005: Submit initial draft of truncation mechanism. February 2006: WG Last Call on truncation mechanism. April 2006: Submit truncation mechanism as Proposed Standard. June 2006: Recharter to authorize phase two. _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash --Paul Hoffman, Director --VPN Consortium _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash --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 Jun 14 18:42:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiK6u-0003mh-3Q; Tue, 14 Jun 2005 18:42:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiK6s-0003mS-M0 for hash@megatron.ietf.org; Tue, 14 Jun 2005 18:42: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 SAA14793 for ; Tue, 14 Jun 2005 18:42:15 -0400 (EDT) Received: from smtp2.pacifier.net ([64.255.237.172]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiKTN-0008IO-DU for hash@ietf.org; Tue, 14 Jun 2005 19:05:38 -0400 Received: from romans (unknown [207.202.179.27]) by smtp2.pacifier.net (Postfix) with ESMTP id A506B830E6 for ; Tue, 14 Jun 2005 15:41:56 -0700 (PDT) From: "Jim Schaad" To: Subject: RE: [Hash] Charter discussion, round 1 Date: Tue, 14 Jun 2005 15:43:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVxMGZiovvAUZbyREu91NZb7i0YkQAATZsA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: Message-Id: <20050614224156.A506B830E6@smtp2.pacifier.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit 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 Qustions that I have are: 1. Is this new hash function we are considering in phase 1 going to be the same length as SHA-1 or not? This would appear to be implied by the goals. Would replacement of SHA-1 with SHA-256 intact be considered as reasonable in the first phase? 2. Can we do a reasonable job with phase 1 without having atleast some idea of what would be required from phase 2, even if it is not a full set of requirements so that we can evaluate phase 1 againist some type of critera. Do we then want to start phase 2 (even if it is not completed) right away? 3. I think that adding explicit deliverables for phase 2 could wait, I think it must wait until a re-charter for phase 3. 4. If a new hash function is recommended by this group, will it also be responible to deal with any new signature algorithms and so forth that come out of this decision? For example, DSA is fixed on using SHA-1 and would need changes to adapt to any new hash algorithm be it a trucated or a seeded hash algorithm. jim -----Original Message----- From: hash-bounces@lists.ietf.org [mailto:hash-bounces@lists.ietf.org] On Behalf Of Paul Hoffman Sent: Tuesday, June 14, 2005 3:16 PM To: hash@ietf.org Subject: Re: [Hash] Charter discussion, round 1 [[ Another nudge, and a re-send for the new people on the list. While it would be lovely to think that there are absolutely no issues with the suggested charter, IETF history suggests there are probably at least a few comments. ]] Thanks, Russ. So, there are a couple of questions about the charter that we can possibly run in parallel: - Did we leave anything out of phase 1 that would be both useful and possible for an IETF Working Group to achieve before we start phase 2? - Are the milestones for phase 1 reasonable? - Is the three-phase approach reasonable? - Do we need to change or add to phases 2 and 3 now, or can we wait until the already-scheduled recharter? For those of you planning on being at the Paris meeting, let's see where we get on the charter discussion before we start to set an agenda for our face-to-face meeting. --Paul Hoffman, Director --VPN Consortium --------------------------------------------------- One-way Hash Function BoF (hash) Security Area Director: Sam Hartman Russ Housley Security Area Advisor: Russ Housley Mailing Lists: General Discussion: hash@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/hash Archive: http://www.ietf.org/mail-archive/web/hash/index.html Description of Proposed Working Group: Recently, a team of researchers reported that the SHA-1 one-way hash function offers significantly less collision resistance than could be expected from a cryptographic hash function with an output of 160 bits. This result has inspired significant research activities in government and academia. Additional information regarding the security of current one-way hash functions, as well as proposals for new one-way hash functions, are expected. The proposed working group responds to the current state of research in this area. However, additional research is likely to provide new insights as the working group progresses. A three-phase approach is envisioned. The second and third phases will be pursued only if it is clear that the international cryptographic community is actively participating in the working group. The first phase of the working group will specify one or more standards- track mechanism replace or strengthen SHA-1. At least two approaches will be considered: 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. For example, as an alternative to SHA-1, the truncation mechanism could be used create a 160-bit result from the output of the SHA-256 one-way hash function. 2) Including a random value in the hash function computation. The random block used is transferred as a parameter in the algorithm identifier. This approach is sometimes called a "salted" or "randomized" hash function. The first phase may also consider other potential solutions, and one or more standards-track mechanism will be selected. The second phase 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 third phase will identify one or more standards-track one-way hash functions that fulfill the requirements stated in the BCP documents developed in phase two. Guidance will also be developed to assist protocol developers in the selection among the standards-track one-way hash functions. Goals and Milestones: September 2005: Charter to authorize phase one. October 2005: Submit initial draft of truncation mechanism. February 2006: WG Last Call on truncation mechanism. April 2006: Submit truncation mechanism as Proposed Standard. June 2006: Recharter to authorize phase two. _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash --Paul Hoffman, Director --VPN Consortium _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash --Paul Hoffman, Director --VPN Consortium _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Wed Jun 15 18:43:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Digbv-0003Gv-5F; Wed, 15 Jun 2005 18:43:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DigJV-00080y-GE for hash@megatron.ietf.org; Wed, 15 Jun 2005 18:24:49 -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 SAA12141 for ; Wed, 15 Jun 2005 18:24:46 -0400 (EDT) Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DiggG-0002OA-Kt for hash@ietf.org; Wed, 15 Jun 2005 18:48:21 -0400 Received: (qmail 59393 invoked by uid 1016); 15 Jun 2005 22:25:11 -0000 Date: 15 Jun 2005 22:25:11 -0000 Message-ID: <20050615222511.59392.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] Charter discussion, round 1 References: <20050614224156.A506B830E6@smtp2.pacifier.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-Mailman-Approved-At: Wed, 15 Jun 2005 18:43:50 -0400 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 Randomized hashing requires even more protocol changes than moving to a longer hash, not to mention implementation changes. So it doesn't make sense to consider randomized hashing without considering longer hashes. ---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 Wed Jun 15 22:24:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dik3p-0004md-Lt; Wed, 15 Jun 2005 22:24:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dik3o-0004mY-OM for hash@megatron.ietf.org; Wed, 15 Jun 2005 22:24:52 -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 WAA11807 for ; Wed, 15 Jun 2005 22:24:50 -0400 (EDT) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DikQb-0007WQ-0a for hash@ietf.org; Wed, 15 Jun 2005 22:48:27 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 637028A02D; Wed, 15 Jun 2005 19:31:14 -0700 (PDT) To: "Jim Schaad" Subject: Re: [Hash] Charter discussion, round 1 In-reply-to: Your message of "Tue, 14 Jun 2005 15:43:44 PDT." <20050614224156.A506B830E6@smtp2.pacifier.net> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Wed, 15 Jun 2005 19:24:36 -0700 From: EKR Message-Id: <20050616023114.637028A02D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Jim Schaad wrote: > 1. Is this new hash function we are considering in phase 1 going to be the > same length as SHA-1 or not? This would appear to be implied by the goals. > Would replacement of SHA-1 with SHA-256 intact be considered as reasonable > in the first phase? Right. It's important here to distinguish between DSA/ECDSA and RSA. There's basically no advantage to using a truncated SHA-256 over straight SHA-256 with RSA. The performance is (of course) the same and there's plenty of room for a 256-bit hash in a 1024-bit RSA block (and people using 512-bit deserve what they get). So, defining truncated hashes really only makes sense for ECDSA/DSA and other algorithms with fixed input sizes.... -Ekr _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Wed Jun 15 22:52:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DikUF-0000yq-Sj; Wed, 15 Jun 2005 22:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DikUC-0000xo-Ki for hash@megatron.ietf.org; Wed, 15 Jun 2005 22:52:10 -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 WAA01779 for ; Wed, 15 Jun 2005 22:52:06 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DikhV-00013i-NH for hash@ietf.org; Wed, 15 Jun 2005 23:05:55 -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 j5G2gCuh068777 for ; Wed, 15 Jun 2005 19:42:13 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050615222511.59392.qmail@cr.yp.to> <20050616023114.637028A02D@laser.networkresonance.com> References: <20050614224156.A506B830E6@smtp2.pacifier.net> <20050615222511.59392.qmail@cr.yp.to> <20050616023114.637028A02D@laser.networkresonance.com> Date: Wed, 15 Jun 2005 19:41:58 -0700 To: hash@ietf.org From: Paul Hoffman Subject: Re: [Hash] Charter discussion, round 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 At 7:24 PM -0700 6/15/05, EKR wrote: >So, defining truncated hashes really only makes sense for ECDSA/DSA >and other algorithms with fixed input sizes.... At 10:25 PM +0000 6/15/05, D. J. Bernstein wrote: >Randomized hashing requires even more protocol changes than moving to a >longer hash, not to mention implementation changes. So it doesn't make >sense to consider randomized hashing without considering longer hashes. We have two use cases here, both of which are probably important. The first is algorithms with fixed input sizes; the second is protocols with fixed hash sizes (or variable hash sizes that max out at 128 or 160). Both seem worth investigating and documenting. --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 Jun 16 10:39:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivWG-0005oG-2w; Thu, 16 Jun 2005 10:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivWC-0005mS-LK for hash@megatron.ietf.org; Thu, 16 Jun 2005 10:38:59 -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 KAA27377 for ; Thu, 16 Jun 2005 10:38:51 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Divt6-00040W-7a for hash@ietf.org; Thu, 16 Jun 2005 11:02:37 -0400 Received: (qmail 17574 invoked by uid 0); 16 Jun 2005 14:37:38 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.17.75) by woodstock.binhost.com with SMTP; 16 Jun 2005 14:37:38 -0000 Message-Id: <6.2.1.2.2.20050616093927.0660b700@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 16 Jun 2005 10:30:42 -0400 To: "Jim Schaad" From: Russ Housley Subject: RE: [Hash] Charter discussion, round 1 In-Reply-To: <20050614224156.A506B830E6@smtp2.pacifier.net> References: <20050614224156.A506B830E6@smtp2.pacifier.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Jim: >1. Is this new hash function we are considering in phase 1 going to be the >same length as SHA-1 or not? This would appear to be implied by the goals. >Would replacement of SHA-1 with SHA-256 intact be considered as reasonable >in the first phase? This has already been discussed. Below I propose some words in the charter to capture the discussion. >2. Can we do a reasonable job with phase 1 without having atleast some idea >of what would be required from phase 2, even if it is not a full set of >requirements so that we can evaluate phase 1 againist some type of critera. >Do we then want to start phase 2 (even if it is not completed) right away? I do not think so. I think we understand the needs for signatures, which is the primary issue for phase 1. >3. I think that adding explicit deliverables for phase 2 could wait, I >think it must wait until a re-charter for phase 3. Are you saying that we can do a good job on Phase 2 even if the participation from the international crypto community is low? >4. If a new hash function is recommended by this group, will it also be >responible to deal with any new signature algorithms and so forth that come >out of this decision? For example, DSA is fixed on using SHA-1 and would >need changes to adapt to any new hash algorithm be it a trucated or a seeded >hash algorithm. If you are talking about the assignment of algorithm identifiers, I am not really concerned about who does it. A new hash function should not have deep ripples into the signature algorithms. It may have an impact on protocols to carry parameters. Russ = = = = = = Here is the proposed rewording of the charter discussion of phase 1: The first phase of the working group will specify one or more standards- track mechanism replace or strengthen SHA-1. Two classes of signature algorithm need to be considered. In support of RSA, there is no advantage to reducing the size of a longer hash function output; the RSA modulus size will easily accomodate large hash function output values. However, in support of DSA and ECDSA, the hash function output size nees to match the subgroup size. The irst phase will consider alt least two approches to strengthen one-way hash functions: 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. For example, an alternative to SHA-1, the truncation mechanism could be used create a 160-bit result from the output of the SHA-256 one-way hash function. 2) Including a random value in the hash function computation. The random block used is transferred as a parameter in the algorithm identifier. This approach is sometimes called a "salted" or "randomized" hash function. The first phase may also consider other potential solutions, and one or more standards-track mechanism will be selected. _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Thu Jun 16 10:49:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivgR-0007Rl-5a; Thu, 16 Jun 2005 10:49:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivgP-0007NJ-8p for hash@megatron.ietf.org; Thu, 16 Jun 2005 10:49: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 KAA27889 for ; Thu, 16 Jun 2005 10:49:23 -0400 (EDT) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diw3H-0004W4-5b for hash@ietf.org; Thu, 16 Jun 2005 11:13:10 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id E50948A02D; Thu, 16 Jun 2005 07:55:51 -0700 (PDT) To: Paul Hoffman Subject: Re: [Hash] Charter discussion, round 1 In-reply-to: Your message of "Wed, 15 Jun 2005 19:41:58 PDT." X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Thu, 16 Jun 2005 07:49:14 -0700 From: Eric Rescorla Message-Id: <20050616145551.E50948A02D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Hoffman wrote: > At 7:24 PM -0700 6/15/05, EKR wrote: > >So, defining truncated hashes really only makes sense for ECDSA/DSA > >and other algorithms with fixed input sizes.... > > At 10:25 PM +0000 6/15/05, D. J. Bernstein wrote: > >Randomized hashing requires even more protocol changes than moving to a > >longer hash, not to mention implementation changes. So it doesn't make > >sense to consider randomized hashing without considering longer hashes. > > We have two use cases here, both of which are probably important. The > first is algorithms with fixed input sizes; the second is protocols > with fixed hash sizes (or variable hash sizes that max out at 128 or > 160). Both seem worth investigating and documenting. Do you have a specific example in mind of the latter? -Ekr _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Thu Jun 16 10:52:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivjI-0007xo-8o; Thu, 16 Jun 2005 10:52:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivjH-0007xj-B4 for hash@megatron.ietf.org; Thu, 16 Jun 2005 10:52: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 KAA28092 for ; Thu, 16 Jun 2005 10:52:21 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Diw6B-0004iX-8q for hash@ietf.org; Thu, 16 Jun 2005 11:16:08 -0400 Received: (qmail 5449 invoked by uid 0); 16 Jun 2005 14:51:00 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.7.87) by woodstock.binhost.com with SMTP; 16 Jun 2005 14:51:00 -0000 Message-Id: <6.2.1.2.2.20050616104551.064bca50@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 16 Jun 2005 10:50:51 -0400 To: Thomas Roessler From: Russ Housley Subject: Re: [Hash] Charter discussion, round 1 In-Reply-To: <20050616081143.GC32581@raktajino.does-not-exist.org> References: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> <20050616081143.GC32581@raktajino.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: w3t-archive@w3.org, 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 Thomas: This text is intended to man that the salt is transferred along with the algorithm identifier some how. Using the 1988 ASN.1 syntax, an algorithm identifier is defined as: AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } In this structure, a new value would be assigned to identify the "SHA-1 with a salt" hash function, and the parameters field would carry the salt value. Russ At 04:11 AM 6/16/2005, Thomas Roessler wrote: >Hello, > >a quick question for clarification... > >On 2005-06-09 13:02:47 -0700, Paul Hoffman wrote: > > > 2) Including a random value in the hash function computation. The > > random block used is transferred as a parameter in the algorithm > > identifier. This approach is sometimes called a "salted" or > > "randomized" hash function. > >Is this meant to imply an approach where hash identifiers would look >like, say, "shaN-0xdeadbeef", 0xdeadbeef being the salt? Or is it >merely meant to imply that the seed would be transferred along with >the algorithm identifier, somehow? > >My concern with the first interpretation would be that it mixes >badly with XML Signature, where algorithm identifiers are URIs >(hence opaque), but where other mechanisms for passing parameters >are readily available. > >Thanks, >-- >Thomas Roessler, W3C _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Thu Jun 16 11:41:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwUy-00052c-Du; Thu, 16 Jun 2005 11:41:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiwUx-0004yo-FH for hash@megatron.ietf.org; Thu, 16 Jun 2005 11:41:43 -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 LAA03238 for ; Thu, 16 Jun 2005 11:41:37 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diwrr-0007x5-LA for hash@ietf.org; Thu, 16 Jun 2005 12:05:25 -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 j5GFfZeF035544; Thu, 16 Jun 2005 08:41:36 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050616145551.E50948A02D@laser.networkresonance.com> References: <20050616145551.E50948A02D@laser.networkresonance.com> Date: Thu, 16 Jun 2005 08:41:35 -0700 To: Eric Rescorla From: Paul Hoffman Subject: Re: [Hash] Charter discussion, round 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 7:49 AM -0700 6/16/05, Eric Rescorla wrote: > > We have two use cases here, both of which are probably important. The >> first is algorithms with fixed input sizes; the second is protocols >> with fixed hash sizes (or variable hash sizes that max out at 128 or >> 160). Both seem worth investigating and documenting. > >Do you have a specific example in mind of the latter? Nope, but if we find one, it will be important. If there are no IETF protocols with fixed hash sizes, but there are non-IETF protocols with them, we should probably still consider dealing with it. But, the main target of this phase is algorithms with fixed-size inputs. --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 Jun 16 16:00:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0XB-0008SY-JC; Thu, 16 Jun 2005 16:00:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0XB-0008ST-2I for hash@megatron.ietf.org; Thu, 16 Jun 2005 16:00:17 -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 QAA02112 for ; Thu, 16 Jun 2005 16:00:11 -0400 (EDT) Received: from sottmxsecs3.entrust.com ([216.191.252.14]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dj0u5-0000hx-M9 for hash@ietf.org; Thu, 16 Jun 2005 16:24:00 -0400 Received: (qmail 27277 invoked from network); 16 Jun 2005 19:59:59 -0000 Received: from robert.zuccherato@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.3.1; 16 Jun 2005 19:59:59 -0000 Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 16 Jun 2005 19:59:58 -0000 Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Jun 2005 16:00:00 -0400 Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F042741AD@sottmxs05.entrust.com> From: Robert Zuccherato To: "'Russ Housley'" Subject: RE: [Hash] Charter discussion, round 1 Date: Thu, 16 Jun 2005 15:59:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.5 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 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="===============0169956806==" 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. --===============0169956806== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C572AD.F813F253" 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_01C572AD.F813F253 Content-Type: text/plain I think we should remove ECDSA from the justification for a truncated hash. I'm looking at the May 18, 2005 draft which I think will be going for X9F ballot. It clearly states in the signature generation and verification sections that if the hash length is greater than log_2(n) (the subgroup size) then the leftmost log_2(n) bits of the hash function output should be used. Thus, they already appear to have solved this problem. If a similar approach was taken with DSA (which would have to be changed anyway to use anything other than SHA-1) then much of the justification for the definition of a truncated hash function would disappear. Robert Zuccherato. > -----Original Message----- > From: hash-bounces@lists.ietf.org > [mailto:hash-bounces@lists.ietf.org] On Behalf Of Russ Housley > Sent: June 16, 2005 10:31 AM > To: Jim Schaad > Cc: hash@ietf.org > Subject: RE: [Hash] Charter discussion, round 1 > = = = = = = > > Here is the proposed rewording of the charter discussion of phase 1: > > The first phase of the working group will specify one or more > standards- track mechanism replace or strengthen SHA-1. Two > classes of signature algorithm need to be considered. In > support of RSA, there is no advantage to reducing the size of > a longer hash function output; the RSA modulus size will > easily accomodate large hash function output values. > However, in support of DSA and ECDSA, the hash function > output size nees to match the subgroup size. > > The irst phase will consider alt least two approches to > strengthen one-way hash functions: > > 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. For example, an alternative to SHA-1, the truncation > mechanism could be used create a 160-bit result from the output > of the SHA-256 one-way hash function. > > 2) Including a random value in the hash function computation. The > random block used is transferred as a parameter in the algorithm > identifier. This approach is sometimes called a "salted" or > "randomized" hash function. > > The first phase may also consider other potential solutions, > and one or more standards-track mechanism will be selected. > > > _______________________________________________ > Hash mailing list > Hash@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hash > ------_=_NextPart_001_01C572AD.F813F253 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Hash] Charter discussion, round 1

I think we should remove ECDSA from the justification = for a truncated hash.  I'm looking at the May 18, 2005 draft which = I think will be going for X9F ballot.  It clearly states in the = signature generation and verification sections that if the hash length = is greater than log_2(n) (the subgroup size) then the leftmost log_2(n) = bits of the hash function output should be used.  Thus, they = already appear to have solved this problem. 

If a similar approach was taken with DSA (which would = have to be changed anyway to use anything other than SHA-1) then much = of the justification for the definition of a truncated hash function = would disappear.

        Robert = Zuccherato.

> -----Original Message-----
> From: hash-bounces@lists.ietf.org
> [mailto:hash-bounces@lists.ie= tf.org] On Behalf Of Russ Housley
> Sent: June 16, 2005 10:31 AM
> To: Jim Schaad
> Cc: hash@ietf.org
> Subject: RE: [Hash] Charter discussion, round = 1
> =3D =3D =3D =3D =3D =3D
>
> Here is the proposed rewording of the charter = discussion of phase 1:
>
> The first phase of the working group will = specify one or more
> standards- track mechanism replace or = strengthen SHA-1.  Two
> classes of signature algorithm need to be = considered.  In
> support of RSA, there is no advantage to = reducing the size of
> a longer hash function output; the RSA modulus = size will
> easily accomodate large hash function output = values. 
> However, in support of DSA and ECDSA, the hash = function
> output size nees to match the subgroup = size.
>
> The irst phase will consider alt least two = approches to
> strengthen one-way hash functions:
>
>    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.  For example, an alternative to SHA-1, the = truncation
>       mechanism = could be used create a 160-bit result from the output
>       of the = SHA-256 one-way hash function.
>
>    2) Including a random value = in the hash function computation. The
>       random = block used is transferred as a parameter in the algorithm
>       = identifier.  This approach is sometimes called a = "salted" or
>       = "randomized" hash function.
>
> The first phase may also consider other = potential solutions,
> and one or more standards-track mechanism will = be selected. 
>
>
> = _______________________________________________
> Hash mailing list
> Hash@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/hash=
>

------_=_NextPart_001_01C572AD.F813F253-- --===============0169956806== 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 --===============0169956806==-- From hash-bounces@lists.ietf.org Thu Jun 16 16:11:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0hb-0004XI-JL; Thu, 16 Jun 2005 16:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0hZ-0004Wo-Oj for hash@megatron.ietf.org; Thu, 16 Jun 2005 16:11:01 -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 QAA05170 for ; Thu, 16 Jun 2005 16:10:56 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dj14T-0001yl-4H for hash@ietf.org; Thu, 16 Jun 2005 16:34:45 -0400 Received: (qmail 9925 invoked by uid 0); 16 Jun 2005 20:10:30 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.149.16) by woodstock.binhost.com with SMTP; 16 Jun 2005 20:10:30 -0000 Message-Id: <6.2.1.2.2.20050616160909.0719a5b0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 16 Jun 2005 16:10:21 -0400 To: Robert Zuccherato From: Russ Housley Subject: RE: [Hash] Charter discussion, round 1 In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F042741AD@sottmxs05.entrust .com> References: <7A3E1242FA9989439AD1F9B2D71C287F042741AD@sottmxs05.entrust.com> Mime-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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="===============1854035553==" Sender: hash-bounces@lists.ietf.org Errors-To: hash-bounces@lists.ietf.org --===============1854035553== Content-Type: text/html; charset="us-ascii" Robert:

Thanks for letting me know about the built-in truncation.

See the proposed charter discussion for phase one below.

Russ

= = = = = = =

The first phase of the working group will specify one or more standards-
track mechanism replace or strengthen SHA-1.  Two classes of signature
algorithm need to be considered.  In support of RSA, there is no
advantage to reducing the size of a longer hash function output; the
RSA modulus size will easily accommodate large hash function output
values.  However, in support of DSA, the hash function output size
needs to match the subgroup size.

The first phase will consider alt least two approaches to strengthen
one-way hash functions:

  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.  For example, an alternative to SHA-1, the truncation
     mechanism could be used create a 160-bit result from the output
     of the SHA-256 one-way hash function.

  2) Including a random value in the hash function computation. The
     random block used is transferred as a parameter in the algorithm
     identifier.  This approach is sometimes called a "salted" or
     "randomized" hash function.

The first phase may also consider other potential solutions, and one or
more standards-track mechanism will be selected.


At 03:59 PM 6/16/2005, Robert Zuccherato wrote:

I think we should remove ECDSA from the justification for a truncated hash.  I'm looking at the May 18, 2005 draft which I think will be going for X9F ballot.  It clearly states in the signature generation and verification sections that if the hash length is greater than log_2(n) (the subgroup size) then the leftmost log_2(n) bits of the hash function output should be used.  Thus, they already appear to have solved this problem. 

If a similar approach was taken with DSA (which would have to be changed anyway to use anything other than SHA-1) then much of the justification for the definition of a truncated hash function would disappear.

        Robert Zuccherato.

> -----Original Message-----
> From: hash-bounces@lists.ietf.org
> [ mailto:hash-bounces@lists.ietf.org] On Behalf Of Russ Housley
> Sent: June 16, 2005 10:31 AM
> To: Jim Schaad
> Cc: hash@ietf.org
> Subject: RE: [Hash] Charter discussion, round 1
> = = = = = =
>
> Here is the proposed rewording of the charter discussion of phase 1:
>
> The first phase of the working group will specify one or more
> standards- track mechanism replace or strengthen SHA-1.  Two
> classes of signature algorithm need to be considered.  In
> support of RSA, there is no advantage to reducing the size of
> a longer hash function output; the RSA modulus size will
> easily accomodate large hash function output values. 
> However, in support of DSA and ECDSA, the hash function
> output size nees to match the subgroup size.
>
> The irst phase will consider alt least two approches to
> strengthen one-way hash functions:
>
>    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.  For example, an alternative to SHA-1, the truncation
>       mechanism could be used create a 160-bit result from the output
>       of the SHA-256 one-way hash function.
>
>    2) Including a random value in the hash function computation. The
>       random block used is transferred as a parameter in the algorithm
>       identifier.  This approach is sometimes called a "salted" or
>       "randomized" hash function.
>
> The first phase may also consider other potential solutions,
> and one or more standards-track mechanism will be selected. 
>
>
> _______________________________________________
> Hash mailing list
> Hash@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/hash
>
--===============1854035553== 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 --===============1854035553==-- From hash-bounces@lists.ietf.org Fri Jun 17 11:43:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjJ0E-0005pd-Or; Fri, 17 Jun 2005 11:43:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjJ0C-0005oG-E4 for hash@megatron.ietf.org; Fri, 17 Jun 2005 11:43:28 -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 LAA28347 for ; Fri, 17 Jun 2005 11:43:25 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DjJNH-0005bf-HC for hash@ietf.org; Fri, 17 Jun 2005 12:07:22 -0400 Received: (qmail 24012 invoked by uid 0); 17 Jun 2005 15:43:16 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.18.238) by woodstock.binhost.com with SMTP; 17 Jun 2005 15:43:16 -0000 Message-Id: <6.2.1.2.2.20050617114209.0640e0d0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 17 Jun 2005 11:43:16 -0400 To: Thomas Roessler From: Russ Housley Subject: Re: [Hash] Charter discussion, round 1 In-Reply-To: <20050617084345.GJ32581@raktajino.does-not-exist.org> References: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> <20050616081143.GC32581@raktajino.does-not-exist.org> <20050617084345.GJ32581@raktajino.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: w3t-archive@w3.org, 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 Perhaps "as a parameter to the algorithm identifier" captures the intent even better. It would read: 2) Including a random value in the hash function computation. The random block used is transferred as a parameter to the algorithm identifier. This approach is sometimes called a "salted" or "randomized" hash function. Russ At 04:43 AM 6/17/2005, Thomas Roessler wrote: >On 2005-06-16 07:53:27 -0700, Paul Hoffman wrote: > > > >On 2005-06-09 13:02:47 -0700, Paul Hoffman wrote: > > > > > >> 2) Including a random value in the hash function computation. The > > >> random block used is transferred as a parameter in the algorithm > > >> identifier. This approach is sometimes called a "salted" or > > >> "randomized" hash function. > > > >Is this meant to imply an approach where hash identifiers would look > > >like, say, "shaN-0xdeadbeef", 0xdeadbeef being the salt? Or is it > > >merely meant to imply that the seed would be transferred along with > > >the algorithm identifier, somehow? > > > The proposal is a -00 draft, so it has not yet been decided, but it > > is extremely likely to be the latter. IETF protocols don't usually > > carry the names of algorithms, but instead use numeric identifiers > > for them. In the current case, it is likely that the salt would be > > carried as a parameter in an ASN.1 construct, or something similar. > >Thanks for the clarification. > >Maybe you could change "in the algorithm identifier" to "with the >algorithm identifier", to make a little clearer that this >description is not tied to any particular assumption of what an >algorithm identifier looks like? > >Thanks, >-- >Thomas Roessler, W3C _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Fri Jun 17 12:24:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjJdn-0005g0-Jv; Fri, 17 Jun 2005 12:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjJdm-0005fv-4I for hash@megatron.ietf.org; Fri, 17 Jun 2005 12:24:22 -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 MAA01790 for ; Fri, 17 Jun 2005 12:24:19 -0400 (EDT) Received: from mail.rfburst.com ([66.119.143.51]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjK0t-0000F1-IA for hash@ietf.org; Fri, 17 Jun 2005 12:48:16 -0400 Received: from localhost.localdomain (rfb.rfburst.com [66.119.143.249]) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id j5HGNrma023371; Fri, 17 Jun 2005 10:23:53 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id j5HGOpeI017028; Fri, 17 Jun 2005 10:24:51 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id j5HGOplk017024; Fri, 17 Jun 2005 10:24:51 -0600 Date: Fri, 17 Jun 2005 10:24:51 -0600 Message-Id: <200506171624.j5HGOplk017024@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: housley@vigilsec.com In-reply-to: Yourmessage <6.2.1.2.2.20050617114209.0640e0d0@mail.binhost.com> Subject: Re: [Hash] Charter discussion, round 1 X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: hash@ietf.org, w3t-archive@w3.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 "a parameter to the algorithm identifier" is even more confusing. How about "as a field in the algorithm identifier data structure"? If that's not right, then the method of introducing the random value should be left as a mystery for the reader. Hilarie _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Fri Jun 17 12:27:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjJgw-0006V7-VR; Fri, 17 Jun 2005 12:27:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjJgv-0006Uu-3b for hash@megatron.ietf.org; Fri, 17 Jun 2005 12:27: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 MAA02038 for ; Fri, 17 Jun 2005 12:27:32 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DjK40-0000Tv-Hg for hash@ietf.org; Fri, 17 Jun 2005 12:51:29 -0400 Received: (qmail 14214 invoked by uid 0); 17 Jun 2005 16:27:29 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.129.157) by woodstock.binhost.com with SMTP; 17 Jun 2005 16:27:29 -0000 Message-Id: <6.2.1.2.2.20050617122707.049bba10@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 17 Jun 2005 12:27:30 -0400 To: "The Purple Streak, Hilarie Orman" From: Russ Housley Subject: Re: [Hash] Charter discussion, round 1 In-Reply-To: <200506171624.j5HGOplk017024@localhost.localdomain> References: <200506171624.j5HGOplk017024@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: hash@ietf.org, w3t-archive@w3.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 Good suggestion. It now reads: 2) Including a random value in the hash function computation. The random block used is transferred as a field in the algorithm identifier data structure. This approach is sometimes called a "salted" or "randomized" hash function. Russ At 12:24 PM 6/17/2005, The Purple Streak, Hilarie Orman wrote: >"a parameter to the algorithm identifier" is even more confusing. How >about "as a field in the algorithm identifier data structure"? If that's >not right, then the method of introducing the random value should >be left as a mystery for the reader. > >Hilarie _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Fri Jun 17 15:18:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjMMg-0001d2-0A; Fri, 17 Jun 2005 15:18:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjMMe-0001cx-K4 for hash@megatron.ietf.org; Fri, 17 Jun 2005 15:18:52 -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 PAA15509 for ; Fri, 17 Jun 2005 15:18:50 -0400 (EDT) Received: from smtp2.pacifier.net ([64.255.237.172]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjMjj-00046H-Se for hash@ietf.org; Fri, 17 Jun 2005 15:42:48 -0400 Received: from romans (unknown [207.202.179.27]) by smtp2.pacifier.net (Postfix) with ESMTP id 6B39C32735; Fri, 17 Jun 2005 12:18:30 -0700 (PDT) From: "Jim Schaad" To: "'Russ Housley'" Subject: RE: [Hash] Charter discussion, round 1 Date: Fri, 17 Jun 2005 12:20:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <6.2.1.2.2.20050616093927.0660b700@mail.binhost.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVygVtq1+YOdbBsQ1KbO/JpRAwRjQA7e9Sg Message-Id: <20050617191830.6B39C32735@smtp2.pacifier.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit 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 Russ, > > Jim: > > >1. Is this new hash function we are considering in phase 1 > going to be > >the same length as SHA-1 or not? This would appear to be > implied by the goals. > >Would replacement of SHA-1 with SHA-256 intact be considered as > >reasonable in the first phase? > > This has already been discussed. Below I propose some words > in the charter to capture the discussion. Do we have any research available to use about the strengths of truncated hashes? > > >2. Can we do a reasonable job with phase 1 without having > atleast some > >idea of what would be required from phase 2, even if it is > not a full > >set of requirements so that we can evaluate phase 1 againist > some type of critera. > >Do we then want to start phase 2 (even if it is not > completed) right away? > > I do not think so. I think we understand the needs for > signatures, which is the primary issue for phase 1. In my understanding of the world, it is in the case of signatures that the requirements placed on hash functions are the most restrictive. If we understand this set of needs then phase 2 is just a case of identifying the other places where hash functions are used and figuring out which of the signature elements still apply. Other places that hash functions are used (not all cases are applicable to the IETF and list is not complete) - - collision resistance - i.e. building a symbol table based on the hash of a symbol - low level integrity check - assumes the absence of an attacker - keyed hash function authentication > > >3. I think that adding explicit deliverables for phase 2 > could wait, I > >think it must wait until a re-charter for phase 3. > > Are you saying that we can do a good job on Phase 2 even if > the participation from the international crypto community is low? Yes I think so, we are identifying the locations where hash functions are being used or are likely to be used in IETF protocols. We are then specifying what prosperities are needed in these situations. This does not seem to be highly reliant on big research issues. > > >4. If a new hash function is recommended by this group, > will it also > >be responible to deal with any new signature algorithms and so forth > >that come out of this decision? For example, DSA is fixed on using > >SHA-1 and would need changes to adapt to any new hash > algorithm be it a > >trucated or a seeded hash algorithm. > > If you are talking about the assignment of algorithm > identifiers, I am not really concerned about who does it. > > A new hash function should not have deep ripples into the > signature algorithms. It may have an impact on protocols to > carry parameters. If we propose to replace SHA-1 in DSA/ECDSA then there is a big change for those signature algorithms. If we propose to replace SHA-1 for RSA v1.5 - that might be a big change, but I would say we should just jump to RSA-PSS where this is not a big issue. I agree it might have a huge impact on some protocols as well. > > Russ > > = = = = = = > > Here is the proposed rewording of the charter discussion of phase 1: > > The first phase of the working group will specify one or more > standards- track mechanism replace or strengthen SHA-1. Two > classes of signature algorithm need to be considered. In > support of RSA, there is no advantage to reducing the size of > a longer hash function output; the RSA modulus size will > easily accomodate large hash function output values. > However, in support of DSA and ECDSA, the hash function > output size nees to match the subgroup size. > > The irst phase will consider alt least two approches to > strengthen one-way hash functions: > > 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. For example, an alternative to SHA-1, the truncation > mechanism could be used create a 160-bit result from the output > of the SHA-256 one-way hash function. > > 2) Including a random value in the hash function computation. The > random block used is transferred as a parameter in the algorithm > identifier. This approach is sometimes called a "salted" or > "randomized" hash function. > > The first phase may also consider other potential solutions, > and one or more standards-track mechanism will be selected. > > > _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Mon Jun 20 10:18:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkN6C-0006LS-Hx; Mon, 20 Jun 2005 10:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkN68-0006LC-J9 for hash@megatron.ietf.org; Mon, 20 Jun 2005 10:18:02 -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 KAA02914 for ; Mon, 20 Jun 2005 10:17:58 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DkNTm-0002Y3-IO for hash@ietf.org; Mon, 20 Jun 2005 10:42:32 -0400 Received: (qmail 30272 invoked by uid 0); 20 Jun 2005 14:17:32 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.170.162) by woodstock.binhost.com with SMTP; 20 Jun 2005 14:17:32 -0000 Message-Id: <6.2.1.2.2.20050620094732.05d64ba0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 20 Jun 2005 10:04:00 -0400 To: "Jim Schaad" From: Russ Housley Subject: RE: [Hash] Charter discussion, round 1 In-Reply-To: <20050617191830.6B39C32735@smtp2.pacifier.net> References: <6.2.1.2.2.20050616093927.0660b700@mail.binhost.com> <20050617191830.6B39C32735@smtp2.pacifier.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 Jim: > > >1. Is this new hash function we are considering in phase 1 going to be > > >the same length as SHA-1 or not? This would appear to be implied by > the goals. > > >Would replacement of SHA-1 with SHA-256 intact be considered as > > >reasonable in the first phase? > > > > This has already been discussed. Below I propose some words > > in the charter to capture the discussion. > >Do we have any research available to use about the strengths of truncated >hashes? As we have already seen posted here, this is the approach being used in ECDSA. Also, NIST is working on a document in this area. I hope that John Kelsey will finish the document before the -00 cutoff, but that seem unlikely at this point. > > >2. Can we do a reasonable job with phase 1 without having atleast some > > >idea of what would be required from phase 2, even if it is not a full > > >set of requirements so that we can evaluate phase 1 againist some type > of critera. > > >Do we then want to start phase 2 (even if it is not completed) right away? > > > > I do not think so. I think we understand the needs for > > signatures, which is the primary issue for phase 1. > >In my understanding of the world, it is in the case of signatures that the >requirements placed on hash functions are the most restrictive. If we >understand this set of needs then phase 2 is just a case of identifying the >other places where hash functions are used and figuring out which of the >signature elements still apply. > >Other places that hash functions are used (not all cases are applicable to >the IETF and list is not complete) - > - collision resistance - i.e. building a symbol table based on the >hash of a symbol > - low level integrity check - assumes the absence of an attacker > - keyed hash function authentication I do not see any disagreement here ... > > >3. I think that adding explicit deliverables for phase 2 could wait, I > > >think it must wait until a re-charter for phase 3. > > > > Are you saying that we can do a good job on Phase 2 even if > > the participation from the international crypto community is low? > >Yes I think so, we are identifying the locations where hash functions are >being used or are likely to be used in IETF protocols. We are then >specifying what prosperities are needed in these situations. This does not >seem to be highly reliant on big research issues. I would like to see more discussion of this point on this mail list and ant the BoF. You might be able to convince me that we should include Phase 1 and Phase 2 in the first version if the charter. > > >4. If a new hash function is recommended by this group, will it also > > >be responible to deal with any new signature algorithms and so forth > > >that come out of this decision? For example, DSA is fixed on using > > >SHA-1 and would need changes to adapt to any new hash algorithm be it a > > >trucated or a seeded hash algorithm. > > > > If you are talking about the assignment of algorithm > > identifiers, I am not really concerned about who does it. > > > > A new hash function should not have deep ripples into the > > signature algorithms. It may have an impact on protocols to > > carry parameters. > >If we propose to replace SHA-1 in DSA/ECDSA then there is a big change for >those signature algorithms. >If we propose to replace SHA-1 for RSA v1.5 - that might be a big change, >but I would say we should just jump to RSA-PSS where this is not a big >issue. >I agree it might have a huge impact on some protocols as well. I believe that the complexity should be less than adding support for a new hash/signature pair. This should be fairly straightforward if the implementation has any kind of a crypto API. The biggest ripple would seem to be looking into the algorithm identifier parameters. Previously, these were always absent or NULL, so a new bit of code will be needed here. Russ _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Mon Jun 20 19:27:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkVg1-0007OZ-8h; Mon, 20 Jun 2005 19:27:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkVg0-0007OU-IS for hash@megatron.ietf.org; Mon, 20 Jun 2005 19:27:36 -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 TAA20669 for ; Mon, 20 Jun 2005 19:27:33 -0400 (EDT) Received: from mailgw1.technion.ac.il ([132.68.238.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkW3o-0000aM-6R for hash@ietf.org; Mon, 20 Jun 2005 19:52:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw1.technion.ac.il (Postfix) with ESMTP id 5BA40FF8E5 for ; Tue, 21 Jun 2005 02:27:28 +0300 (IDT) Received: from mailgw1.technion.ac.il ([127.0.0.1]) by localhost (mailgw1.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08785-01-91 for ; Tue, 21 Jun 2005 02:27:28 +0300 (IDT) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw1.technion.ac.il (Postfix) with ESMTP id 3C60AFF8D7 for ; Tue, 21 Jun 2005 02:27:28 +0300 (IDT) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id j5KNSV4A008052 for ; Tue, 21 Jun 2005 02:28:31 +0300 (IDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id j5KNSU1G008049 for ; Tue, 21 Jun 2005 02:28:31 +0300 (IDT) Date: Tue, 21 Jun 2005 02:28:30 +0300 (IDT) From: Hugo Krawczyk To: hash@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Hash] randomized hashing I-D 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 People in this list may be interested in the internet-draft http://www.ietf.org/internet-drafts/draft-irtf-cfrg-rhash-00.txt that has been submitted a few weeks ago as a cfrg work item. Hugo _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Tue Jun 21 09:06:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkiSS-00033d-3v; Tue, 21 Jun 2005 09:06:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkcyx-0001HR-OI for hash@megatron.ietf.org; Tue, 21 Jun 2005 03: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 DAA18678 for ; Tue, 21 Jun 2005 03:15:37 -0400 (EDT) Received: from smtp1.pacifier.net ([64.255.237.171]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkdMj-0003oO-0N for hash@ietf.org; Tue, 21 Jun 2005 03:40:19 -0400 Received: from romans (unknown [207.202.179.27]) by smtp1.pacifier.net (Postfix) with ESMTP id 4129874AF2 for ; Tue, 21 Jun 2005 00:15:19 -0700 (PDT) From: "Jim Schaad" To: Date: Tue, 21 Jun 2005 00:17:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcV2MT4RXrcRkWIRTNaRep6KLvNYDw== Message-Id: <20050621071519.4129874AF2@smtp1.pacifier.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Jun 2005 09:06:27 -0400 Cc: Subject: [Hash] UMAC and HMAC X-BeenThere: hash@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jimsch@exmsft.com 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 the process of reviewing some other documents a question has occurred to me. If we are looking at the different places where hash functions are used during phase 2 of the charter work, should we include a section in these documents deal with other methods of acheving these aims? Thus should we, at least in a cursory fashion, deal with items such as HMAC and UMAC for message authentication problems? Jim _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Tue Jun 21 09:17:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkidE-0005Cj-7x; Tue, 21 Jun 2005 09:17:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkidC-0005C6-Qb for hash@megatron.ietf.org; Tue, 21 Jun 2005 09:17:34 -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 JAA16943 for ; Tue, 21 Jun 2005 09:17:33 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dkj16-0004cD-Vn for hash@ietf.org; Tue, 21 Jun 2005 09:42:18 -0400 Received: (qmail 29898 invoked by uid 0); 21 Jun 2005 13:17:26 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.91.211) by woodstock.binhost.com with SMTP; 21 Jun 2005 13:17:26 -0000 Message-Id: <6.2.1.2.2.20050621091559.04d12960@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 21 Jun 2005 09:17:25 -0400 To: jimsch@exmsft.com From: Russ Housley Subject: Re: [Hash] UMAC and HMAC In-Reply-To: <20050621071519.4129874AF2@smtp1.pacifier.net> References: <20050621071519.4129874AF2@smtp1.pacifier.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) 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 Jim: These have very different requirements. My preference is to focus on the one-way hash function for this charter. If your intuition turns out to be correct, then the charter can be expanded. Russ At 03:17 AM 6/21/2005, Jim Schaad wrote: >In the process of reviewing some other documents a question has occurred to >me. If we are looking at the different places where hash functions are used >during phase 2 of the charter work, should we include a section in these >documents deal with other methods of acheving these aims? Thus should we, >at least in a cursory fashion, deal with items such as HMAC and UMAC for >message authentication problems? > >Jim _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Tue Jun 21 20:03:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dksi5-0006ND-Uz; Tue, 21 Jun 2005 20:03:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dksi4-0006N7-Hc for hash@megatron.ietf.org; Tue, 21 Jun 2005 20:03:16 -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 UAA28979 for ; Tue, 21 Jun 2005 20:03:15 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkt64-0003WN-KD for hash@ietf.org; Tue, 21 Jun 2005 20:28:05 -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 j5M0388K098218 for ; Tue, 21 Jun 2005 17:03:09 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F042741AD@sottmxs05.entrust.com> References: <7A3E1242FA9989439AD1F9B2D71C287F042741AD@sottmxs05.entrust.com> Date: Tue, 21 Jun 2005 17:03:15 -0700 To: hash@ietf.org From: Paul Hoffman Subject: RE: [Hash] Charter discussion, round 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 At 3:59 PM -0400 6/16/05, Robert Zuccherato wrote: >If a similar approach was taken with DSA (which would have to be >changed anyway to use anything other than SHA-1) then much of the >justification for the definition of a truncated hash function would >disappear. Do we have any information on whether or not the same truncation approach is being taken on DSA as ECDSA? That would have a fairly significant affect on our charter items. If it isn't being taken, finding out why would also be helpful. --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 Jun 21 20: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 1Dksu4-0003D2-Cw; Tue, 21 Jun 2005 20: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 1Dksu2-0003A6-13 for hash@megatron.ietf.org; Tue, 21 Jun 2005 20:15:38 -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 UAA29866 for ; Tue, 21 Jun 2005 20:15:36 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DktI3-0003pL-7O for hash@ietf.org; Tue, 21 Jun 2005 20:40:27 -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 j5M0FRKT010505; Tue, 21 Jun 2005 17:15:30 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.1.2.2.20050620094732.05d64ba0@mail.binhost.com> <20050617191830.6B39C32735@smtp2.pacifier.net> References: <6.2.1.2.2.20050616093927.0660b700@mail.binhost.com> <20050617191830.6B39C32735@smtp2.pacifier.net> <6.2.1.2.2.20050620094732.05d64ba0@mail.binhost.com> <20050617191830.6B39C32735@smtp2.pacifier.net> Date: Tue, 21 Jun 2005 17:15:33 -0700 To: "Jim Schaad" , "'Russ Housley'" From: Paul Hoffman Subject: RE: [Hash] Charter discussion, round 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 12:20 PM -0700 6/17/05, Jim Schaad wrote: > > >3. I think that adding explicit deliverables for phase 2 >> could wait, I >> >think it must wait until a re-charter for phase 3. >> >> Are you saying that we can do a good job on Phase 2 even if >> the participation from the international crypto community is low? > >Yes I think so, we are identifying the locations where hash functions are >being used or are likely to be used in IETF protocols. We are then >specifying what prosperities are needed in these situations. This does not >seem to be highly reliant on big research issues. At 10:04 AM -0400 6/20/05, Russ Housley wrote: >I would like to see more discussion of this point on this mail list >and ant the BoF. You might be able to convince me that we should >include Phase 1 and Phase 2 in the first version if the charter. Remember that this effort is intended to be done in an IETF Working Group, and WGs are inherently open to all participants. If we begin the work or deciding the criteria that make a good hash without the experts from the international crypto community who understand those criteria being on-board, the WG will probably tend towards non-experts quoting (and misquoting) what they read in the trade press. There is the additional factor that we are just finding out some important things about hashes, and have heard very few analyses of that new information. Do the discoveries by Wang et. al. only apply to collisions? If we wait a year or two, will the crypto community be able to extend those into measurable preimage attacks? If so, what will we know then? I'm not saying we need to wait on chartering phase 2, but we should certainly not try to rush this based on our limited information. --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 Jun 23 15:09:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlX5C-0005Sp-To; Thu, 23 Jun 2005 15:09:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlX5B-0005Sk-EQ for hash@megatron.ietf.org; Thu, 23 Jun 2005 15:09:49 -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 PAA17324 for ; Thu, 23 Jun 2005 15:09:48 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlXTZ-0004XT-8R for hash@ietf.org; Thu, 23 Jun 2005 15:35:01 -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 j5NJ9fct049659 for ; Thu, 23 Jun 2005 12:09:42 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 23 Jun 2005 12:09:38 -0700 To: hash@ietf.org From: Paul Hoffman 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 j5NJ9fct049659 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hash] Fwd: Reminder - Submission Deadline for the Cryptographic Hash Workshop Approaching (7/15/2005) 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 >X-Sender: sjchang@email.nist.gov >X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 >Date: Thu, 23 Jun 2005 14:17:32 -0400 >To: shu-jen.chang@nist.gov >From: Shu-jen Chang >Subject: Reminder - Submission Deadline for the Cryptographic Hash > Workshop Approaching (7/15/2005) >X-NIST-MailScanner: Found to be clean >X-NIST-MailScanner-From: shu-jen.chang@nist.gov > >This is just a reminder that submissions for the Cryptographic Hash=20 >Workshop are due on 7/15/2005. Details about the Workshop are=20 >available at: http://www.nist.gov/hash-function > >Attached below is the original announcement that I sent out in=20 >April. Thanks for your attention. > >Shu-jen Chang >Computer Security Division >NIST > >------------------------------------------------------------------------= ----------------- >Cryptographic Hash Workshop >NIST Gaithersburg, MD (Green Auditorium) >Oct. 31-Nov. 1, 2005 >Submission Deadline: July 15, 2005 (Workshop without Proceedings) > >Recently a team of researchers reported that the SHA-1 function=20 >offers significantly less collision resistance than could be=20 >expected from a cryptographic hash function of its output size.=20 >NIST plans to host a Cryptographic Hash Workshop on Oct. 31-Nov. 1,=20 >2005 to solicit public input in how best to respond to the current=20 >state of research in this area. The workshop has the following=20 >goals: > >=B7 Assess the status of the current NIST-approved hash=20 >functions, i.e., the SHA-256 and SHA-512 families in addition to=20 >SHA-1; >=B7 Discuss short term actions to mitigate the potential problems=20 >with the various applications of the approved hash functions; >=B7 Discuss the conditions that would warrant an early transition=20 >away from any of the approved hash functions; >=B7 Discuss the potential replacement options for any of the=20 >approved hash functions; >=B7 Clarify the properties of unkeyed cryptographic hash=20 >functions required for different applications such as digital=20 >signatures, key derivation, message authentication, and random=20 >number generation. > >NIST solicits papers, presentations, case studies, panel proposals,=20 >and participation from any interested parties, including=20 >researchers, systems architects, vendors, and users. NIST will post=20 >the accepted papers and presentations on the workshop web site and=20 >include these in a workshop handout. However, no formal workshop=20 >proceedings will be published. NIST encourages presentations and=20 >reports on preliminary work that participants plan to publish=20 >elsewhere. Topics for submissions are included in the attached=20 >document, and details about the workshop will be available at the=20 >following web site shortly: http://www.nist.gov/hash-function > > >Shu-jen Chang >Computer Security Division >NIST --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 Sun Jun 26 12:16:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZnh-00014A-6s; Sun, 26 Jun 2005 12:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZnf-00013b-EC for hash@megatron.ietf.org; Sun, 26 Jun 2005 12:16:03 -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 MAA15928 for ; Sun, 26 Jun 2005 12:16:00 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmaCd-00041G-P7 for hash@ietf.org; Sun, 26 Jun 2005 12:41:52 -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 j5QGFu8I019084 for ; Sun, 26 Jun 2005 09:15:57 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 26 Jun 2005 09:15:43 -0700 To: Hash BOF From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Subject: [Hash] Charter discussion, round 2 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 Greetings again. Thank you to everyone who helped with the first round. My take is that people don't see much need to segregate the truncation/salting discussion from the meatier requirements discussion. Also, looking at the mailing list, we are already seeing a reasonable level of subscription from some well-known names in the cryptography community. Given that, I would like to propose a similar-but-different charter that gets us started on the more significant issues earlier. Please comment on the list whether you think the text is or is not reasonable, the goals are or are not achievable, and the timeline is or is not sensible. --Paul Hoffman, Director --VPN Consortium One-way Hash Function BoF (hash) Security Area Director: Sam Hartman Russ Housley Security Area Advisor: Russ Housley Mailing Lists: General Discussion: hash@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/hash Archive: http://www.ietf.org/mail-archive/web/hash/index.html Description of Proposed Working Group: Recently, a team of researchers reported that the SHA-1 one-way hash function offers significantly less collision resistance than could be expected from a cryptographic hash function with an output of 160 bits. This result has inspired significant research activities in government and academia. Additional information regarding the security of current one-way hash functions, as well as proposals for new one-way hash functions, are expected. The proposed working group responds to the current state of research in this area. However, additional research is likely to provide new insights as the working group progresses. A two-phase approach is envisioned. The second phase will be pursued by revising the charter, only after the first phase is finished and if it is clear that the international cryptographic community is actively participating in the working group. The first phase will consist of two main areas of work: setting requirements for the use of one-way hash functions in IETF protocols, and describing ways to make current hash functions more robust. These two work items can be done in parallel. 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 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 block used is transferred as a field in the algorithm identifier data structure. 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. 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. Goals and Milestones: August 2005: Charter working group to authorize first phase. September 2005: Submit initial draft of truncation mechanism and/or salting mechanism. November 2005: Submit initial drafts on hash requirements, descriptions, and suitability. February 2006: WG Last Call on truncation mechanism and/or salting mechanism. March 2006: Submit truncation mechanism and/or salting mechanism for IETF standard. August 2006: Begin WG Last Calls on hash requirements, descriptions, and suitability. June 2007: Submit hash requirements, descriptions, and suitability documents for BCP. June 2007: Recharter working group to authorize second phase. _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Mon Jun 27 08:01:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmsJ6-00010a-Dg; Mon, 27 Jun 2005 08:01:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmsJ5-00010O-Bd for hash@megatron.ietf.org; Mon, 27 Jun 2005 08:01:43 -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 IAA11500 for ; Mon, 27 Jun 2005 08:01:42 -0400 (EDT) Received: from mail.links.org ([217.155.92.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmsiD-0005mc-Bh for hash@ietf.org; Mon, 27 Jun 2005 08:27:42 -0400 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2E1AB33C1A; Mon, 27 Jun 2005 13:01:39 +0100 (BST) Message-ID: <42BFEA9E.6080603@algroup.co.uk> Date: Mon, 27 Jun 2005 13:01:34 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ Housley Subject: Re: [Hash] Charter discussion, round 1 References: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> <20050616081143.GC32581@raktajino.does-not-exist.org> <20050617084345.GJ32581@raktajino.does-not-exist.org> <6.2.1.2.2.20050617114209.0640e0d0@mail.binhost.com> In-Reply-To: <6.2.1.2.2.20050617114209.0640e0d0@mail.binhost.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: w3t-archive@w3.org, 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 Russ Housley wrote: > Perhaps "as a parameter to the algorithm identifier" captures the intent > even better. It would read: > > 2) Including a random value in the hash function computation. The > random block used is transferred as a parameter to the algorithm > identifier. This approach is sometimes called a "salted" or > "randomized" hash function. It strikes me as weird, describing it as a parameter to the algorithm identifier - firstly, it seems this wording is derived from where you want to fit it into ASN.1, and secondly, why constrain it in this way? A protocol could easily transfer the random value somewhere other than in the algorithm identification. Indeed, if the protocol doesn't use algorithm identifiers every time it uses a hash (TLS would be an example of this, surely?), you'd be utterly screwed by this wording. Cheers, Ben. -- >>>ApacheCon Europe<<< http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Mon Jun 27 14:42:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmyZK-0001Hw-L3; Mon, 27 Jun 2005 14:42:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmyZJ-0001Hm-IP for hash@megatron.ietf.org; Mon, 27 Jun 2005 14:42: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 OAA23009 for ; Mon, 27 Jun 2005 14:42:51 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DmyyT-0002mv-2A for hash@ietf.org; Mon, 27 Jun 2005 15:08:56 -0400 Received: (qmail 4412 invoked by uid 0); 27 Jun 2005 18:41:41 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.44.179) by woodstock.binhost.com with SMTP; 27 Jun 2005 18:41:41 -0000 Message-Id: <6.2.1.2.2.20050627143944.058e7560@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 27 Jun 2005 14:41:38 -0400 To: Ben Laurie From: Russ Housley Subject: Re: [Hash] Charter discussion, round 1 In-Reply-To: <42BFEA9E.6080603@algroup.co.uk> References: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> <20050616081143.GC32581@raktajino.does-not-exist.org> <20050617084345.GJ32581@raktajino.does-not-exist.org> <6.2.1.2.2.20050617114209.0640e0d0@mail.binhost.com> <42BFEA9E.6080603@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Ben: Good point. The words should say that three things need to be transferred (either implicitly or explicitly). They are the data to be hashed, the hash algorithm, and the random value. Where in the protocol that these values appear is not important to the algorithm development. Russ At 08:01 AM 6/27/2005, Ben Laurie wrote: >Russ Housley wrote: >>Perhaps "as a parameter to the algorithm identifier" captures the intent >>even better. It would read: >> 2) Including a random value in the hash function computation. The >> random block used is transferred as a parameter to the algorithm >> identifier. This approach is sometimes called a "salted" or >> "randomized" hash function. > >It strikes me as weird, describing it as a parameter to the algorithm >identifier - firstly, it seems this wording is derived from where you want >to fit it into ASN.1, and secondly, why constrain it in this way? A >protocol could easily transfer the random value somewhere other than in >the algorithm identification. > >Indeed, if the protocol doesn't use algorithm identifiers every time it >uses a hash (TLS would be an example of this, surely?), you'd be utterly >screwed by this wording. > >Cheers, > >Ben. > >-- > >>>ApacheCon Europe<<< http://www.apachecon.com/ > >http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > >"There is no limit to what a man can do or how far he can go if he >doesn't mind who gets the credit." - Robert Woodruff > _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Tue Jun 28 11:32:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnI4Q-0001NM-1j; Tue, 28 Jun 2005 11:32:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnI4N-0001NB-Jt for hash@megatron.ietf.org; Tue, 28 Jun 2005 11:32:15 -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 LAA19811 for ; Tue, 28 Jun 2005 11:32:13 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnITj-0007MS-Pe for hash@ietf.org; Tue, 28 Jun 2005 11:58:29 -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 j5SFW2eM097678; Tue, 28 Jun 2005 08:32:03 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <42BFEA9E.6080603@algroup.co.uk> References: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> <20050616081143.GC32581@raktajino.does-not-exist.org> <20050617084345.GJ32581@raktajino.does-not-exist.org> <6.2.1.2.2.20050617114209.0640e0d0@mail.binhost.com> <42BFEA9E.6080603@algroup.co.uk> Date: Tue, 28 Jun 2005 08:31:58 -0700 To: Ben Laurie , Russ Housley From: Paul Hoffman Subject: Re: [Hash] Charter discussion, round 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: w3t-archive@w3.org, 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 1:01 PM +0100 6/27/05, Ben Laurie wrote: >Russ Housley wrote: >>Perhaps "as a parameter to the algorithm identifier" captures the >>intent even better. It would read: >> >> 2) Including a random value in the hash function computation. The >> random block used is transferred as a parameter to the algorithm >> identifier. This approach is sometimes called a "salted" or >> "randomized" hash function. > >It strikes me as weird, describing it as a parameter to the >algorithm identifier - firstly, it seems this wording is derived >from where you want to fit it into ASN.1 ... and PGP and IKE and other protocols that have parameters for crypto functions. >, and secondly, why constrain it in this way? A protocol could >easily transfer the random value somewhere other than in the >algorithm identification. You may be right, but I'm not convinced about "easily". Do you have different wording that would help, for example, TLS use these kinds of functions if we define them? --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 Jun 28 11:54:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnIPm-0007Zn-B4; Tue, 28 Jun 2005 11:54:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnIPk-0007Zi-NN for hash@megatron.ietf.org; Tue, 28 Jun 2005 11:54:20 -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 LAA22763 for ; Tue, 28 Jun 2005 11:54:18 -0400 (EDT) Received: from mail.links.org ([217.155.92.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnIp5-0008W7-CV for hash@ietf.org; Tue, 28 Jun 2005 12:20:34 -0400 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 7B2D533C1A; Tue, 28 Jun 2005 16:54:19 +0100 (BST) Message-ID: <42C172A7.8080807@algroup.co.uk> Date: Tue, 28 Jun 2005 16:54:15 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [Hash] Charter discussion, round 1 References: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> <20050616081143.GC32581@raktajino.does-not-exist.org> <20050617084345.GJ32581@raktajino.does-not-exist.org> <6.2.1.2.2.20050617114209.0640e0d0@mail.binhost.com> <42BFEA9E.6080603@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: w3t-archive@w3.org, 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 Hoffman wrote: > At 1:01 PM +0100 6/27/05, Ben Laurie wrote: > >> Russ Housley wrote: >> >>> Perhaps "as a parameter to the algorithm identifier" captures the >>> intent even better. It would read: >>> >>> 2) Including a random value in the hash function computation. The >>> random block used is transferred as a parameter to the algorithm >>> identifier. This approach is sometimes called a "salted" or >>> "randomized" hash function. >> >> >> It strikes me as weird, describing it as a parameter to the algorithm >> identifier - firstly, it seems this wording is derived from where you >> want to fit it into ASN.1 > > > ... and PGP and IKE and other protocols that have parameters for crypto > functions. I've managed to avoid IKE (so far) but PGP doesn't have parameters for crypto functions. >> , and secondly, why constrain it in this way? A protocol could easily >> transfer the random value somewhere other than in the algorithm >> identification. > > You may be right, but I'm not convinced about "easily". I'm pretty sure its easy. What isn't so easy is changing all the applications to understand the modified protocol. > Do you have different wording that would help, for example, TLS use > these kinds of functions if we define them? 'Including a random value in the hash function computation. The random block 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.' And now I'm thinking harder about this, we also should say that care needs to be taken that the right party chooses the random value (or it may be that both (all?) parties should choose it in some cases) - since allowing the attacker to choose it would be bad. Cheers, Ben. -- >>>ApacheCon Europe<<< http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Tue Jun 28 12:21:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnIpp-00087O-PP; Tue, 28 Jun 2005 12:21:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnIpp-000872-6M for hash@megatron.ietf.org; Tue, 28 Jun 2005 12:21:17 -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 MAA28360 for ; Tue, 28 Jun 2005 12:21:14 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnJFB-0001Ad-1D for hash@ietf.org; Tue, 28 Jun 2005 12:47:31 -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 j5SGL2J1040667; Tue, 28 Jun 2005 09:21:03 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <42C172A7.8080807@algroup.co.uk> References: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> <20050616081143.GC32581@raktajino.does-not-exist.org> <20050617084345.GJ32581@raktajino.does-not-exist.org> <6.2.1.2.2.20050617114209.0640e0d0@mail.binhost.com> <42BFEA9E.6080603@algroup.co.uk> <42C172A7.8080807@algroup.co.uk> Date: Tue, 28 Jun 2005 09:20:37 -0700 To: Ben Laurie From: Paul Hoffman Subject: Re: [Hash] Charter discussion, round 1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: w3t-archive@w3.org, 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 4:54 PM +0100 6/28/05, Ben Laurie wrote: >I've managed to avoid IKE (so far) Probably wise, or at least sanity-saving. > but PGP doesn't have parameters for crypto functions. Ah. I now see that. There are parameters, but they're baked into the packet format. >>>, and secondly, why constrain it in this way? A protocol could >>>easily transfer the random value somewhere other than in the >>>algorithm identification. >> >>You may be right, but I'm not convinced about "easily". > >I'm pretty sure its easy. What isn't so easy is changing all the >applications to understand the modified protocol. Of course. >>Do you have different wording that would help, for example, TLS use >>these kinds of functions if we define them? > >'Including a random value in the hash function computation. The >random block 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.' I prefer "value" to "block" in the second sentence, but the rest seems fine to me. Do others have an opinion on this wording? >And now I'm thinking harder about this, we also should say that care >needs to be taken that the right party chooses the random value (or >it may be that both (all?) parties should choose it in some cases) - >since allowing the attacker to choose it would be bad. The whole purpose here is to allow the signing party to add randomness to the message they are signing. If the attacker is signing, don't they already have all the control they need for the collision attacks? --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 Jun 28 12:34:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnJ2F-00037F-OI; Tue, 28 Jun 2005 12:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnJ2F-000375-1N for hash@megatron.ietf.org; Tue, 28 Jun 2005 12:34:07 -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 MAA29305 for ; Tue, 28 Jun 2005 12:34:03 -0400 (EDT) Received: from mail.links.org ([217.155.92.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnJRb-0001W2-Fb for hash@ietf.org; Tue, 28 Jun 2005 13:00:20 -0400 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id D920733C1B; Tue, 28 Jun 2005 17:34:09 +0100 (BST) Message-ID: <42C17BFD.1000402@algroup.co.uk> Date: Tue, 28 Jun 2005 17:34:05 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [Hash] Charter discussion, round 1 References: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> <20050616081143.GC32581@raktajino.does-not-exist.org> <20050617084345.GJ32581@raktajino.does-not-exist.org> <6.2.1.2.2.20050617114209.0640e0d0@mail.binhost.com> <42BFEA9E.6080603@algroup.co.uk> <42C172A7.8080807@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: w3t-archive@w3.org, 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 Hoffman wrote: > At 4:54 PM +0100 6/28/05, Ben Laurie wrote: >>> Do you have different wording that would help, for example, TLS use >>> these kinds of functions if we define them? >> >> 'Including a random value in the hash function computation. The >> random block 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.' > > I prefer "value" to "block" in the second sentence, but the rest seems > fine to me. Fair enough - I took that word from the existing wording. > Do others have an opinion on this wording? > >> And now I'm thinking harder about this, we also should say that care >> needs to be taken that the right party chooses the random value (or it >> may be that both (all?) parties should choose it in some cases) - >> since allowing the attacker to choose it would be bad. > > The whole purpose here is to allow the signing party to add randomness > to the message they are signing. It is? Isn't the purpose to try to mitigate _all_ the problems caused by weak hashes? > If the attacker is signing, don't they > already have all the control they need for the collision attacks? Not if the relying party chooses the random value. -- >>>ApacheCon Europe<<< http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash From hash-bounces@lists.ietf.org Tue Jun 28 12:35:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnJ3l-0003NR-Fq; Tue, 28 Jun 2005 12:35:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnJ3k-0003NL-0C for hash@megatron.ietf.org; Tue, 28 Jun 2005 12:35:40 -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 MAA29399 for ; Tue, 28 Jun 2005 12:35:37 -0400 (EDT) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnJT7-0001Yg-1G for hash@ietf.org; Tue, 28 Jun 2005 13:01:54 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 77DF08A02D; Tue, 28 Jun 2005 09:41:57 -0700 (PDT) To: Paul Hoffman Subject: Re: [Hash] Charter discussion, round 1 In-reply-to: Your message of "Tue, 28 Jun 2005 08:31:58 PDT." X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Tue, 28 Jun 2005 09:35:21 -0700 From: Eric Rescorla Message-Id: <20050628164157.77DF08A02D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: hash@ietf.org, w3t-archive@w3.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 Hoffman wrote: > At 1:01 PM +0100 6/27/05, Ben Laurie wrote: > >Russ Housley wrote: > >> Perhaps "as a parameter to the algorithm identifier" captures the > >> intent even better. It would read: > >> > >> 2) Including a random value in the hash function computation. The > >> random block used is transferred as a parameter to the algorithm > >> identifier. This approach is sometimes called a "salted" or > >> "randomized" hash function. > > > > It strikes me as weird, describing it as a parameter to the > > algorithm identifier - firstly, it seems this wording is derived > > from where you want to fit it into ASN.1 > > ... and PGP and IKE and other protocols that have parameters for > crypto functions. > > > , and secondly, why constrain it in this way? A protocol could > > easily transfer the random value somewhere other than in the > > algorithm identification. > > You may be right, but I'm not convinced about "easily". > > Do you have different wording that would help, for example, TLS use > these kinds of functions if we define them? TLS probably doesn't need them. Digital signatures in TLS are over jointly randomly generated values and not for non-repudation purposes. -Ekr _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash