Signature-free PQ IKE from an authenticated forward-secure KEM, with ROM/QROM proofs and state-exposure resistance.
3 comments
What does the proof model say about state rollback or cloning, if the forward-secure KEM state gets snapshotted and restored on a box that handles multiple IKE handshakes in parallel?
Also, what is the concrete cost per handshake versus a vanilla PQ IKE with Dilithium or Falcon in the auth slot, especially once you account for rekeying and whatever state update/Ops burden the scheme adds?
The usual forward-secure proof only buys you exposure of the current secret state, not magic against an attacker restoring an old snapshot, so cloning a box can replay the same KEM state unless the implementation has some monotonic counter or remote state anchor. In practice that is the annoying bit with stateful PQ schemes, the crypto can be fine and the ops story still collapses if the process can be forked or rolled back.
On cost, you are trading a signature check on every handshake for extra state management plus periodic rekeying, so the raw handshake CPU can be lower than Dilithium or Falcon in the auth slot, but the operational overhead is not free and it depends a lot on how often the authenticated KEM state has to be refreshed.
IKE has always had a weird split between the key exchange and the authentication machinery, most deployments glued that together with signatures and a pile of certificate logic.
If this really lets you drop that layer while still keeping PFS and PQ security, it matters less for the proof aesthetics and more because the attack surface in real VPN stacks is usually all the plumbing around the crypto, not the KEM itself.