Re: [Cfrg] I like PKEX

David Jacobson <> Sun, 03 December 2017 03:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B03A2126C22 for <>; Sat, 2 Dec 2017 19:46:54 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 yFmT0l0znFiE for <>; Sat, 2 Dec 2017 19:46:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAFEB124D6C for <>; Sat, 2 Dec 2017 19:46:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1512272810; bh=eKkE4FF6CZcWrFGh42WLOKfdulur8g9SlrvQOwKn6A8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=TaE6jJ8GPwWs2ER2YBGXHR35Eb3kSogz8jjXTu/Jomrnm+6VsbcfyK41b5nYSUhAvfHIj3LS99iAj7eGV8KUDUysS2sBZH+uKMacffNYJHpgZvqNamJLIGVM8vMDPVmvrS3bze8wmX2QLMtx3UU8YDOZToX6IO/c6cVAq7dBwHplTbyyZuWmwQ+LYvM8OqLumb3lnV3X9qG0XVpr9GY8O21m/9JKyEGItNZupHJ8nPuS1fekm/vRJpWHjMaVtZTyQEZ6HcJSJdQaZNB3gmdcIRbwf1phCaxLhOCjaVGqGdpAwvEe8ZYo664NV+CEmhlmzmZyNe3PeWOeqscmnElXAg==
X-YMail-OSG: Ga8jmeYVM1l3MbxnelsTgL_X63kiqB3vJoYAann0xQg9LLEqfmZ2Uew_G.1pK4l j31gQoTasNKAXQq4uCbOs1TqWwShJ6iczNlauDkXxRvUwyMjcl9s.vQfRyOqpwo7SXLsvYryVI7S ovTAwqHqOTZnBS7ZhAidWCtmclansKycE2sjLqS7u4k4jPP4xjnFigMNDBs40yvQ6fMO33Lx.hc7 0HqjTrWM8Cw68fbRnj8RXllZLqZXVHw7UYdfSb.Ecgq_IDvlge2t3GmCpsgjxDyP751_Xh6etduY SvXYLioOA2M7zhORRkUncod_GmkLgnojQAdSQNh50hDu8iGJylmBf2N5IeKK5pUBxt9oO6cQhgUz h_SLDlt3PG9H.5ERWZDnxUeQuiTUkuaTmYxO1EvukiTLnBXVP2sljR5BBzeLob_rHEVmSjJfFNPt 9HUqBOa6nMZVE8H2N0B.uS.QkHsiG6pKqNQ5ixiZFC2YPkQDEK4s7_g1ySWEGp3.RaxXgfJve64J DyHZvcrmo1Xrx1EEj
Received: from by with HTTP; Sun, 3 Dec 2017 03:46:50 +0000
Received: from (EHLO Davids-iMac.local) ([]) by (JAMES SMTP Server ) with ESMTPA ID 1716476646; Sun, 03 Dec 2017 03:46:49 +0000 (UTC)
To: "Stanislav V. Smyshlyaev" <>, Richard Barnes <>
Cc: "" <>
References: <> <> <> <>
From: David Jacobson <>
Message-ID: <>
Date: Sat, 02 Dec 2017 19:46:46 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------DD053119B569B3027A2891C2"
Content-Language: en-US
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 03:46:55 -0000

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 

    --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 list