Re: [CFRG] Does OPRF/OPAQUE require full implementation of RFC 9380

[Sander Dijkhuis <[e-mail]>]

Hej Stefan,

In case you’re also looking for a small JVM implementation based on BouncyCastle: I started drafting one in https://github.com/sander/hashtocurve-kotlin?tab=readme-ov-file" rel="nofollow">https://github.com/sander/hashtocurve-kotlin some months ago for wallet prototyping. In Kotlin for conciseness but should be easy to reuse/rewrite in Java.

We’ll likely need one in production soon as well. I would be interested in collaborating on an easily testable and maintainable pure Java+BC version since I couldn’t find one back then.

I arrived at the same conclusion as Mike for this problem. But note that given the application domain involving network I/O, local timing side-channel attacks may be less important so you may want to consider the try-and-increment approach to HashToGroup also if that’s easier.

Op 30 mrt 2024 om 16:19 heeft Mike Hamburg <[e-mail]> het volgende geschreven:

Hi Stefan,

I haven’t studied OPRF/OPAQUE in detail.  But I believe that yes, it is critically important to implement it using hashToGroup(x) rather than as g^hashToScalar(x).  If it were g^hashToScalar(x), and the server’s secret were k, then the OPRF protocol would output

h := g^(k * hashToScalar(x))

which would then be hashed again client-side.  But having received this value, a malicious client could calculate the value h’ corresponding to another password x’, as:

h’ = h^(hashToScalar(x’) / hashToScalar(x)).

If I am reading the protocol correctly, this would allow the malicious client to brute-force the password, since the client’s first message is not otherwise bound to a specific password, but the server’s response includes enough information to check a guess.  Constructing the OPRF using hashToGroup instead prevents this attack, because finding

hashToGroup(x')^k

from

hashToGroup(x), hashToGroup(x)^k

ought to be hard, because hashToGroup’s output should look unstructured.  If its output were truly random (i.e. in the random oracle model), this would be a computational Diffie-Hellman (CDH) problem, or rather a one-more-CDH because a client could try to connect several times.

Regards,
— Mike

On Mar 30, 2024, at 10:53 AM, Stefan Santesson <[e-mail]> wrote:

Hey,

Thanks a lot for the answers.

Right now I'm more interested in the security analysis than interop. So right now I'm mostly interested if there is a distinct and important security requirement to implement hashToGroup a´la RFC 9380, of if a simpler approach as the one I showed would do the job. And if not, why?

Regarding library support I haven't found any libraries implementing P-256 OPRF in the platforms I'm looking for which is mobile development, Java and Python.

Where can I find all current implementations of OPRF/OPAQUE, and in particular hathToGroup and hashToScalar ?

/Stefan

On 2024-03-30 13:24, stef wrote:

hey, Stefan.

On Sat, Mar 30, 2024 at 12:56:10PM +0100, Stefan Santesson wrote:

Note that there are not even a "MUST" expressed here. Just a "must" and

therefore not a requirement according to section 1.1.

nothing really is a must, but if you don't implement the hashtogroup as per

the rfc you will not be able to satisfy the test vectors, and if you don't

satisfy the test vectors it is difficult to claim compliance with the rfc. and

also compatibility with all the other implementations. if that is ok with you,

you should be doing whatever you want.

tbh i also think this is overkill since for some groups, like ristretto255 for

example there is a widely used hashtogroup available in most big

implementations (like crypto_scalarmult_ed25519 and

crypto_core_ristretto255_from_hash in libsodium). but i do understand that for

other curves this might be more involved, and seems to be also problematic as

- afaik - there has been for 20 years attempts made at defining a hashtogroup

that applies to all widely used - standardized - groups be it curves or dlog...

Finally, is there any support for G.hashToGroup being planned in any major

libraries supporting OPRF/OPAQUE?

i don't quite understand what you mean with "being planned", as as far as i

know all of the implementations that satisfy the test vectors have this

implemented, and liboprf

https://rad.ctrlc.hu/nodes/rad.ctrlc.hu/rad:z3P9keM4KFAMp8wZuULi71VS7cWwp/tree/src/oprf.h#L105

exports this also via the .h file. i suppose all others conforming to

testvectors do so too.

greets,

stefan

_______________________________________________

CFRG mailing list

[e-mail]

https://mailman.irtf.org/mailman/listinfo/cfrg

_______________________________________________
CFRG mailing list
[e-mail]
https://mailman.irtf.org/mailman/listinfo/cfrg