Re: [Hash] Charter discussion, round 1

Ben Laurie <ben@algroup.co.uk> Tue, 28 June 2005 15:54 UTC

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 <hash@ietf.org>; 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 <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [Hash] Charter discussion, round 1
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> <p06230977bee71c108c83@[10.20.30.249]>
In-Reply-To: <p06230977bee71c108c83@[10.20.30.249]>
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: <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

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