Re: [Hash] Charter discussion, round 1

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 28 June 2005 15:32 UTC

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 <hash@ietf.org>; 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: <p06230977bee71c108c83@[10.20.30.249]>
In-Reply-To: <42BFEA9E.6080603@algroup.co.uk>
References: <6.2.1.2.2.20050609152413.078e8ac0@mail.binhost.com> <p06210245bece4ebbbea1@[10.20.30.249]> <20050616081143.GC32581@raktajino.does-not-exist.org> <p0621023abed742623640@[10.20.30.249]> <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 <ben@algroup.co.uk>, Russ Housley <housley@vigilsec.com>
From: Paul Hoffman <paul.hoffman@vpnc.org>
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: <https://www1.ietf.org/mailman/listinfo/hash>, <mailto:hash-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/hash>
List-Post: <mailto:hash@lists.ietf.org>
List-Help: <mailto:hash-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hash>, <mailto:hash-request@lists.ietf.org?subject=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