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

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 <stefan@aaa-sec.com> 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
> CFRG@irtf.org
> https://mailman.irtf.org/mailman/listinfo/cfrg