Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd)

"D. J. Bernstein" <djb@cr.yp.to> Mon, 31 October 2005 06:07 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWSpK-00087y-DG; Mon, 31 Oct 2005 01:07:26 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWSpG-00087L-Sv for cfrg@megatron.ietf.org; Mon, 31 Oct 2005 01:07:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13677 for <cfrg@ietf.org>; Mon, 31 Oct 2005 01:07:04 -0500 (EST)
Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWT3N-0000NG-Sd for cfrg@ietf.org; Mon, 31 Oct 2005 01:21:59 -0500
Received: (qmail 51688 invoked by uid 1016); 31 Oct 2005 06:07:43 -0000
Date: Mon, 31 Oct 2005 06:07:43 -0000
Message-ID: <20051031060743.51687.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@ietf.org
Subject: Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd)
References: <200510300542.j9U5gbRn023523@taverner.CS.Berkeley.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
X-BeenThere: cfrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=subscribe>
Sender: cfrg-bounces@ietf.org
Errors-To: cfrg-bounces@ietf.org

David Wagner writes:
> *the attacker has limited (or no) control over the input to the hash*

I disagree. It is highly dangerous to model Diffie-Hellman shared
secrets g^xy as uniform random group elements. For example, the attacker
can feed the geometric progression g^xy g^x, g^xy g^2x, ... to the hash.
Sure, this is more complicated than an arithmetic progression 0,1,2,...,
but describing it as ``limited (or no) control'' is unreasonable.

> H(i || SV || ...) puts more stress on
> the hash than PRF(H(SV), i || ...) does.  

I disagree. This ``stress'' hasn't even succeeded in breaking wimpy
MD5-based constructions from a decade ago. The ``many simple rounds''
philosophy for building unbroken secret-key ciphers, and for trying to
build collision-resistant hash functions, has been 100% successful at
building unbroken key-derivation functions.

There don't seem to be speed pressures telling us to reduce the number
of rounds in a key-derivation function; there aren't security pressures
telling us to increase the number of rounds; there _are_ code-size
pressures telling us to reuse existing cryptographic components in the
simplest possible way.

---D. J. Bernstein, Professor, Mathematics, Statistics,
and Computer Science, University of Illinois at Chicago

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg