Hi Watson,
On 15/04/2019, 00:39, "TLS on behalf of Watson Ladd" <[email protected] on
behalf of [email protected]> wrote:
On Wed, Mar 27, 2019 at 11:36 PM Feng Hao <[email protected]> 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.
>
> Cheers,
> Feng
>
> On 27/03/2019, 20:08, "Watson Ladd" <[email protected]> wrote:
>
> >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.
>
--
"Man is born free, but everywhere he is in chains".
--Rousseau.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
