Re: [Cfrg] Updated review of PAKEs

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Sun, 08 March 2020 22:30 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 72FD23A098D for <cfrg@ietfa.amsl.com>; Sun, 8 Mar 2020 15:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0csohlvAdKiV for <cfrg@ietfa.amsl.com>; Sun, 8 Mar 2020 15:29:59 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 4BE343A0936 for <cfrg@irtf.org>; Sun, 8 Mar 2020 15:29:59 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id i10so6062784lfg.11 for <cfrg@irtf.org>; Sun, 08 Mar 2020 15:29:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8YcN6gW+W6RNoWLSpqhHjtRRjNHAmYakZblULN2QZas=; b=kyMucJ8xm+nuRdiTgqGcjbCQrWkVV2P16mGY/d6OiHJiQHaTEH3oCSnLkh3ujtrqev +YDBMu01XWfWpxX8UJX8fhK0zxWpY19JaPdqrRaOy4+AALMW9Fhw3NU40rmFh1gtGZxt 3vu1/g4yp4XpkNVeNZxEOprFmgk7WNh7LwK7JdXI+FsBH1M9BvH5tnGelEaNGeobekh8 SBU6NkglgYoe/UEEx4MaEcA5Ow4fNEvfq1nUXlErtCl+H8CAIT+nbNxgL8LySf+gZeQU iu1F3p9gpbqhf6/iG+shf5DmV+X+AfUxEjbp7cjeRD0shErpYOQGLqO2AOdEpR9fqx6A anGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8YcN6gW+W6RNoWLSpqhHjtRRjNHAmYakZblULN2QZas=; b=dSaNJ3MHjPtm2sUr4wmEoLU+/Z2YGaZjcSnaeAhk0eGneXO2UNKbhqKYlvrOsgLVak xHtdfMGdQ3atyrDOKxRDNBzZZxKRU2h9t1qwAIoDAsGsUAr9V+zceKjEgIYd/nf1GGIJ bvp3Mosa5AUhTG7+P26d8kh1pSiz77f/BnOfv59JRwZ16yP59rL6ql7X/PHQHNIVSXcb +shqwFa9fK2xPkD1kmBB9ZklXa17Kg1y0gHf8So8H2HeLLS+1+D1zqQwLvz3e7mJDpJx t4aQGnp5hrUvLlxbNQPAg3xHxndayulxcwEDG3V/fdTPW1Y6gmv580mfjhSs5dgOzU8t GF8w==
X-Gm-Message-State: ANhLgQ1S1QnElOmvpp7HkDwjvpOFZmKDeXSbuCHnufMsvEm9UQjnxy72 KKDcUOyThmYbV/gpjK0PLEpcjfDKov8DqPNGZV8=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vvthhR+my51MlBAF/3gzVtkdXw8oPfIPfTkPXBS?= =?utf-8?q?FMki3VaByXzr1xH4FzACcxtxkHDESscXhl9fEhL5DdcPuAY=3D?=
X-Received: by 2002:ac2:53b8:: with SMTP id j24mr1462206lfh.79.1583706597071; Sun, 08 Mar 2020 15:29:57 -0700 (PDT)
MIME-Version: 1.0
References: <02E5DBB7-10F9-4595-94D2-9F3A96F5AE46@ieee.org>
In-Reply-To: <02E5DBB7-10F9-4595-94D2-9F3A96F5AE46@ieee.org>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Mon, 9 Mar 2020 01:29:46 +0300
Message-ID: <CAMr0u6n+kKmVUNT9UF3iMe=VS8YLWSwGAVmMJB++jUcKSzDVbA@mail.gmail.com>
To: Bjoern Tackmann <bjoern.tackmann@ieee.org>
Cc: cfrg@irtf.org
Content-Type: multipart/alternative; boundary="000000000000259e9005a05f6d74"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/KNtCSSwx5JYxLziV6SRaZc0QxpM>
Subject: Re: [Cfrg] Updated review of PAKEs
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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: Sun, 08 Mar 2020 22:30:12 -0000

Thanks a lot, Bjoern!

Regards,
Stanislav

пн, 9 марта 2020 г. в 01:24, Bjoern Tackmann <bjoern.tackmann@ieee.org>rg>:

> This is a brief update of my review of all candidates sent on October 29
> [1]. Note that there was a follow-up discussion in which Hugo pointed out
> flaws in my report. (None of them had an effect on the outcome.)
>
>
> Balanced PAKE
> ===========
>
> The short version is that I prefer CPACE over SPAKE2. The arguments are
> essentially the same as in the previous review. SPAKE2 seems an (almost)
> equally good alternative, and picking one of the two was difficult.
>
> Sparked by Julia’s excellent review of the proofs [2], I wanted to share
> some of my own thoughts on this in a bit more detail. I fully support
> Julia’s argument that SPAKE2 has a published proof that is written clearly
> and in detail, and that has withstood scrutiny since 2005. The CPACE proof,
> by contrast, omits several important steps (such as all reduction
> arguments), has been more of a moving target during review, and has been
> published only last year. The SPAKE2 theorem is in concrete security (which
> I think is an important aspect), whereas the CPACE theorem only provides an
> asymptotic “soundness” guarantee. And yet, the formal statement for SPAKE2
> has the assumption of uniformly distributed passwords; the protocol does
> not seem to use this anywhere but it is still a limitation in the proof
> support. It is also unclear how the proved security of SPAKE2 composes when
> the key is used in higher-level protocols. And last but not least, I think
> (disclaimer: what follows is not a statement I can make formal) that the
> dependency on stronger idealization in the proof of CPACE is linked to the
> use of a security model that is significantly stronger in corruption
> modeling. So in terms of proof support I find the two protocols
> incomparable, and my preference for CPACE mostly comes from the “more
> useful” (targeted) security statement. I fully understand Julia’s reasons
> for coming to a different conclusion.
>
> Finally, and although it may be unnecessary to point this out: even subtle
> changes in protocols invalidate existing security proofs. I think it would
> be prudent for CFRG to re-evaluate the proof support after the
> now-discussed modifications to the chosen protocol (e.g., choice of session
> id for CPACE, choice of M,N for SPAKE2) are finalized, before deciding on
> the final outcome (“zero or one” candidates) of the process.
>
> And just for completeness: I deliberately did not take possible IP issues
> into account.
>
>
> Augmented PAKE
> ===========
>
> The short version is that I prefer OPAQUE over AUCPACE. The main arguments
> are OPAQUE’s better compatibility with important application protocols
> through less protocol messages, and its flexibility.
>
> Amending my previous review, the latest proof for OPAQUE is indeed a
> significant improvement over the one that was available when I started that
> review. So besides the preferable properties stated above, I now consider
> the proof support for OPAQUE also as better than that for AUCPACE. (This is
> in full agreement with Julia’s assessment.)
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/cfrg/1sNu9USxo1lnFdzCL5msUFKBjzM/
> [2]
> https://mailarchive.ietf.org/arch/msg/cfrg/47pnOSsrVS8uozXbAuM-alEk0-s/
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>