Re: [Cfrg] The SESPAKE protocol and PAKE requirements

Станислав Смышляев <smyshsv@gmail.com> Tue, 26 April 2016 14:40 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 2568912D1DD for <cfrg@ietfa.amsl.com>; Tue, 26 Apr 2016 07:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 N7ctx9ZO_dco for <cfrg@ietfa.amsl.com>; Tue, 26 Apr 2016 07:40:54 -0700 (PDT)
Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (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 D61D612D1DB for <cfrg@irtf.org>; Tue, 26 Apr 2016 07:40:53 -0700 (PDT)
Received: by mail-lf0-x244.google.com with SMTP id u64so2682359lff.2 for <cfrg@irtf.org>; Tue, 26 Apr 2016 07:40:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc; bh=i/hsIblVcNVMWkfmyvQW0dTJ/Q/OcAqopBftHlG+zeY=; b=pJCIe8tGsetL5Ga++zeensVCIC1Ykaz/c5pPQ4qKAfumNjKsBpLPN8y0Igz6/jNIAQ sGxs6ctUOG1CcTqIO3YWl406DkEE5HZrAT0XPp2uPTm2qmZE07GyZTZSZJ9BBHWs5e+V 65b3gOBIXJjO/m+R+VM25G01ZMM2RIarwrHjjdak/CttJAttWIAqGVOyg13UZNhr9bm5 Z1odb7nkwowXKgbYsvTmvwrVoBhyuLUQUT00BCk8vKxEolC1tN/wDtUisAOqTESXN20X KBBtmeSOtTz/n5AO7MmHi4ytZIZgvTU6ZF9DG5s7YBhAdtLkSxbnX7boHHGvXVGzmKtF bEvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc; bh=i/hsIblVcNVMWkfmyvQW0dTJ/Q/OcAqopBftHlG+zeY=; b=DRcNXVRo60te6MyMRBrHVt3VNvs7vnXba3YQLE8XbXALN0gIfS+WUkVyt5F5ke7ZIh SI5e0Ex2/lgGrTbeIyOb4oryLPpeEXgKafJJM7bKUCYPGf4QgPesXwxsGNg8m0TfeK73 M3kqAwiHXcYoU9iDLT4NfamSWMkiJyM0LNS2QWbmF1PRaxSfSu+6t+kiR6j8HqJwJhh1 24gJL7ja+HP0hnASAmUVoQ2vxvTHPV3rDxuz5NiGV6By0QSglQ7MYpc0NgBtPVPxd4Ei UwulAHHVhXmIDS5qbrrtne1cyzfxfXqrqsJxDsBjD8L1uJt0CkEXygidDslBnQYo3xWG gxkg==
X-Gm-Message-State: AOPr4FXrg7+dqz+oO8aF//W8MLduCflC/e+a/JdPR2XnBGGsptp2PiO/TSHSJQTHH+ri0Q==
X-Received: by 10.112.160.199 with SMTP id xm7mr1257823lbb.32.1461681650689; Tue, 26 Apr 2016 07:40:50 -0700 (PDT)
Received: from [127.0.0.1] ([213.87.146.65]) by smtp.gmail.com with ESMTPSA id ez1sm5356982lbc.29.2016.04.26.07.40.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2016 07:40:49 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Mailer: BlackBerry Email (10.3.2.2876)
Message-ID: <20160426144049.5910610.54445.3223@gmail.com>
Date: Tue, 26 Apr 2016 17:40:49 +0300
From: Станислав Смышляев <smyshsv@gmail.com>
In-Reply-To: <38634A9C401D714A92BB13BBA9CCD34F23476BA3@mail-essen-01.secunet.de>
References: <CAMr0u6nu=0H8pi=rEC1i69y1nhGLStvbJUXukUX0uHaVperkSg@mail.gmail.com> <38634A9C401D714A92BB13BBA9CCD34F167B5300@mail-essen-01.secunet.de> <CAMr0u6=eKJyCVQwHpuBLzB2TrrUQrfP8ti9N+Ai108=iS9tkZA@mail.gmail.com> <38634A9C401D714A92BB13BBA9CCD34F167B8267@mail-essen-01.secunet.de> <CAMr0u6m7TD2Nx29q+gFOBEFRswSiSCzXmGoVP_AmZtNhs0vUFw@mail.gmail.com> <CAMr0u6=YnFXRDtXxHuz03g2-Dt74Z1HZ3Pa3GVYOa2_hPFsgrw@mail.gmail.com> <38634A9C401D714A92BB13BBA9CCD34F23472FB0@mail-essen-01.secunet.de> <CAMr0u6kU2r=xKwAwCW+oCcA=-BDAEb7E2pbx6Df=DDw2-OkGXQ@mail.gmail.com> <38634A9C401D714A92BB13BBA9CCD34F23476BA3@mail-essen-01.secunet.de>
To: "Schmidt, Jörn-Marc" <Joern-Marc.Schmidt@secunet.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/cDCyxbRAw9NgzSQ9li-J6DVj7_Q>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] The SESPAKE protocol and PAKE requirements
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: Tue, 26 Apr 2016 14:40:56 -0000

‎Dear Jorn,

Thank you very much for your response.

That's my point: Eve obviously can always guess the password with a nonzero probability, but that doesn't mean that we do not need to address false authentication attacks at all - this only means that it has to be proven that for a certain PAKE protocol the probability of Eve's false authentication has the form of q/|D| + \nu(n), where D is the password set, n is the security parameter, q is the limit of trials (online) and \nu(n) is negligible if all used primitives are strong. ‎

A proof of a statement of this kind is crucial to evaluate the real security (in fact, probability of a false authentication or obtaining some info about a key) for a specific allowed limit of trials, password length and alphabet and adversary resources. 

‎Thus I think it is important to specify that the PAKE proposal must have a clear (and proven) security evaluation (kind of "Pr <= q/|D| + \nu(n)" ) for threats of 1) key distinguishing and 2) false authentication. 
‎
Best regards,
Stanislav‎
  Исходное сообщение  
От: Schmidt, Jörn-Marc
Отправлено: вторник, 26 апреля 2016 г., 15:22
Кому: Stanislav V. Smyshlyaev
Копия: cfrg@irtf.org
Тема: AW: The SESPAKE protocol and PAKE requirements

Hi Stanislav,

thank you for reviewing the document and your feedback. 


>Maybe it will be helpful to add in Section 4 (after it is stressed that "PAKE scheme should come with a security proof and also clearly state its assumptions and used models"), which threats are most relevant (and >thus which threats must be addressed in adversary models considered in secutiy proofs)? For instance, a threat of distinguishing a key from a random string and a threat of false authentication.


I'm not completely sure how to address this. My understanding of a proof for a PAKE scheme is that Eve must not learn more than that there was a key agreement when listening to one. In case she hits the password by guessing, she wins - that's something you cannot prevent. I tried to describe this in the Section 4: 
"That is, if Eve is unable to take information from a passive attack or a single active attack and enumerate through her dictionary then the only attack left is repeated guessing attacks. Eve learns one thing from a single active attack: whether her single guess is correct or not. In other words, the security of a PAKE scheme is based on the idea that Eve, who is trying to impersonate Alice cannot efficiently verify a password guess without interacting with Bob (or Alice) and hence is detected. "

Do you have a suggestion how to improve this section to underline specific threats? 

Best regards,


Jörn