Re: [Cfrg] On using ROs for analyzing randomness extraction functions

John Wilkinson <wilkjohn@gmail.com> Sun, 30 October 2005 19:27 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 1EWIpd-0007iC-Tv; Sun, 30 Oct 2005 14:27:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIpb-0007h1-ML for cfrg@megatron.ietf.org; Sun, 30 Oct 2005 14:27:03 -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 OAA10788 for <cfrg@ietf.org>; Sun, 30 Oct 2005 14:26:44 -0500 (EST)
Received: from wproxy.gmail.com ([64.233.184.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWDRg-0006x0-R1 for cfrg@ietf.org; Sun, 30 Oct 2005 08:42:07 -0500
Received: by wproxy.gmail.com with SMTP id i21so360388wra for <cfrg@ietf.org>; Sun, 30 Oct 2005 05:27:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=r2y1l0uImkP7YI9rtsK6JjcmjTcNP9fQoECaqHora+7evnQAZ17+Y8yr1jKZqke3fF3JJWnV6VkgVcH9Mu4kU9htSXwlgwXF7dMTS6jAMVLVHST+EwW79gVOIs2vYmNUiByeemdDHk7euebbiz8g/EI1nYBClw6YBCRa4AJywy4=
Received: by 10.64.143.6 with SMTP id q6mr762447qbd; Sun, 30 Oct 2005 05:27:32 -0800 (PST)
Received: from ?10.0.1.2? ( [141.154.76.225]) by mx.gmail.com with ESMTP id e15sm1056761qbe.2005.10.30.05.27.31; Sun, 30 Oct 2005 05:27:32 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: <Pine.A41.4.58.0510290053020.30282@prf.watson.ibm.com>
References: <200510282114.j9SLEarq012372@taverner.CS.Berkeley.EDU> <Pine.A41.4.58.0510290053020.30282@prf.watson.ibm.com>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <5719CDC5-3557-4E5F-9E82-9342BC8685ED@gmail.com>
Content-Transfer-Encoding: 7bit
From: John Wilkinson <wilkjohn@gmail.com>
Subject: Re: [Cfrg] On using ROs for analyzing randomness extraction functions
Date: Sun, 30 Oct 2005 08:27:34 -0500
To: cfrg@ietf.org
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit
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

Perhaps this is the discussion topic I should have replied to with my  
questions about Bernstein and Wagner's non-NIST KDF discussion. I  
apologize for any confusion I may have caused on the other topic.

Perhaps some will think it is only of academic interest, but I, for  
one, would be very interested in continuing the discussion on KDFs  
that can minimize, or avoid entirely, our reliance on the RO  
assumption for hash functions. So, in the interest of having a  
suitable target to throw darts at, what, if anything, is wrong with  
the following proposal, and does anything like it already exist as a  
standard or write-up?

1. Assume that there has already been an authenticated DH key  
exchange (details and caveats to be fleshed out later), resulting in  
the sharing of the secret g^xy between Alice and Bob.

2. To extract "computational entropy" (or whatever term is most  
correct) from g^xy, Alice and Bob each use, as specified by their  
protocol, the fixed universal hash function H(g^xy), where H(m) is  
defined as:

H(m) := m*x^256 mod x^256 + x^10 + x^5 + x^2 + 1

Where m is interpreted as a polynomial in x, with coefficients modulo 2.

3. H(g^xy) can then be used directly for further communications, if  
only 256-bits of key material are required, or H(g^xy) can be used as  
the key to a PRF (say, HMAC-SHA256 or CMAC-AES256) to derive more key  
material.

Such a construction would seem to be efficient and practical, and  
avoids any reliance on random oracles, so, something must be wrong  
with it. :)

-John


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