[Cfrg] Fwd: Hash-Based Key Derivation

David Wagner <daw@cs.berkeley.edu> Tue, 25 October 2005 20:32 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVSp-0005Dr-2D; Tue, 25 Oct 2005 16:32:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUVSn-0005DP-Ae for cfrg@megatron.ietf.org; Tue, 25 Oct 2005 16:32:05 -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 QAA00538 for <cfrg@ietf.org>; Tue, 25 Oct 2005 16:31:49 -0400 (EDT)
Received: from taverner.cs.berkeley.edu ([128.32.168.222]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUVfm-00054M-HX for cfrg@ietf.org; Tue, 25 Oct 2005 16:45:32 -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 j9PKVqe5019729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Oct 2005 13:31:52 -0700
Received: (from daw@localhost) by taverner.CS.Berkeley.EDU (8.13.1/8.13.1/Submit) id j9PKVq6U019725; Tue, 25 Oct 2005 13:31:52 -0700
From: David Wagner <daw@cs.berkeley.edu>
Message-Id: <200510252031.j9PKVq6U019725@taverner.CS.Berkeley.EDU>
Subject: [Cfrg] Fwd: Hash-Based Key Derivation
To: cfrg@ietf.org
Date: Tue, 25 Oct 2005 13:31:52 -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: f4c2cf0bccc868e4cc88dace71fb3f44
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

Uri Blumenthal writes:
>David Wagner writes:
>> In the random oracle model, it is easy to prove that pre-hashing then
>> applying a PRF makes a good PRF. 
>
>What properties of hash are assumed in this proof?

Like I said, this is in the random oracle model.  The random oracle
model does not make any testable 'assumptions' about the hash.  Rather,
it replaces the concrete hash (e.g., SHA256) by a theoretical model
(the random oracle).  Roughly speaking, the model assumes that the hash
is ideal and has no bad interactions with the rest of the system -- but
this is not an 'assumption' in the usual provable-security sense.
The only way that I can identify a meaningful assumption is to assume
that the model accurately reflects reality; but that's not very helpful.

>> In other words, let
>>     F'(S,X) = F(H(S),X)
>> where F is a PRF (when its key-input is uniformly distributed) and H is
>> a random oracle.  Then F' is a PRF, even when its secret-input S is not
>> uniformly distributed, so long as S has sufficient min-entropy.
>
>Is it proven that hash function output is uniformly distributed?

Are you asking about a concrete hash function like SHA256, or a model
of the hash function (the oracle oracle)?

Yes, a random oracle is uniformly distributed.  This is proven.

No, it is not proven whether SHA256 is uniformly distributed.  Most likely
the output of SHA256 is computationally indistinguishable from uniform,
but not actually uniform in the information-theoretic sense.

>Are most cryptographers OK with modelling hash functions as random
>oracles?

The topic of the random oracle model has been well-discussed before
on several cryptography mailing lists.  But here is my view:

There is no broad agreement.  Personally, I believe the random oracle
model is a reasonable approach.  There is some possibility that real
vulnerabilities could go undetected by the random oracle model.  There has
been theoretical work pointing out examples of how this might happen,
though all the examples so far have been contrived.  I am not aware of
any case where this has ever happened in a real system.  I believe the
probability of a failure due to gaps in the random oracle model is much
lower than the probability of other kinds of failure modes, so I believe
this failure mode is so negligibly rare that it's not worth spending too
much time worrying over.  Of course, it is better to have a proof security
in the standard model, where possible, but if that isn't possible, then
the random oracle model seems to me to be a very reasonable fallback.
But that's just my personal opinion, and I know that others assess
things differently.  I feel sure that this has been discussed at great
length on CFRG before (and if it hasn't already, it will be soon).

If you're interested in learning more, I bet a search through the
archives of this list and of Perry Metzger's mailing list would yield
more useful background.

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