Re: [Hipsec] HIT construction for ECC HIs

Robert Moskowitz <rgm@htt-consult.com> Wed, 14 April 2010 15:10 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D4F28C27C for <hipsec@core3.amsl.com>; Wed, 14 Apr 2010 08:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.398
X-Spam-Level:
X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_50=0.001, J_CHICKENPOX_51=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxPdfHgb0oKQ for <hipsec@core3.amsl.com>; Wed, 14 Apr 2010 08:10:43 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 9DAA128C27F for <hipsec@ietf.org>; Wed, 14 Apr 2010 08:10:26 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id BB01568B6F for <hipsec@ietf.org>; Wed, 14 Apr 2010 15:04:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF9fNja1fl1e for <hipsec@ietf.org>; Wed, 14 Apr 2010 11:04:46 -0400 (EDT)
Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 756C168B67 for <hipsec@ietf.org>; Wed, 14 Apr 2010 11:04:46 -0400 (EDT)
Message-ID: <4BC5DAD0.6010400@htt-consult.com>
Date: Wed, 14 Apr 2010 11:10:08 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4
MIME-Version: 1.0
To: "hipsec@ietf.org" <hipsec@ietf.org>
References: <4BC5CB24.9050101@htt-consult.com>
In-Reply-To: <4BC5CB24.9050101@htt-consult.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Hipsec] HIT construction for ECC HIs
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Apr 2010 15:10:45 -0000

More on this from the

On 04/14/2010 10:03 AM, Robert Moskowitz wrote:
> This may only be applied to Diet HIP, but ECC public keys have some 
> interesting properties:
>
> The Private key is a uniformly distributed random number. From:
>
> draft-mcgrew-fundamental-ecc-02.txt, sec 5.3.1:
>
> The private key z is an integer between 1 and q - 1, inclusive,
> generated uniformly at random. (See Appendix B regarding random
> integers.) The public key is the group element
> Y = alpha^z. Each public key is associated with a particular
> particular parameter set as per Section 3.3.
>
>
> Thus the private key is uniformly distributed from the set:
>
> { 1, 2, .... , q-1 }
>
> Further a subset of the bits of the PK are uniformly distributed.
>
> Thus it is conceivable that the HIT for an ECC HI is just 96 bits 
> selected from the HI. To put it within the ORCHID context, it could be 
> a simple XOR with the HIP ECC context.
>
> Comments?

 From the IRTF cfrg list:

============================

Don't have a proof, but here's a couple of thoughts:

I actually wondered about the same question a few years ago and ran an 
experiment: I generated a few thousand public keys and ran the NIST 
randomness tests on them. Based on those tests, at least, the bits in 
the public keys did indeed look pretty random.

Actually, here's a proof sketch:
-- ECC public key has the form (x,y), where x,y in GF(2^n) satisfy the 
curve equations
-- Since the curve equations are quadratic in y, the standard compact 
form of a public key is (x,b), where b is a single bit that indicates 
which of the two possible y values (see, e.g., [1])
-- A random public key is generated as a random element of a cyclic 
group of order p~=2^n
-- So the entropy of the public key is approximately n bits, in a 
representation with n+1 bits
-- So the public key distribution has to be close to uniform, for some 
definition of "close" (e.g., in terms of Kullback-Liebler divergence)

[1] <http://csrc.nist.gov/rng/>
[1] <http://www.hpl.hp.com/techreports/98/HPL-98-94R1.pdf>

===========================================