On Mon, Apr 15, 2019, 5:50 AM Hao, Feng <feng....@warwick.ac.uk> wrote:
> Hi Watson, > > On 15/04/2019, 00:39, "TLS on behalf of Watson Ladd" < > tls-boun...@ietf.org on behalf of watsonbl...@gmail.com> wrote: > > 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. > > OK, jargons apart - my point was about the assumption. If the relation of > the two system generators is known, the assumption of the proof is > violated, and the proof becomes invalid. > > > 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. > > As explained earlier, the difference is the "assumption" in the proof. > From the engineering perspective, we ought to prepare for the worst. When > one specific instance of the discrete logarithm is resolved, there is a big > difference between the class attack and the session attack. This is in no > way to say the SPAKE2 draft that you're working on is not useful (on the > contrary, I think it can be useful in some specific applications where the > effect of a class attack is tolerable), but I just want to point out the > factual differences between the two. > Attackers shouldn't be able to compute any discrete logs, and they cannot go back and break old SPAKE2 sessions with that information (DH reduction I should write up). > > > > 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 > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
