Re: [Cfrg] password-based key exchange

"Igoe, Kevin M." <kmigoe@nsa.gov> Wed, 04 January 2012 13:15 UTC

Return-Path: <kmigoe@nsa.gov>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E871121F85BA; Wed, 4 Jan 2012 05:15:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6fvyeFjYwPX; Wed, 4 Jan 2012 05:15:31 -0800 (PST)
Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2A25521F8716; Wed, 4 Jan 2012 05:15:30 -0800 (PST)
Received: from MSCS-GH1-UEA02.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id q04DFPM6004461; Wed, 4 Jan 2012 13:15:29 GMT
Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA02.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Jan 2012 08:14:37 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 4 Jan 2012 08:14:37 -0500
Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B8F@MSIS-GH1-UEA06.corp.nsa.gov>
In-Reply-To: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] password-based key exchange
Thread-Index: Acy/X7Yum82oOjagRhO3T6IYweJmAwLgcKcw
References: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net>
From: "Igoe, Kevin M." <kmigoe@nsa.gov>
To: "Dan Harkins" <dharkins@lounge.org>, <cfrg@irtf.org>
X-OriginalArrivalTime: 04 Jan 2012 13:14:37.0865 (UTC) FILETIME=[CF719990:01CCCAE2]
Cc: tls@ietf.org
Subject: Re: [Cfrg] password-based key exchange
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2012 13:15:32 -0000

I really like this idea & can find no problems.

One nitpicking detail:  HashToElement should return an element of a 
cryptographic subgroup of (Z/pZ)*, i.e. an element of a cyclic subgroup 
of prime order q, q suitably large.  (Of course both sides should use
the 
same subgroup, but in practice this isn't a problem since the standard
mod p 
groups specify both q and an element g of order q which generates the 
cryptographic subgroup.)

I'm curious as to what size parameters are under consideration by IEEE.


> -----Original Message-----
> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf
Of
> Dan Harkins
> Sent: Tuesday, December 20, 2011 4:38 PM
> To: cfrg@irtf.org
> Cc: tls@ietf.org
> Subject: [Cfrg] password-based key exchange
> 
> 
>   Hello,
> 
>   I proposed a new TLS ciphersuite using a zero knowledge proof at
> IETF 82 in Taipei. The draft is here:
> 
>        http://tools.ietf.org/html/draft-harkins-tls-pwd-01
> 
> At the TLS WG meeting I was requested to ask people on the CFRG list
> with expertise in this field to take a look at it. So here I am,
> asking.
> If someone has some spare cycles this holiday season, if you just
gotta
> get away from the relatives, or you are just feeling in the giving
> mood,
> please take a look and comment. Any analysis on this would be greatly
> appreciated. (I tried to do a formal proof but I cannot, and that's
> what's prompting this).
> 
>   I can describe the key exchange broadly here. There are subtle
> differences in the draft-- like one side keeps a salted version of the
> password and communicates the salt during a HELLO message-- that don't
> affect the exchange. It is symmetric so I can describe it from one
> side's
> perspective. The side being described is "local" and the other side is
> "peer", it goes like this:
> 
> Given: local ID, peer ID, password, an agreed-upon set of domain
> parameters defining a finite field group (it works will elliptic
> curve crypto too) and using two function:
> 
>   - E = HashToElement(d) which takes some data, d, and hashes into
>     the finite field to return an element, E.
>   - x = H(y) returns a random stream, x, given some input, y.
> 
> The key exchange works like this:
> 
> 1. PE = HashToElement(local_ID | peer_ID | password)
>    gets a "password element"
> 
>    There is an ordering defined in the draft to ensure that the IDs
>    are put in the same order on each side.
> 
> 2. generate 2 random numbers between 0 and the order of the group, q:
> 
>    0 < local_rand, local_mask < q
> 
> 3. compute a scalar and an element:
>    local_scalar = (local_rand + local_mask) mod q
>    local_element = 1/(PE^local_mask) mod p
> 
>    where p is the prime and q is the order. Send local_scalar and
>    local_element to other side
> 
> 4. receive peer_scalar and peer_element from other side
> 
> 5. compute shared key, K
> 
>    K = (PE^peer_scalar * peer_element)^local_rand mod p =
>        (PE^(peer_rand + peer_mask) * PE^(-peer_mask))^local_rand mod p
> =
>        PE^(peer_rand*local_rand) mod p
> 
> 6. compute a confirmation
> 
>    local_confirm = H(K, local_scalar | local_element |
>                      peer_scalar | peer_element)
> 
>    send confirmation to peer
> 
> 7. receive peer's confirmation, calculate verifier
> 
>    verifier = H(K, peer_scalar | peer_element | local_scalar |
>                 local_element)
> 
>    if verifier equals peer's confirmation the peer is authenticated.
> 
> The peer does the same thing but from its perspective it is "local"
> and the side described above is "peer".
> 
>   Thank you in advance for any analysis that can be provided on this
> exchange.
> 
>   regards,
> 
>   Dan.
> 
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg