[Cfrg] Fwd: Hash-Based Key Derivation (fwd)
David Wagner <daw@cs.berkeley.edu> Sat, 29 October 2005 18:50 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 1EVvmZ-0008BD-1V; Sat, 29 Oct 2005 14:50:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVvmW-00088Z-Q5 for cfrg@megatron.ietf.org; Sat, 29 Oct 2005 14:50: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 OAA17506 for <cfrg@ietf.org>; Sat, 29 Oct 2005 14:50:02 -0400 (EDT)
Received: from taverner.cs.berkeley.edu ([128.32.168.222]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVw0K-0003T8-Rw for cfrg@ietf.org; Sat, 29 Oct 2005 15:04:38 -0400
Received: from taverner.CS.Berkeley.EDU (localhost.localdomain [127.0.0.1]) by taverner.CS.Berkeley.EDU (8.13.1/8.13.1) with ESMTP id j9TIo7SW010086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Oct 2005 11:50:07 -0700
Received: (from daw@localhost) by taverner.CS.Berkeley.EDU (8.13.1/8.13.1/Submit) id j9TIo74O010082; Sat, 29 Oct 2005 11:50:07 -0700
From: David Wagner <daw@cs.berkeley.edu>
Message-Id: <200510291850.j9TIo74O010082@taverner.CS.Berkeley.EDU>
Subject: [Cfrg] Fwd: Hash-Based Key Derivation (fwd)
To: cfrg@ietf.org
Date: Sat, 29 Oct 2005 11:50:07 -0700
Secret-Bounce-Tag: 9a029cbee41caf2ca77a77efa3c13981
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: 7bit
X-BeenThere: cfrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: David Wagner <daw-usenet@taverner.CS.Berkeley.EDU>
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
It may be hard for people to remember the thread context. We've had a long chain of responses (some of which seemed to have missed the point that I was trying to make). Therefore, I want to refresh everyone's memory. You may recall that Dan Bernstein wrote: How do we build PRFs? By hashing the key and the input. In response, I wrote: That's one possibility, although I'm starting to become inclined to limit our reliance on hash functions as much as necessary, after all these attacks on many of our hash functions. Another possibility -- which I would have more confidence in at the moment -- is to use a block cipher based PRF such as AES-OMAC. Let me stress that Bernstein asked about a PRF (a pseudorandom functions), not, e.g., key extraction from a biased source. My response was that, if you want a PRF, Bernstein's scheme is a poor choice. It is better to use a construction like AES-OMAC than to use what Bernstein proposed. Bernstein seems to be suggesting SHA256(K||X). That is a poor choice of PRF. It is not secure against truncation attacks. And even if we assume that X is of fixed length, it is a poor choice of a construction, because it makes very strong assumptions about the properties of the hash. (It is secure in the random oracle model, but the RO model makes very strong "assumptions" about the hash.) As Hugo Krawczyk says, if you want to use a hash-based PRF, SHA256-HMAC(K,X) is better. It makes more realistic assumptions about the hash function, and it doesn't need the RO model. But I was saying that better still would be to use a block-cipher based PRF, such as AES-OMAC(K,X). AES-OMAC assumes only that AES is a PRP (pseudorandom permutation). This is a standard and commonly accepted notion of security for a block cipher. It is in some sense the weakest interesting concept of what it means for a block cipher to be secure. Weaker assumptions are better, because it means that AES-OMAC is less likely to disappoint. What also seems relevant is that the recent results on hash functions cast doubt in my mind on the security of hashing when used for, say, pseudorandom functions. Hash functions weren't (primarily) designed for that kind of purpose. In comparison, this is exactly what block ciphers were designed for. Therefore, if you want a PRF, my suggestion is that something like AES-OMAC may be one of the most conservative choices out there. Now, let's come to the responses that we have heard from Dan Bernstein and others. They missed the above point. They went on tangents. Bernstein claimed that some construction using AES + Luby-Rackoff + Miyaguchi-Preneel leads to a hash scheme that is ``exactly the same'' as AES-OMAC. I believe that claim to be inaccurate. I have been trying to pin Bernstein down on exactly what he means and why things it would be the case. I have been failing. I apologize for dragging you through all this background. My only excuse is that it is not my fault: it looks to me like Bernstein has made two claims that are unjustified, but trying to get this point across has led to a long chain of responses that make it hard to remember the context and the background. With that background, let's come to your email: John Wilkinson writes: >I suspect that Dr. Bernstein's will claim that the following two >KDF's are equivalent, from a provable security perspective: > >KDF1: Ki = CMAC-AES256(SHA256(x),i), where x is the shared secret, >SHA256(x) is used as the key to CMAC, and i is a counter used as the >message input to CMAC. > >KDF2: Ki = SHA256(i,x), where i is a counter, x is the shared secret, >and (i,x) represents the concatenation of i and x. Well, I don't know what he will claim in the future, but that's not what he was claiming before. His claims before were not about KDFs intended for use with biased sources of shared secrets (e.g., Diffie-Hellman shared secrets); they were about PRFs. Under the standard meaning of the term, a PRF is only required to be secure when the key is chosen uniformly at random. So I don't think your KDF schemes are relevant to the objections I have raised to Bernstein's comments. _______________________________________________ Cfrg mailing list Cfrg@ietf.org https://www1.ietf.org/mailman/listinfo/cfrg
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- [Cfrg] Fwd: Hash-Based Key Derivation David McGrew
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Scott Fluhrer
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Simon Blake-Wilson
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Tom Shrimpton
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Simon Blake-Wilson
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Blumenthal, Uri
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Simon Blake-Wilson
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Simon Blake-Wilson
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Scott Fluhrer
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Blumenthal, Uri
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Tom Shrimpton
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Simon Blake-Wilson
- Re: [Cfrg] Fwd: Hash-Based Key Derivation Daniel Brown
- Re: [Cfrg] Fwd: Hash-Based Key Derivation Paul Hoffman
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Tom Shrimpton
- RE: [Cfrg] Fwd: Hash-Based Key Derivation Simon Blake-Wilson
- Re: [Cfrg] Fwd: Hash-Based Key Derivation D. J. Bernstein
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- Re: [Cfrg] Fwd: Hash-Based Key Derivation Jack Lloyd
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- KDF definition and goal [was: [Cfrg] Fwd: Hash-Ba… David McGrew
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- Re: [Cfrg] Fwd: Hash-Based Key Derivation Daniel Brown
- Re: [Cfrg] Fwd: Hash-Based Key Derivation Jack Lloyd
- Re: KDF definition and goal [was: [Cfrg] Fwd: Has… David McGrew
- Re: [Cfrg] Fwd: Hash-Based Key Derivation Daniel Brown
- Re: [Cfrg] Fwd: Hash-Based Key Derivation Daniel Brown
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- [Cfrg] Fwd: Hash-Based Key Derivation David Wagner
- Re: [Cfrg] Fwd: Hash-Based Key Derivation Daniel Brown
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) Hugo Krawczyk
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) Daniel Brown
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) D. J. Bernstein
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) Hugo Krawczyk
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) Hugo Krawczyk
- [Cfrg] Fwd: Hash-Based Key Derivation (fwd) David Wagner
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) Hugo Krawczyk
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) D. J. Bernstein
- [Cfrg] Fwd: Hash-Based Key Derivation (fwd) David Wagner
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) D. J. Bernstein
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) John Wilkinson
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) Jack Lloyd
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) John Wilkinson
- [Cfrg] Fwd: Hash-Based Key Derivation (fwd) David Wagner
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) John Wilkinson
- [Cfrg] Fwd: Hash-Based Key Derivation (fwd) David Wagner
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) John Wilkinson
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) D. J. Bernstein
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) D. J. Bernstein
- [Cfrg] Fwd: Hash-Based Key Derivation (fwd) David Wagner
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) John Wilkinson
- Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd) D. J. Bernstein