Re: [Cfrg] I like PKEX

"Stanislav V. Smyshlyaev" <> Sun, 03 December 2017 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0D0D1241FC for <>; Sun, 3 Dec 2017 02:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K1xLtHYOBm8A for <>; Sun, 3 Dec 2017 02:36:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFF3A120713 for <>; Sun, 3 Dec 2017 02:36:26 -0800 (PST)
Received: by with SMTP id d4so18020434qtj.5 for <>; Sun, 03 Dec 2017 02:36:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VrlALeXVmJ3gp4oN20tODBDCPM0IKCwtukPUjiPV3XU=; b=WVM6EuNy2XwKwR6ErQ9lMyXdHEfUj6iYXjB/WVtMOSHHdegM1iRaScpJD8agLwFsRR RWslGKSVlt8xKHw7OHW6IWJgocaga8/PGoeddhR75EtEPr/Usu732h0xsCHKI4arBoQ/ dNhZhU3fSLivXQHq+Dw4hhXhJcMPECy8pbuY6i7OjwyiZpX7kg7ZTsYEhQEyU8TIvE0w 2OLvUnep5UKQzWdjwHmCTHBOQ7mY3Rs1K9yOh/Pwow9b6q1zX0oi03Xm5H/nFBz7kiz8 R+tikd96d2SvTpC0I0W0m0cbrvjbsha3lNFA/UZ3q19xPwYjsQU13WS8Acvc0z3UdGrk KCiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VrlALeXVmJ3gp4oN20tODBDCPM0IKCwtukPUjiPV3XU=; b=Mbf3VGZ6NvTPRxmNz9BRDfEwWk3N8Z06ITQKDgEHw1XE65wxjGp/m2/l3fCb2XUKCa 0ab1xhiTd7DbX9L8jAqN4bq4IL0I4isePWsPFRpHOiu+KDUWp3i5vjJf0GmwfNq+4Br1 qykCk84E7ilyR2iE0rQakF00QiQd6Pmwxerqj6uGdlq+Tudb+os8SUTZ+USxm3FFmznD ccVQTY70L9Fci0FszbW5pVnTz8t8Q6VLNtho4WdMz0IkkZYzJhO5XqMbl7vWH+IDRA2F 6l3CEuaAc24prTpLrobYDbWh8OgjANkMQZDhtlLeGarHRAoOWIL8HSce9mXaVB7DjxGD kMIQ==
X-Gm-Message-State: AKGB3mJolHrPppkxMwn/lf+UdVuPlRBtl71Dz+ygw/fSdADVruEg8Bst aZtMBUTTfYqoL3Dm9B+N04rZ6enoa0PCJo1OW7A=
X-Google-Smtp-Source: AGs4zMYclK5TECt+O9b71oqn08RNSkDarI5lljrZIwraHppE4q64M+K29vdup7xXLceiOJ5ZHwRQJAI2N/VmItlKdjU=
X-Received: by with SMTP id l5mr12817022qtf.299.1512297386095; Sun, 03 Dec 2017 02:36:26 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 3 Dec 2017 02:36:25 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: "Stanislav V. Smyshlyaev" <>
Date: Sun, 03 Dec 2017 13:36:25 +0300
Message-ID: <>
To: David Jacobson <>
Cc: Richard Barnes <>, "" <>
Content-Type: multipart/alternative; boundary="001a11417d2c7e37e6055f6d2cf8"
Archived-At: <>
Subject: Re: [Cfrg] I like PKEX
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 03 Dec 2017 10:36:29 -0000

Dear David,

PKEX/PAKEs cannot be seen as a silver bullet, that can solve any
authentication problems.

My view on the second and the third questions that you've raised is the
First of all, the usage of PAKE always assumes that there is a certain
password distributed among communicating parties - this type of protocols
is absolutely meaningless otherwise. That provides an answer to your third
question: PAKEs cannot provide any help for anonymous browsing.

On the second question and the security bootstrapping issue - PAKEs can
help in the following case: when some memorable secret is used for the
initial secure communication session, during which long-term secret keys
can be established and stored in the devices for all further authentication
purposes. But you're completely right that PAKEs can't be used without any
preceding actions (face-to-face communication, provision of some memorable
PINs to users, negotiation to some "security questions" etc).

Best regards,
Stanislav Smyshlyaev, Ph.D.,
Head of Information Security Department,
CryptoPro LLC

2017-12-03 6:46 GMT+03:00 David Jacobson <>:

> I'm not a web protocol expert, nor a PKEX/PAKE expert, so what I'm about
> to mention might be already solved.
> 1.  I'd like some advocates of PKEX/PAKE to give a brief explanation of
> what has to be added to browsers to make this work.  And, in particular,
> how can the end-user be sure that the thing asking for her account number
> and password is the genuine browser implementation of the client side of
> PKEX or PAKE, not some imposter?
> 2.  How do you bootstrap the security?    The connection can't be secure
> until the client presents some credentials.  But the client doesn't want to
> send credentials in the clear during the setup.  And the client wants to be
> certain that the entity she is communicating with is genuine.  So it looks
> like we have to use the present protocols for creating an account.   So we
> haven't really gotten rid of having to trust a CA.
> 3.  And a similar problem arises around anonymous browsing.   Suppose our
> end user wants to browse women's apparel and wants to look around and not
> identify herself unless she sees something she likes and wants to buy it.
> There are many people who advocate using HTTPS for everything to make it
> hard for an attacker to inject a malicious web page.  But with PKEX/PAKE
> the client either has to fall back on present protocols or be vulnerable to
> injected attacks until she has decided to reveal her identity.
>    --David Jacobson
> On 11/15/17 11:31 PM, Stanislav V. Smyshlyaev wrote:
> Though, unfortunately, I am not aware of any online banking systems or
> messengers that use PAKEs for user authentication, I'd like to mention
> (hope you consider it interesting) that there are some existing cloud
> signature solutions (digital signature servers) in Russia that use one of
> PAKEs to authenticate users to their private keys stored in a cloud - in
> a way that is pretty similar to the one that has been mentioned by Rich.
> Best regards,
> Stanislav
> 2017-11-16 15:23 GMT+08:00 Stanislav V. Smyshlyaev <>:
>> In fact, PKEX (password-authenticated key exchange protocol by Dan
>> Harkins, - for
>> Richard), as all secure PAKE protocols can help to upgrade most cases of
>> authentication, when some shared secret (password or, as in Rich's example,
>> an account number), to solutions which do not require having a primary
>> trust to someone you're authenticating to.
>> I'd also like to see PAKEs in the messengers, as I commented during the
>> CFRG meeting yesterday.
>> 2017-11-16 15:21 GMT+08:00 Richard Barnes <>:
>>> Sorry, what is PKEX?
>>> On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich <> wrote:
>>>> I think the PKEX stuff is very interesting.  It inverts the trust model
>>>> used on the Web.   Suppose I want to do some online banking with
>>>> My browser checks the server cert, and decided to trust it
>>>> if the CA verifies the identity. I then type my name and password into the
>>>> website. There is a risk if I end up at the wrong website.
>>>> With PKEX, I can use my name and password and the bank can use
>>>> something like my account number or other similar info, and we exchange and
>>>> get a shared secret. We then use that secret to get an authenticated ECDSA
>>>> key and then I switch to TLS and get its benefits.  No third-party trust is
>>>> needed.
>>>> I think this solves an interesting use-case and it would be nice to
>>>> have it in our toolbox.
>>>> _______________________________________________
>>>> Cfrg mailing list
>>> _______________________________________________
>>> Cfrg mailing list
> _______________________________________________
> Cfrg mailing listCfrg@irtf.org