[curves] Use cases for PAKE?

[wasa bee]

although the idea of using J-PAKE for end-to-end messaging with shared
secret looks interesting, do you realistically believe users can set and
remember different codes for different contacts? would you then end up with
same pwd for your wife and mistress :) There's also been some research
about PIN/code selection which shows it's not uniformly distributed so you
might be able to just guess it. So do you plan to have an
unbrute-force-able random shared secret stored on the phone, with the
shared secret possibly be exchanged face-to-face (or something along those
lines)?


On Thu, Mar 20, 2014 at 10:23 AM, Feng Hao <feng.hao at newcastle.ac.uk> wrote:

>
>
>  * PAKE for the web has been attempted in TLS (RFC 5054) with little
> interest from browsers or sites.  Partly this is a layering problem
> (username in clear, too early in the connection, and the TLS terminator is
> the wrong place for client auth).  But there are deeper UI problems:
>  browsers would have to display an unspoofable dialog; users would have to
> be trained to enter certain passwords only into this dialog; and sites
> would lose control of login UI.  Client auth for the web seems likely to
> evolve in other directions (e.g. password managers, 2-factor, federation).
>
>
>
> The web UI is indeed a major issue. It should be possible for the web
> browser to add a trusted UI for entering passwords (e.g., possibly in the
> address bar next to the web address where you click to find out the
> certificate details). But still, the question is how to educate ordinary
> users to *only* use this trusted interface for password entry. If a
> phishing website displays a password field in the web page and asks users
> to enter the password, then the PAKE mechanism is entirely bypassed and
> becomes useless.
>
>
>
>  * SSH already has J-PAKE which (I think?) is rarely used, though I'm not
> sure why.  If part of the reason is performance, is there room for
> improvement here?
>
>
>
> I don't think performance is any issue. I guess the main concern may be
> that J-PAKE has not been formally standardized. I submitted an initial
> proposal (
> http://homepages.cs.ncl.ac.uk/feng.hao/files/RationaleForJPAKE.pdf) to
> the UK standards committee meeting last month in Feb, and it passed the
> preliminary review; next month, I'm going to present J-PAKE, as the UK
> input, to ISO/IEC at the international SC27 meeting (http://www.sc27.hk/).
> I had hoped to get J-PAKE published as an RFC in IETF, but it was slow and
> it is still not clear to me how the IETF process works.
>
>
>
>  * IEEE 802.11s I think has standardized on "Simultaneous Authentication
> of Equals" (aka Dragonfly) as an EC PAKE. I don't know if it's seen real
> deployment, nor do I understand the "mesh networking" scenario it's being
> used for, which seems different from just authenticating a client to an AP.
>  Anyone know more?
>
>
>
> I don't think the EC version of Dragonfly is fully specified. It is
> derived from SPEKE, and has the same issues as SPEKE when it comes to both
> DL and EC implementations (the file in the above link gives a bit more
> details).
>
>
>
>  * There are smaller, more specialized uses of PAKE for protocols like
> online backups or device pairing.  E.g. I think Chrome is (using?
> investigating?) SPAKE2 for "chromoting", whatever that is.
>
>
>
> Do you know if there is any sample source code of SPAKE2 somewhere that
> people can view? I am curious to learn how the two generators are actually
> implemented.
>
>
>
> Anyways, it's not clear that there are strong-enough use cases to motivate
> a good discussion and keep it on track.  Though I wish there were!  PAKEs
> are cool, it seems like they should be useful somewhere.
>
>
>
> I believe there are useful use cases in certain applications. Currently,
> I'm supervising an undergraduate student project. The student is developing
> a secure messaging app for Android. The app establishes a secure E2E
> communication channel with another Android phone user via a google cloud
> after both users enter the same short code at two phones. The encryption is
> end-to-end, so no third parties, including Google, ISP etc, are able to
> eavesdrop. The app is based on J-PAKE (using the existing boucycastle
> implementation). We plan to release the app for free when the project is
> done, possibly, in the next 2-3 months.
>
>
>
> Other thoughts?
>
>
>
> Trevor
>
>
>
>
>
> [1] http://eprint.iacr.org/2009/340.pdf
>
> [2] http://elligator.cr.yp.to
>
> [3] http://www.ietf.org/mail-archive/web/cfrg/current/msg03840.html
>
>
>
> _______________________________________________
> Curves mailing list
> Curves at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/curves
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20140320/6258c7ca/attachment.html>