Re: [TLS] Elliptic Curve J-PAKE

[Watson Ladd <[e-mail]>]

On Mon, Apr 15, 2019, 5:50 AM Hao, Feng <[e-mail]> wrote:

> Hi Watson,
>
> On 15/04/2019, 00:39, "TLS on behalf of Watson Ladd" <
> [e-mail] on behalf of [e-mail]> wrote:
>
>     On Wed, Mar 27, 2019 at 11:36 PM Feng Hao <[e-mail]>
> 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" <[e-mail]> wrote:
>     >
>     > >On Wed, Mar 27, 2019 at 7:56 PM Feng Hao <[e-mail]>
> 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 <[e-mail]> on behalf of Hugo Krawczyk
>     > >><[e-mail]>
>     > >> Date: Wednesday, 27 March 2019 at 02:49
>     > >> To: Hannes Tschofenig <[e-mail]>
>     > >> Cc: "[e-mail]" <[e-mail]>
>     > >> 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
>     > >><[e-mail]> 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
>     > >> [e-mail]
>     > >> https://www.ietf.org/mailman/listinfo/tls
>     > >>
>     > >> _______________________________________________
>     > >> TLS mailing list
>     > >> [e-mail]
>     > >> 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
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/tls
>
>
>