Hi Peter,
We discussed this among the [DOWLING] authors; Douglas asked me to chime
in here as he's offline the next couple of days.
It is indeed true that the PRF-ODH assumption, as stated in [DOWLING]
and https://ia.cr/2017/517, wouldn't be compatible when using the
x-coordinate only, or with clamping. One needs to be a little bit more
careful in these cases, disallowing the PRF-ODH adversary to make
queries on trivially colliding points (e.g., by flipping signs, or
adding small-order points).
This has been done for example in a paper about the security of
Bluetooth by Fischlin (co-author of [DOWLING]) and Sanina [
https://ia.cr/2021/1597 ], where the x-coordinate is also used to derive
keys. There, they adapted the PRF-ODH definition accordingly (Section
4.1). We don't think that this makes the assumption less plausible, only
a bit more tedious to define and deal with in the proofs.
Concretely for TLS 1.3, the reduction to sn-PRF-ODH for Theorem 5.2 in
Game B.2 would perform the relevant collision checks upon a modified
g^v' received by the partner session, and use the same uniform random
string as in the test session for such collisions. (The session hash in
later key derivation steps still ensures they'll derive independent keys.)
This matches the PRF-ODH assumption with the restricted modifications as
mentioned above; the TLS proof then goes through as before.
As for the PQ3 protocol also brought up in this, from a
quick glance similar arguments seem to apply: the PRF-ODH reductions
already check whether "the same V" is received, hence the collision
check can be added there, too.
Hope this helps to clarify. We plan to update the eprint version
https://ia.cr/2020/1044 of [DOWLING] accordingly. Let us know if you
need more details.
Best,
Felix (with Ben, Douglas, Marc)
On 2024-07-26 00:19 +0200, Peter C
<Peter.C=40ncsc.gov...@dmarc.ietf.org> wrote:
Douglas,
It's not exactly due to the point formats, at least for X25519. The RFC 7748
security considerations highlight that "for each public key, there are several
publicly computable public keys that are equivalent to it, i.e., they produce
the same shared secrets". Assuming the early secret doesn't change, this
means equivalent public keys will produce the same handshake secrets and
the same master secrets. The transcript hash does give you different
handshake traffic secrets and application traffic secrets, but I think that's
too
late in the key schedule for [DOWLING].
The proof in [DOWLING] only aims to prove that the handshake traffic secrets
and application traffic secrets are secure, not that the handshake secrets and
master secrets are secure, so for that purpose it should be okay that the
transcript hash is incorporated a little later in the key schedule.
Sorry, I only meant that in Theorem 5.2 the dual-snPRF-ODH assumption is used
in Game B.2 to replace the handshake secret with a uniformly random value which
then allows the handshake traffic secrets to be replaced with uniformly random
values in Game B.3 using the PRF assumption on HKDF.Expand and the fact that
the labels are distinct. Equivalent public keys mean that the handshake secret
is not indistinguishable from random and the proof fails at Game B.2. The
distinct
labels in Game B.3 only imply that the handshake traffic secrets will be
different,
not that they are indistinguishable.
Peter
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
