Re: [Cfrg] Fwd: New Version Notification for draft-harkins-pkex-00.txt

[Dan Harkins <[e-mail]>]

On 9/12/16 2:43 PM, Andy Lutomirski wrote:
> On Mon, Sep 12, 2016 at 1:19 PM, Dan Harkins <[e-mail]> wrote:
>>    Hi Andy,
>>
>> On 9/12/16 8:20 AM, Andy Lutomirski wrote:
>>
>> This appears to be more or less the same protocol described in the 802.11
>> DPP drafts.  It was terminally insecure then and it appears to be just as
>> terminally insecure now.  If it's really necessary for some reason, I can
>> reiterate the multiple ways I found to break it after half an hour of
>> thinking.
>>
>>
>> Yes please do show the multiple ways to break this.
> It's hard in this particular case because the draft does not define
> its symbols.  In particular, I'm guessing that (X, x) is Alice's key.
> So here's one break:

   The draft clearly says "Alice's public key she wants to share with Bob
is A and her private key is a, while Bob's public key he wants to share
with Alice is B and his private key is b." x/X is Alice's ephemeral share.

> Alice and Bob start running the protocol with one password pw1.  Alice
> sends X + Qa = X + F(pw1) * Pi where F is a function that an attacker
> can compute.  The attacker interrupts the exchange and Alice and Bob
> retry using a different pasword.  The draft *says* that the keys are
> ephemeral, but that's really hard to believe because the whole stated
> point is to establish a long-term key.  So Alice how sends X + F(pw2)
> * Pi.

   So your "attack" is based on the supposition that it's "really hard
to believe" an ephemeral key is ephemeral? Hmmm.

   What you have done is to look at the _very first_ of the Security
Considerations, decided to ignore the statement that says you void
the security of the exchange if you reuse ephemeral keys and then claim
you have discovered an "attack" on the protocol?

   Did you spend the whole "half an hour of thinking" to come up with this?


>> This protocol needs to be replaced, starting from scratch.  By "from
>> scratch", I mean that a real PAKE should be used, in its intended form.  The
>> result will not even need to mention "groups", because there is no reason at
>> all for the tiny bit of protocol layered above the PAKE to care that the
>> exchanged keys are anything other than opaque strings.
>>
>>
>>    I am honestly soliciting constructive comments. If you have some
>> please provide them.
>>
> Sure.
>
> Step 1: define clearly what you're actually trying to do.  I'll guess
> what you're trying to do: Alice and Bob are devices with keyboards,
> and there's a user (an actual person) who will come up with a
> temporary password to use to pair the devices.  Both devices have
> keyboards.
>
> Step 1: User chooses a password and types it in to both devices.
>
> Step 2: Alice and Bob run a balanced PAKE (DH-EKE, SPAKE2, whatever)
> using that password.  They do this the normal way, using fresh
> ephemeral random numbers as prescribed by the PAKE in use, and they do
> not keep any internal values around that they are supposed to discard.
> The result is a shared secret.  They do this PAKE exchange exactly
> once and they do not retry without explicit input from the user.

   Interesting that now "fresh ephemeral random numbers as prescribed
by the PAKE" are eminently believable yet you find such behavior
"really hard to believe" for PKEX.

>
> This has the usual balanced PAKE security property: an attacker gets
> exactly one guess with which to try cracking the password, and no
> off-line attack against the password is possible.
>
> Step 3: Alice uses her favorite authenticated encryption protocol,
> keyed by the shared secret, to send Bob her public key.  Bob now knows
> that whoever sent this key knows the password or got extremely lucky
> on their one and only chance to guess the password.

   And this provides absolutely no proof-of-possession. Bob got a public
key and he knows that Alice sent it to him but there is nothing that
Alice does to prove that she holds the corresponding private key.

   Proof-of-possession is an express property of PKEX (see section 2, 
Properties)
that you have not provided in your ad hoc construction. 
Proof-of-possession is
critical to obtain trust that a public key actually belongs to an identity.
If your ad hoc construction does not provide it then your ad hoc
construction does not solve the problem.

   Again, I solicit review and criticism but it would be nice if the 
criticism
was professional in tone and content.

   Dan.