Jun Hu (Nokia) <[email protected]> wrote: > [HJ] sure, but my understanding is the attack we are discussing here > doesn't rely on a CRQC
It does.
The attacker is able to remove the quantum-safe algorithms from the proposal,
leaving the communication using quanutm-unsafe algorithms.
The document lists these conditions:
3. The attacker must either has a long-term authentication key for
one of the peers or must be able to break authentication
algorithm used by one of the peers in real time.
Perhaps there are algorithms which can be broken in real time without a CRQC,
but if so, they were broken awhile ago, and aren't in use.
Valery's proposal to have both ends sign both series of messages, rather than
just their own is reasonable to me. It's an improvement, but it's also a
significant change.
It's subject to it's *own* downgrade attack, where the CRQC-enabled
attacker removes this new Notify :-) so we have to lock that down by policy.
The assumption is that it is easier to do that than to lock the policy down
to insist on a hybrid or quantum-safe algorithm.
> Jun Hu \(Nokia\) <[email protected]> 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 <[email protected]> . o O ( IPv6 IøT consulting
> ) Sandelman Software Works Inc, Ottawa and Worldwide
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
