Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA

   Hello Stanislav,

On 10/4/16 10:55 PM, Stanislav V. Smyshlyaev wrote:
> Hello, Dan!
>
> mbDH (without modifications to SPM2) allows mutual authentication by 
> private keys s_A and s_B in case the parties obtain trusted (i.e. 
> obtained by a well-authenticated channel before the mbDH itself, of 
> course) P_A and P_B – as well as ordinary authenticated DH.

So the parties must have some pre-existing authenticated channel through 
which
they exchanged and obtained trust in P_A and P_B? And if not, then mbDH 
provides
no authentication whatsoever. Correct?

>
> The thing I am talking about is that SPM2 seems not to provide it – 
> Alice, who has a valid Bob's P_B, can be tricked by an adversary who 
> doesn't have a correct s_B and has only the password.

   That does seem to void one of the goals of SPM2.

   regards,

   Dan.

>
>
> Regards,
> Stanislav
>
>
>
> 2016-10-05 8:45 GMT+03:00 Dan Harkins <dharkins@lounge.org 
> <mailto:dharkins@lounge.org>>:
>
>
>       Privyet Stanislav,
>
>     On 10/4/16 9:56 PM, Stanislav V. Smyshlyaev wrote:
>>
>>     Dear Paul!
>>
>>
>>     Thank you very much for the corrections.
>>
>>
>>     I. In the sense of PAKE everything seems to be OK now: now the
>>     proposed protocol is at least as strong as SPAKE2 itself – since
>>      SPAKE2 + mbDH for certain values of parameters is reduced
>>     toSPAKE2. Since the first part of SPAKE2 (key agreement itself)
>>     is proven to be secure, we may say that SPM2 should be a secure
>>     PAKE. Nevertheless a separate accurate proof would be interesting
>>     anyway – but I think this is not the thing we should care now
>>     about SPM2, there seems to be a lot more important problem.
>>
>>     II. The problem is SPM2 in the case of known password seems to be
>>     less secure than mbDH (it seems to be unsecure at all in this case).
>>
>
>       What security properties do you believe mbDH has beyond simple
>     DH-- i.e.
>     unauthenticated key agreement?
>
>       Dan.
>
>>
>>     Consider the following attack (thanks to my colleague Liliya
>>     Ahmetzyanova for the description)
>>
>>     Let the adversary who tries to impersonate himself as B, knows
>>     password w, but doesn't possess private key s_B and wants to make
>>     honest party A believe that he does it for some fixed value of P_B.
>>
>>
>>
>>     1.A sends the valuesR_A, Y_A, where
>>
>>     R_A = x_A * G + w * M_A;  (according to the protocol description)
>>
>>     Y_A = y_A * P_A = y_A * s_A * G; (according to the protocol
>>     description)
>>
>>     2.The adversary calculates for random x_B andy_Bthe values
>>
>>     Y_B = y_B * P_B;
>>
>>     R_B = x_B * G + w * M_B *– Y_B*;
>>
>>     K = x_B * (R_A – w * M_A) + x_B * Y_A       (     =     x_B *
>>     (x_A * G) + x_B * (y_A * s_A * G));
>>
>>     Then all actions are made according to the protocol.
>>
>>     3.A calculates K according to the protocol:
>>
>>     K = (x_A + y_A * s_A)(R_B – w * M_B + Y_B)    (    =    (x_A +
>>     y_A * s_A)(x_B * G)  );
>>
>>     The key Kis equal to the key of adversary = > decryption will be
>>     correct => the check
>>
>>     assertY_B == y_B * P_Bwill be successful;
>>
>>
>>     Thus SPM2 is not secure in the same case as mbDH is – it loses
>>     all private-key-related security when the password is known.
>>
>>     Again, Paul, please correct me if I missed something.
>>
>>
>>
>>     Best regards,
>>     Stanislav Smyshlyaev
>>
>>
>>     2016-10-04 10:44 GMT+03:00 Paul Lambert <paul@marvell.com
>>     <mailto:paul@marvell.com>>:
>>
>>
>>
>>
>>         Dear Stanislav,
>>
>>
>>             Just a small remark: I'm sure that in the second message
>>             you wanted to send "encrypt( key=sk_BA, ((y_B, P_B), ...)
>>             )", not "encrypt( key=sk_BA, ((x_B, P_B), ...) )" (and
>>             "y_A, P_A" correspondigly). Otherwise you would obtain
>>             exactly the same problem as before.
>>
>>
>>         Thanks! I missed making this variable change … appreciate
>>         your catching this error.
>>
>>         This update also made the shared key calculation more exactly
>>         match the SPAKE2 RFC and I missed changing the terms in this
>>         hash in a couple places.
>>
>>         These are now fixed in:
>>         https://mentor.ieee.org/802.11/dcn/16/11-16-1329-01-00ai-pkex-alternatives.ppt
>>         <https://mentor.ieee.org/802.11/dcn/16/11-16-1329-01-00ai-pkex-alternatives.ppt>
>>
>>
>>         Best Regards,
>>
>>         Paul
>>
>>
>>
>>     _______________________________________________
>>     Cfrg mailing list
>>     Cfrg@irtf.org <mailto:Cfrg@irtf.org>
>>     https://www.irtf.org/mailman/listinfo/cfrg
>>     <https://www.irtf.org/mailman/listinfo/cfrg>
>