Re: [Cfrg] SPAKE2+mbDH a PAKE+PKA

[Andy Lutomirski <[e-mail]>]

For the record: I have nothing to do with the proposal here.  This thread
is the first time I've seen it.

I still think that the right way to do this type of exchange is to use
existing, proven primitives as black boxes.  I don't see why the concepts
of "point" or "group", for example, should be involved except insofar as
they occur in the details of the underlying primitives.

So if SPAKE2 is going to be used, use it as is.  Don't modify it without a
very compelling reason and a proof.

On Oct 1, 2016 10:22 PM, "Dan Harkins" <[e-mail]> wrote:

>
>   Paul,
>
>   Why are you and Andy Lutomirski asking for review of a couple of slides
> on a powerpoint deck? Especially a deck whose focus is about a different
> protocol that does not exist anymore. Make an Internet-Draft that specifies
> _exactly_ how the protocol runs and not some ambiguous powerpoint
> suggestion
> based on a slide that uses some abbreviated notation that you admit is
> incomplete?
>
>   An I-D should clarify the unclear stuff regarding how you suggest to
> use AEAD schemes. Some of these schemes have critical usage requirements--
> like NEVER reuse a counter-- that you will have to deal with. You can't
> just wave your hands and say "encrypt".
>
>   Given the fact that it is not really clear what you and Andy Lutomirski
> are proposing I can only reply to the slides that you provide under the
> caveat that they may be inaccurate given their poor specification. So...
>
>   The "mutually blinded DH" you and Andy Lutomirski propose is completely
> broken
> and provides absolutely no authentication at all. A DH by itself provides
> no
> authentication so doing another DH "under the protection of" another
> unauthenticated
> DH  does not magically create authentication out of thin air.
>
>   There is a difference between proof-of-possession and authentication. The
> former is necessary for the kind of exchange you propose but it is not
> sufficient.
> An unauthenticated DH provides the former but not the latter. Your
> mutually blinded
> DH also provides the former but not the latter.
>
>   The "mutually blinded DH" that you and Andy Lutomirski propose is
> susceptible to
> a simple man-in-the-middle attack due to the fact that it provides
> absolutely no
> authentication whatsoever. You have no idea who sends Rb and no idea whose
> public
> key is Pb. The fact that Pb is sent encrypted by a secret derived from an
> unauthenticated Diffie-Hellman does not change anything. In fact, it
> enables the
> attack.
>
>   Modulo the obvious concerns with your proposal being a couple of
> powerpoint
> slides I feel safe in saying that the protocol you and Andy Lutomirski
> propose
> is completely broken.
>
>   Dan.
>
> On 9/29/16 1:54 AM, Paul Lambert wrote:
>
>
> Dear Stanislav,
>
>
> Thank you for these links – they give a slightly new viewpoint on PAKEs
> applications (I think the most discussed question will be "for which
> applications will combining public keys and passwords be most useful?").
>
> Yes … it may be useful as a type of ‘introduction’ process.
>
>
> An editorial comment on the description of the protocol in the slides: it
> seemts that after the second message A should check that "R_B - w*M_B ==
> x_B * P_B", not "R_B == x_B * P_B" as it is shown now. Similarly with the
> B's check.
>
>
> And a tiny remark: there is a misprint in the plaintext that A encrypts on
> sk_AB for the third message: "(x_A, P_A)" should be there, not "(m_A, P_A)".
>
>
> Many thanks for catching my errors!
>
> I’ve updated the figures and reposted: https://mentor.ieee.
> org/802.11/dcn/16/11-16-1142-06-00ai-cryptographic-review-and-pkex.ppt
>
>
> About the protocol itself, I'll try my best to give you our opinion today
> or tomorrow.
>
> At a glance, it seems to be useful to add some specific requirements for
> the used "encrypt" functions now or some concrete cipher modes (e.g. GCM or
> CTR + HMAC)
>
>
> Yes, this is not clear. The notation slide mentions  AEAD encryption but
> could say more on requirements. The ‘additional data’ is not being used, so
> AEAD is not strictly required. For concrete examples, I’m considering
> AES-SIV or GCM-SIV or something similar.
>
>
> due to the words "decrypt is successful" (is it a real data authentication
> or just some padding check?). EMVco used to check PIN-blocks just by
> correctness of ECB decryption of IUN, so we should have more details here.
>
>
> Yes, exactly.  The decryption provides the validity check for the password
> based authentication and does need a better description.
>
> Best Regards,
>
> Paul
>
>
> Kindest regards,
> Stanislav
>
>
>
> 2016-09-29 4:25 GMT+03:00 Paul Lambert <[e-mail]>:
>
>>
>> The PKEX protocol ( https://tools.ietf.org/html/draft-harkins-pkex-00 )
>> provides PAKE functionality (with SPAKE2) and adds public key
>> authentication (PAKE+PKA).
>>
>> In looking at alternatives to PKEX, combining an existing and evaluated
>> authenticated public key exchange with a PAKE seems like an interesting
>> design path. To this end, the SPAKE2 protocol (
>> https://tools.ietf.org/html/draft-irtf-cfrg-spake2-03 ) combines nicely
>> with mutually blinded Diffie-Hellman (mbDH). Blinded DH (bDH) is described
>> in https://www.emvco.com/specifications.aspx?id=285
>>
>> A brief description of the resulting SPAKE2+mbDH protocol is contained in
>> slides 13 to 18 of:
>>
>>         https://mentor.ieee.org/802.11/dcn/16/11-16-1142-04-00ai-cry
>> ptographic-rev
>> iew-and-pkex.ppt
>> <https://mentor.ieee.org/802.11/dcn/16/11-16-1142-04-00ai-cryptographic-rev%0Aiew-and-pkex.ppt>
>>
>> Comments would be appreciated.
>>
>> If this protocol seems useful an RFC could be developed.
>>
>> Paul
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
>
>
>
>
> _______________________________________________
> Cfrg mailing [e-mail]://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>
>