Hi Jun, you're correct ... the attack isn't specific to PQ. It takes advantage of the presence of a weak key exchange method, regardless of whether the attacker uses a CRQC to break it.
But to answer your earlier question, the attack doesn't require re-signing the IKE_AUTH message from Y. The exact steps of the attack are: 1. X sends initiator IKE_INIT_SA to A 2. A rewrites initiator IKE_INIT_SA by dropping support for the strong key exchange and sends it to Y 3. Y sends responder IKE_INIT_SA to A 4. A sends (unmodified) responder IKE_INIT_SA to X 5. X sends initiator IKE_AUTH to A 6. A decrypts IKE_AUTH (by breaking the weak key exchange), signs it with A's key, re-encrypts it, and sends it to Y 7. Y sends responder IKE_AUTH to A 8. A sends (unmodified) responder IKE_AUTH to X Here's the key: the victim responder Y only signs its own outbound messages, so even though X and Y have a split view of the handshake transcript, they never actually confirm this. Y would have sent the same IKE_AUTH in its conversation with A as it would have in its conversation with X. Chris P. On Wed, Jul 30, 2025 at 2:09 PM Jun Hu (Nokia) <jun...@nokia.com> wrote: > Sorry, I need rephrase that, the attack doesn't rely on a CRQC could break > a digital signature in live communication > > -----Original Message----- > From: Jun Hu (Nokia) > Sent: Wednesday, July 30, 2025 11:08 AM > To: Michael Richardson <mcr+i...@sandelman.ca> > Cc: Valery Smyslov <smyslov.i...@gmail.com>; 'Christopher Patton' < > cpat...@cloudflare.com>; 'Scott Fluhrer (sfluhrer)' <sfluh...@cisco.com>; > 'ipsec' <ipsec@ietf.org> > Subject: RE: [IPsec] Re: draft-smyslov-ipsecme-ikev2-downgrade-prevention > > [HJ] sure, but my understanding is the attack we are discussing here > doesn't rely on a CRQC > > Jun Hu \(Nokia\) <jun.hu=40nokia....@dmarc.ietf.org> wrote: > > So if A just passthrough Y's certificate payload to X in the IKE_AUTH > > response A sent to X, how could A signs the AUTH payload without > having > > Y's private key that corresponds to Y's certificate? > > The CRQC was able to break the quantum-unsafe algorithm, turning a public > key into a private key. > (That's the point of the CRQC) > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > >
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
