Hi Peter,
If your question is about what assumption the PQ KEM you still need to
make in case it's not IND-CCA secure anymore and you want to fall back
to [DOWLING] for the (EC)DH result, I think the answer is: none.
(Beyond ensuring unambiguous encoding of KDF inputs, as the draft
mandates through fixed-length shared secrets etc.)
You would then be treating HKDF.Extract as a random oracle (which for
PRF-ODH security is the take-away from [ https://ia.cr/2017/517 ]),
where the IKM input is augmented with the (possibly
adversary-controlled) KEM shared secret. But the encoding would ensure
that the argument wrt. ECDH would still apply.
Cheers,
Felix
PS: Sorry for the prior double posting; we were under the impression
that Marc's first email didn't get delivered to the list.
On 2024-08-01 11:38 +0200, Peter C <pete...@ncsc.gov.uk> wrote:
Marc and Felix,
Thank you both for your replies.
I can see how this will work for NIST P-256 and X25519 - it is
straightforward to detect the equivalent public and adjust the
output of the simulator accordingly - and I also agree that it is
not a significant change to the PRF-ODH assumption.
Have you thought how this transfers across to the hybrid key
exchange in draft-ietf-tls-hybrid-design? Do you know what
assumption, if any, you need to make on the PQ KEM to be
able to reuse the argument in [DOWLING]?
Thanks,
Peter
-----Original Message-----
From: Marc Fischlin <marc.fisch...@tu-darmstadt.de>
Sent: Monday, July 29, 2024 4:40 PM
To: tls@ietf.org
Subject: [TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt
[You don't often get email from marc.fisch...@tu-darmstadt.de. Learn why
this is important at https://aka.ms/LearnAboutSenderIdentification ]
Dear all,
Douglas and the other "TLS co-authors" discussed this briefly, but I
think that Douglas is offline for the next couple of days and asked me
if I could answer on behalf of the authors.
It is indeed true that the PRF-ODH assumption, as stated, wouldn't be
comaptible with the usage of the x-coordinate. One needs to be a little
bit more careful in this case, disallowing the adversary to flip signs
of curve points. This has been done for example in a paper about the
security of Bluetooth which I co-authored, where the x-coordinate is
also used to derive keys. There we adapted the definition accordingly
(Section 4.1 in https://eprint.iacr.org/2021/1597.pdf of this Asiacrypt
2021 paper). I don't think that this makes the assumption less
plausible, only more annoying to deal with in the proofs.
We have also checked that with the modifcation above the TLS proofs goes
through as before, one only needs to repeat the extracted key in
executions which have the same x-coordinate (instead of the same DH
values as so far).
Hope this helps to clarify. Let me know if you need more details.
Marc Fischlin
_______________________________________________
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
