Subject: Re: [Cfrg] password-based key exchange

From: "Igoe, Kevin M." <[email-masked]>
Date: Wed, 4 Jan 2012 08:14:37 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Dan Harkins
> Sent: Tuesday, December 20, 2011 4:38 PM
> To: [email-masked]
> Cc: [email-masked]
> 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
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 4 Jan 2012 10:30:08 -0800 (PST)

Hi Kevin,

  Thank you very much for reviewing this draft.

> groups specify both q and an element g of order q which generates the

  I believe the two techniques used in section 4.1-- one for FFC groups,
another for ECC groups-- return an element from a subgroup of prime
order q.

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

  The specification of this key exchange in IEEE 802.11 uses the IANA
registry created by IKE for "diffie-hellman groups" so it can use the
NIST elliptic curves, and the safe prime FFC groups (from 1024 bits
up to 8192 bits). Implementations are required to support NIST's 256 bit
random ECP group (group 19 from IKE's IANA registry).

  regards,

  Dan.