Re: [TLS] Elliptic Curve J-PAKE

On Wed, Mar 27, 2019 at 11:36 PM Feng Hao <feng.hao@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" <watsonbladd@gmail.com> wrote:
>
> >On Wed, Mar 27, 2019 at 7:56 PM Feng Hao <feng.hao@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-bounces@ietf.org> on behalf of Hugo Krawczyk
> >><hugo@ee.technion.ac.il>
> >> Date: Wednesday, 27 March 2019 at 02:49
> >> To: Hannes Tschofenig <Hannes.Tschofenig@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.Tschofenig@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.