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

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Wed, 05 October 2016 06:27 UTC

Return-Path: <smyshsv@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801AD126B6D for <cfrg@ietfa.amsl.com>; Tue, 4 Oct 2016 23:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns6C6O0A1zV4 for <cfrg@ietfa.amsl.com>; Tue, 4 Oct 2016 23:27:19 -0700 (PDT)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3BF129520 for <cfrg@irtf.org>; Tue, 4 Oct 2016 23:27:19 -0700 (PDT)
Received: by mail-it0-x235.google.com with SMTP id 188so89065535iti.1 for <cfrg@irtf.org>; Tue, 04 Oct 2016 23:27:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VLrGDJ9/EWGh1jswT2nSgPXCjZk811YAh3jIxn9TSoM=; b=d6iMJQkZ4KM4HwNsYtpmqKGgrX3SoJzABDX3izmJHnHoscbnP+IpvcW18RY7ATYNG9 FiWJ0wrFMSqHi1QdY9eXYhG3R8utP8WZY6o79oY12cHaTc+6S037RI2H86Xbi2H2Fk9s itAMZP14nhL0vfYrVFGV2DSnQZmhehsDlnIzUgQtStdTuxJuV6bUwpEX1OZzGShyQeTy B94Fj4cccNpMw60OYMqWc1SAsBmQWcIh+BHqWmGJjNkOLFNeWRrklGTdKfFgyE5Z/XGV kgOqYDLJSLa67ygjYRepPUVJuFPMJkesIX/qce//+Ql5CFj3Zs/7lZq7GinRsuV0U8FM i8qA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VLrGDJ9/EWGh1jswT2nSgPXCjZk811YAh3jIxn9TSoM=; b=WMhkzckFJdYr9HvDuSztlCIUNgiGw4fT+6+FqcUWV/MeUnvQXAjcUzIJCI/UuqVsqL 4hd46NxOaUP4ZXB9eoV0KGm+XPNjOxFHaovri/xoW47W4fSzRM27RYrWnS1WwBtDgzQd +XkBFbr/WWTVvUnttTp3AACcXa8DaLgDgwk9qw1YKQqjk9nnGSiddv2XwPzg/OqIEBtz mE3SmAPE/IsjfUmWPNEtM4X1wAbM9oyfcBkidEqV3mxn9aydSwr2Zno+qc5KLkGMp79F FKgCvmdUPnFzKZRA0mwfRd6QRz3ey58HPJklv7YcuGIFgGBxSKjFwfru+kCAmUxljNos 461g==
X-Gm-Message-State: AA6/9RlENH7xvr+WEf9/6JXe+2ny5JBLiWGc1kC8Tel44ZvIv/iWQ2UIpXAZAyGEBj5+F0PYPGWvFneBx24oeg==
X-Received: by 10.107.132.217 with SMTP id o86mr8486426ioi.81.1475648838472; Tue, 04 Oct 2016 23:27:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.225.44 with HTTP; Tue, 4 Oct 2016 23:27:17 -0700 (PDT)
In-Reply-To: <ed455dee-2e1c-b2b3-8624-620acdc04410@lounge.org>
References: <D41831C3.A2964%paul@marvell.com> <CAMr0u6k4U0fsXV2jHxam6Lk0OmmDS1NkV9Z43QF3sjJinW7fPQ@mail.gmail.com> <CAMr0u6ngTf+_eW_qhVz0G_jUNHUqPEMyQO+4A3xrqCh2tRe6FQ@mail.gmail.com> <D418A094.A29E7%paul@marvell.com> <CAMr0u6mUWxjqZbFBriMv8wDnmsWU6g2SBm3vnvOhX=B2rRF3aQ@mail.gmail.com> <c5853319-cfa5-1180-38ce-3fb438df8151@lounge.org> <CAMr0u6kpt-bMw7NVj=bjE3_9pqJs_oHX0mD7A5NR+qqBc9nACQ@mail.gmail.com> <ed455dee-2e1c-b2b3-8624-620acdc04410@lounge.org>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Wed, 5 Oct 2016 09:27:17 +0300
Message-ID: <CAMr0u6=bEb8Pz=1O_kdNHP3UXkSand9j6LrJJnUK_z0i6E8LjA@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary=001a113f85d4d49a56053e18445e
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/NbFNuC49ENENN5c8DMZH5J9Jaqs>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2016 06:27:22 -0000

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?

Of course.

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

This is the goal that is achieved by mbDH – if Alice has Bob's P_B, she can
be sure that the no one without having s_B can make her think that he
obtains s_B. If we add password authentication to mbDH, it is reasonable to
hope at least to keep the existing security properties. Otherwise, what
sense can be in SPM2? SPAKE2 and SESPAKE provide secure password-based
authentication and protected key exchange themselves.



Regards,
Stanislav




2016-10-05 9:09 GMT+03:00 Dan Harkins <dharkins@lounge.org>rg>:

>
>   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>rg>:
>
>>
>>   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 to SPAKE2. 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 values R_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 and y_B the 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 K is equal to the key of adversary = > decryption will be
>> correct => the check
>>
>> assert Y_B == y_B * P_B will 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>om>:
>>
>>>
>>>
>>>
>>> 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/80
>>> 2.11/dcn/16/11-16-1329-01-00ai-pkex-alternatives.ppt
>>>
>>> Best Regards,
>>>
>>> Paul
>>>
>>
>>
>> _______________________________________________
>> Cfrg mailing listCfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg
>>
>>