Re: [Cfrg] Wack-A-Mole and PKEX 3.0 -> Re: Fwd: New Version Notification for draft-harkins-pkex-00.txt

Dan Harkins <> Mon, 12 September 2016 20:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6603412B10F for <>; Mon, 12 Sep 2016 13:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c3JAcaFiqmEP for <>; Mon, 12 Sep 2016 13:43:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 61AE712B106 for <>; Mon, 12 Sep 2016 13:43:17 -0700 (PDT)
Received: from thinny.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 28A2810224062; Mon, 12 Sep 2016 13:43:15 -0700 (PDT)
To: Paul Lambert <>, "" <>
References: <>
From: Dan Harkins <>
Message-ID: <>
Date: Mon, 12 Sep 2016 13:43:15 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: "Adrangi, Farid" <>
Subject: Re: [Cfrg] Wack-A-Mole and PKEX 3.0 -> Re: Fwd: New Version Notification for draft-harkins-pkex-00.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Sep 2016 20:43:19 -0000


On 9/12/16 12:59 PM, Paul Lambert wrote:
> Dan,
>> Name:		draft-harkins-pkex
>> Revision:	00
>> Title:		PKEX
>> Document date:	2016-09-12
>> Group:		Individual Submission
>> Pages:		9
>> URL:
> To prevent confusion on the nature and functionality it might be better to
> call this protocol PKEX 3.0.
> The PKEX 2.0 was already the subject of discussion on this list. I am
> encouraged to see that you acknowledge that PKEX 2.0 had some issues that
> included a MiTM attack. This attack is documented in:
> iew-and-pkex.ppt
> Comments on PKEX 3.0:
> 1) Qi term and Hunt-and-Peck
>          PKEX 2.0:  Qi = H(Alice)*Pwe
>                       Where Pwe = dhp(pw)    dhp() is dragonfly
> hunt-and-peck
>          PKEX 3.0: Qi = H(Alice|pw)*Pi
>                        Where Pi might be dhp(pw) or role specific fixed
>     For PKEX 3.0, I do not see how you can make the Pi and Pr terms be
> unique if you use hunt-and-peck.

   Well it's actually the same way that the fixed elements get
fixed for SPAKE2. The requirement is that the discrete logarithm
not be known and hunting-and-pecking based on an input string will
give you that. I suggest you look at SPAKE2 on how it generates
the fixed elements that it requires.

>     Putting the Œpw¹ into the scalar versus a ECC point is more efficient
> and is an improvement
> 2) Qi term and identity
>          PKEX 3.0: Qi = H(Alice|pw)*Pi
>       The use of ŒAlice¹ is problematic.  There is no indication in this
> write-up how Bob learns
>       ŒAlice¹ or Alice learns to identify Bob as ŒBob¹
>       In your IEEE submissions for PKEX 2.0, Alice and Bob are identified
> as MAC addresses (mac_a and mac_b).

   They are identities, not mac addresses. Authentication requires some
identity to authenticate so to use a public key for authentication in some
protocol like TLS or IKEv2 requires that the public key be bound to an
identity. How they learn each others identities to bind to the exchanged
public keys is not germane to the exchange.

>      If the goal of this protocol is to exchange Œraw¹ publc keys there
> should not be a requirement
>      to strt with a known identity.

   The goal is to exchange public keys that will be suitable for use in
an authentication protocol like TLS or IKEv2. If there is no identity bound
to the public key (as in a certificate) then what you get is 
and not authentication.
>            PKEX 3.0:
>              a, A = a*G (long term)         b, B = b*G (longterm)
>              x, X = x*G  (ephemeral)        y, Y = y*G (ephemeral)
>              Qi = H(Alice|pw)*Pi            Qr = H(Bob|pw)*Pr
>              M = X + Qa                     N = Y + Qr
>              --->M
>                                              N<---
>              u=f(a,Y,M,N,A,Y,pw,X,Y)         v=f(b,X,N,M,B,X,pw,Y,X)
>              --->u
>                                              v<---
>              R = A + Z                       T= B + Z
>              --->R
>                                              T<---
>          This is a significant change and may be an improvement in
> security. Hard to tell yet.

   That is the question I am asking. So?
>          The protocol has gone from a 4-step to 6-step protocol. Seems like
> 4-steps should be enough ...
> 4) How is PKEX used?
>     "At this point, if the parties didn't fail they have each other's
>     public key and trust that it belongs to the peer's stated identlty.
>     They can use the public key in another protocol to authenticate that
>     identity.²
>     ??? Not sure what a Œstated identity¹ means or how it is useful.
>     What is the next protocol, how does this work as a system.

   This is a cryptographic protocol and I am asking for cryptographic
review of it. How it fits into a system is not relevant to the protocol
or whether it is secure or not.
> 5) PKEX is not a key establishment protocol
>     PKEX  generates and then throws away a pair-wise unique key pair.
>     Seems like this class of exchange should also provide such key material.

   The goals and properties of the protocol are stated in the document.

> 6) is the goal to be a PAKE plus authenticated public keys (PAKE+Auth)?
>     If so, clarity on the use of the derived pair-wise key would be useful.
>     More interesting is if a PAKE is the right base mechanism to
> Œintroduce¹ public keys.

   There are no derived pair-wise keys to provide clarity on.
>     Short authentication strings (SAS) were brought up in the PKEX 2.0
> discussions and might be
>     a interesting line of pursuit for a useful protocol.
> The extension of a PAKE (like SPAKE) to carry long-term public keys is one
> possible design path.  For PKEX 4.0 9IMHO) a more generically useful
> exchange could be built using a SIGMA-I type authenticated DH exchange.
> The proof of holding the passphrase could be carried within the encrypted
> portions of the authentication exchange. Such a SIGMA based design could
> also readily be tweaked to generate a SAS. Seems like the same protocol
> could be used to optionally support OWE-like requirements.
> Hope these comments are useful ...

Sadly no, not really. They are not about the protocol but, instead, about
incorrect assumptions on what identities are and irrelevant things about how
this protocol fits into some larger system or about other protocols that 
nothing to do with this (OWE? Huh?). If you have any comments on this 
in this draft I would like to hear them.