Re: [Hash] Charter discussion, round 1

Ben Laurie <ben@algroup.co.uk> Mon, 27 June 2005 12:01 UTC

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 <hash@ietf.org>; 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 <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Russ Housley <housley@vigilsec.com>
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>
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: <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

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