On Wed, Mar 27, 2019 at 11:36 PM Feng Hao <feng....@newcastle.ac.uk> wrote: > > Hi Watson, > > When the attacker knows the relation, besides the active attack, there may > be other things he can exploit. This however is not usually analysed as by > the assumption of the proof, this should never happen.
Random self-reducibility seems relevant here, as does the fact an attacker should be able to solve any discrete logarithm problems over a group one is using. > > You¹re correct that J-PAKE uses Shamir-Fiat heuristics, hence the proof is > in ROM. The key design principle in J-PAKE is based on understanding the > importance of zero-knowledge proof. The use of Shamir-Fiat heuristics to > make ZKP non-interactive is a standard technique in cryptography. In the > field of secure two/multi-party computation, ZKP is almost universally > used in every protocol. However, in the field of PAKE, to my knowledge, > J-PAKE is the only protocol that uses ZKP. On the other hand, if you think > about PAKE, it¹s fundamentally a two-party secure computation problem on > an equality function (with the side benefit that both sides produce a > common session key when the equality holds). This paragraph is not responsive to my assertion that ROM=> common random string. J-PAKE is an instance of a generic design approach where an honest but curious protocol is transformed into a malicious party secure on through adding proofs of correctness. Each of those proofs and verifications is expensive. Hence J-PAKE is expensive. The security of JPAKE versus SPAKE2 is the same: both are secure in the ROM. > > Cheers, > Feng > > On 27/03/2019, 20:08, "Watson Ladd" <watsonbl...@gmail.com> wrote: > > >On Wed, Mar 27, 2019 at 7:56 PM Feng Hao <feng....@newcastle.ac.uk> 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 <tls-boun...@ietf.org> on behalf of Hugo Krawczyk > >><h...@ee.technion.ac.il> > >> Date: Wednesday, 27 March 2019 at 02:49 > >> To: Hannes Tschofenig <hannes.tschofe...@arm.com> > >> Cc: "tls@ietf.org" <tls@ietf.org> > >> 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 > >><hannes.tschofe...@arm.com> 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 > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > > > > >-- > >"Man is born free, but everywhere he is in chains". > >--Rousseau. > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
