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

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Wed, 05 October 2016 04:56 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 AD031129492 for <cfrg@ietfa.amsl.com>; Tue, 4 Oct 2016 21:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 DlTxStBmhfZS for <cfrg@ietfa.amsl.com>; Tue, 4 Oct 2016 21:56:07 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 82DF3128874 for <cfrg@irtf.org>; Tue, 4 Oct 2016 21:56:07 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id 188so86504177iti.1 for <cfrg@irtf.org>; Tue, 04 Oct 2016 21:56:07 -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=oZaFCu0nY4DPBN8wXcKKnDSWQvj9Rjki/CqkSI13RqE=; b=dRVLJCTuDNqLAPIC+cd72hUaN22ywbbMJuLxFd9je6XbNWtSq4atahpELBe6bxYkFj 60Q1JoYC2WrRkxaQCwLrahJMJH3X67C7t8GHmGledGFUtVeirUEqTLSK2Wy/C0R7/jeV M6fXg1NlDKuPvdwOh53vDQOsEaX/d4/V+KBIC1q1oh2xgUYKI4sssk8iQGQ33cJrGFAq D7sMZb9lUoLVKJjcqfN594wrrLNdOG7T9VAz2H6DEHmhO/2tMk53sFQ2JQiNOmf/VrZN xuiRlfcQ9I1whgJiogWlHy25ZzlkeRY5BsH8HAJpZXI/VhLXpyY7Vu8rmF3Grf1sdg/J IWtw==
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=oZaFCu0nY4DPBN8wXcKKnDSWQvj9Rjki/CqkSI13RqE=; b=luULAWHX6jJJ1nblpRff5SSxRtU8vfGX2Joms0uf6bAJNs5lhBhV7PWlgAOa75Q6rS JLMpxagvPcqAHCapeC/LfmtIrrMgH6AmtTWTDa2KnHPIXklJBzuB43UE/uLzrLoxBImg d3wUTKANO/pH70eSchATByPVPU+CYiv54yhS99QXcVk2wyC49HuXcYdUc2irulq2eSjH pCc8fuJFYmueupGQGpZkHSTkPLj7DrJmVlxdsoI91N89UaT4y7TzBZbk/j0cCxJJqAbe 7y0GhnIlpkrBXejchmORxw4QKOVmkK/cUnejl5cW2TvKuz3tzJqFDx6i4uYZeYDZtHdB 9yXA==
X-Gm-Message-State: AA6/9Rmd0ec1H5wdQhIF5C5KwmiF9o+b/Cw3sonTIa1IUZpbWjBy74fmDULP6Owbz7mYtqGVx2RjOv4nnYxHdg==
X-Received: by 10.36.212.6 with SMTP id x6mr8206034itg.71.1475643366794; Tue, 04 Oct 2016 21:56:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.225.44 with HTTP; Tue, 4 Oct 2016 21:56:06 -0700 (PDT)
In-Reply-To: <D418A094.A29E7%paul@marvell.com>
References: <D41831C3.A2964%paul@marvell.com> <CAMr0u6k4U0fsXV2jHxam6Lk0OmmDS1NkV9Z43QF3sjJinW7fPQ@mail.gmail.com> <CAMr0u6ngTf+_eW_qhVz0G_jUNHUqPEMyQO+4A3xrqCh2tRe6FQ@mail.gmail.com> <D418A094.A29E7%paul@marvell.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Wed, 5 Oct 2016 07:56:06 +0300
Message-ID: <CAMr0u6mUWxjqZbFBriMv8wDnmsWU6g2SBm3vnvOhX=B2rRF3aQ@mail.gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: multipart/alternative; boundary=94eb2c0b046ab16cc7053e16fe1c
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/59I1_yS7uen_sEn-JMgAOCNwKgg>
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 04:56:09 -0000

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).



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/
> 802.11/dcn/16/11-16-1329-01-00ai-pkex-alternatives.ppt
>
> Best Regards,
>
> Paul
>