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
