Re: [Hash] Charter discussion, round 1

Russ Housley <housley@vigilsec.com> Mon, 27 June 2005 18:42 UTC

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 <hash@ietf.org>; 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 <ben@algroup.co.uk>
From: Russ Housley <housley@vigilsec.com>
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> <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>
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: <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

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