[prev in list] [next in list] [prev in thread] [next in thread]
List: cfrg
Subject: Re: [CFRG] Does OPRF/OPAQUE require full implementation of RFC 9380
From: Jack Grigg <ietf () jackgrigg ! com>
Date: 2024-03-30 20:01:43
Message-ID: CAPC=aNUSTv=JtpkG71vhu25jgpVqzL5XS81543ntLMUuXcchqw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi all,
On Sat, Mar 30, 2024 at 6:56 AM Stefan Santesson <stefan@aaa-sec.com> wrote:
> Section 2.1 in OPR (RFC 9497) states:
>
> "HashToGroup(x): Deterministically maps an array of bytes x to an element
> of Group. The map must ensure that, for any adversary receiving R =
> HashToGroup(x), it is computationally difficult to reverse the mapping."
> [..]
>
> It continues to say that "Security properties of this function are
> described in [RFC9380]".
> [..]
>
> I would really appreciate help. Has this been discussed already to any
> detail. Is there any guidance available?
>
As Mike Hamburg alludes to in another message in this thread, the security
property of HashToGroup relied upon here is that the output of the function
must be a uniformly random element of the group, with no easily-determined
relation to any canonical generator of the group (more precisely,
HashToGroup should be indifferentiable from a random oracle; see Sections
2.2.3 and 10.1 of RFC 9380). The proposed approach in your email makes
inputScalar a known quantity, which directly breaks this property
(inputScalar is the easily-determined relation to the canonical generator,
because outputElement = [inputScalar] G).
Regardless of RFC 9497 using "must" instead of "MUST" when describing it,
its reliance on this security property is clear; see Sections 2.1, 4.6, and
7.2.1 of RFC 9497 for further details.
> If this is not good enough. Can you take any simpler path than full RFC
> 9380 implementation?
>
If you use ristretto255 or decaf448, then most of the work should already
be done by the libraries implementing the group (see below). See Section
4.1 of RFC 9497 for an OPRF ciphersuite instantiated over ristretto255 and
SHA-512.
For other groups (such as elliptic curves), there are other approaches like
"try-and-increment", but these are not constant-time and may have other
side-channel vulnerabilities in your setting; you would need to consult a
cryptographer.
On Sat, Mar 30, 2024 at 7:37 AM stef <f3o09vld@ctrlc.hu> wrote:
> 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).
>
Just to clarify here for wider benefit: RFC 9496 (which specifies
ristretto255, as well as decaf448) includes an Element Derivation function
(in Section 4.3.4), which when paired with a hash function can be used to
build a hash-to-group operation (which I believe is what library functions
like crypto_core_ristretto255_from_hash in libsodium provide). Appendix B
of RFC 9380 documents precisely how this should be done to be compatible
with it (specifically using an expand_message function that conforms to
Section 5.3 of RFC 9380).
Cheers,
Jack
[Attachment #5 (text/html)]
<div dir="ltr"><div>Hi all,</div><div><br></div><div><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Sat, Mar 30, 2024 at 6:56 AM Stefan Santesson \
<<a href="mailto:stefan@aaa-sec.com">stefan@aaa-sec.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>Section 2.1 in OPR (RFC 9497) states:
<p>"HashToGroup(x): Deterministically maps an array of bytes x to
an element of Group. The map must ensure that, for any adversary
receiving R = HashToGroup(x), it is computationally difficult to
reverse the mapping."</p>[..]<p>It continues to say that "Security \
properties of this function are described in [RFC9380]". <br>
</p>[..]<br><p>I would really appreciate help. Has this been discussed already
to any detail. Is there any guidance available?</p></div></blockquote><div>As \
Mike Hamburg alludes to in another message in this thread, the security property of \
HashToGroup relied upon here is that the output of the function must be a uniformly \
random element of the group, with no easily-determined relation to any canonical \
generator of the group (more precisely, HashToGroup should be indifferentiable from \
a random oracle; see Sections 2.2.3 and 10.1 of RFC 9380). The proposed approach in \
your email makes inputScalar a known quantity, which directly breaks this property \
(inputScalar is the easily-determined relation to the canonical generator, because \
outputElement = [inputScalar] G).</div><div><br></div><div>Regardless of RFC 9497 \
using "must" instead of "MUST" when describing it, its reliance \
on this security property is clear; see Sections 2.1, 4.6, and 7.2.1 of RFC 9497 for \
further details.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> <p>If this is \
not good enough. Can you take any simpler path than full RFC 9380 \
implementation?</p></div></blockquote><div>If you use ristretto255 or decaf448, then \
most of the work should already be done by the libraries implementing the group (see \
below). See Section 4.1 of RFC 9497 for an OPRF ciphersuite instantiated over \
ristretto255 and SHA-512.<br></div><div><br></div><div>For other groups (such as \
elliptic curves), there are other approaches like "try-and-increment", but \
these are not constant-time and may have other side-channel vulnerabilities in your \
setting; you would need to consult a cryptographer.</div></div></div><div \
dir="ltr"><br></div><div dir="ltr">On Sat, Mar 30, 2024 at 7:37 AM stef <<a \
href="mailto:f3o09vld@ctrlc.hu">f3o09vld@ctrlc.hu</a>> wrote: <br></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> tbh i also think this \
is overkill since for some groups, like ristretto255 for<br> example there is a \
widely used hashtogroup available in most big<br> implementations (like \
crypto_scalarmult_ed25519 and<br> crypto_core_ristretto255_from_hash in \
libsodium).<br></blockquote><div> </div><div>Just to clarify here for wider benefit: \
RFC 9496 (which specifies ristretto255, as well as decaf448) includes an Element \
Derivation function (in Section 4.3.4), which when paired with a hash function can be \
used to build a hash-to-group operation (which I believe is what library functions \
like crypto_core_ristretto255_from_hash in libsodium provide). Appendix B of RFC 9380 \
documents precisely how this should be done to be compatible with it (specifically \
using an expand_message function that conforms to Section 5.3 of RFC \
9380).</div><div><br></div><div>Cheers,</div><div>Jack<br></div></div></div>
_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://mailman.irtf.org/mailman/listinfo/cfrg
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic