[TLS] password-based key exchange

"Dan Harkins" <dharkins@lounge.org> Tue, 20 December 2011 21:38 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 27AC31F0C35 for <tls@ietfa.amsl.com>; Tue, 20 Dec 2011 13:38:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.665
X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4e5+hY22pE32 for <tls@ietfa.amsl.com>; Tue, 20 Dec 2011 13:38:09 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net []) by ietfa.amsl.com (Postfix) with ESMTP id 70E0721F8560 for <tls@ietf.org>; Tue, 20 Dec 2011 13:38:09 -0800 (PST)
Received: from www.trepanning.net (localhost []) by colo.trepanning.net (Postfix) with ESMTP id 431BE1022404A; Tue, 20 Dec 2011 13:38:09 -0800 (PST)
Received: from (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 20 Dec 2011 13:38:09 -0800 (PST)
Message-ID: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net>
Date: Tue, 20 Dec 2011 13:38:09 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: cfrg@irtf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: [TLS] password-based key exchange
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2011 21:38:10 -0000


  I proposed a new TLS ciphersuite using a zero knowledge proof at
IETF 82 in Taipei. The draft is here:


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 |

   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