On Wed, Mar 27, 2019 at 7:56 PM Feng Hao <[email protected]> wrote: > > Hi Hugo, > > > > Thanks for your comments. > > > Just to clarify the difference between SPAKE2 and J-PAKE - The proof of > SPAKE2 depends on the assumption of a trusted setup: the discrete logarithm > between the two group generators must be unknown by anyone.
The above is not true: we rely on the common random string model, not the common reference model. This matters for below. >If a powerful adversary (3 letter agency) gathers sufficient resources and >time (say 1 year) to break one instance of discrete logarithm, it will be a >class attack, breaking all >instances of SPAKE2 without anyone knowing it. By >contrast, they can only break one session in J-PAKE, since by design the >randomness is refreshed in every session >rather than being built into a >static setup. This explain why J-PAKE requires more computation than SPAKE2. >Hope it clarifies. I don't know of a JPAKE proof that doesn't rely on Shamir-Fiat heuristic, which implies common random string. Your proof is in the ROM no? Also I do not see how one recovers the password from past sessions or recovers the negotiated key in this case: certainly an active attack is possible knowing a relation! > > > Regards, > > Feng > > > > From: TLS <[email protected]> on behalf of Hugo Krawczyk > <[email protected]> > Date: Wednesday, 27 March 2019 at 02:49 > To: Hannes Tschofenig <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [TLS] Elliptic Curve J-PAKE > > > > Hi Hannes, > > > > J-PAKE is a symmetric PAKE. Both parties store the same password. It is not > suitable for most client-server scenarios where using J-PAKE would mean that > an attacker that breaks into the server simply steals all plaintext > passwords. OPAQUE is an asymmetric (or augmented) PAKE where user remembers a > password (and nothing else, including no public key of the server) while the > server stores a one-way image of the password. Security requires that if the > server is compromised, the attacker needs to run an offline dictionary attack > for each user in the database to find the password. > > > > If what you need is a symmetric PAKE then there are better candidates than > J-PAKE such as SPAKE2 described in draft-irtf-cfrg-spake2-08. SPAKE2 is > *much* more efficient than J-PAKE and while both J-PAKE and SPAKE2 have > proofs of security, SPAKE2 is proven in a stronger security model relative to > J-PAKE. > > > > I am not aware of any advantage of J-PAKE over SPAKE2 - but I may be missing > something. Maybe the PAKE presentation in cfrg will clarify these issues > further. > > > > Hugo > > > > > > > > On Tue, Mar 26, 2019 at 1:03 PM Hannes Tschofenig <[email protected]> > wrote: > > Hi all, > > in context of the OPAQUE talk by Nick today at the TLS WG meeting I mentioned > that the Thread Group has used the Elliptic Curve J-PAKE for IoT device > onboarding. > Here is the draft written for TLS 1.2: > https://tools.ietf.org/html/draft-cragie-tls-ecjpake-01 > > The mechanism is described in https://tools.ietf.org/html/rfc8236 > > @Nick & Richard: Have a look at it and see whether it fits your needs. > > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
