4 ms·
Just want to point out that the article specifically says to use an authenticated KEM (AKEM). A normal, unauthenticated KEM would not work as it provides no aut
by nmadden 2y ago
Just want to point out that the article specifically says to use an authenticated KEM (AKEM). A normal, unauthenticated KEM would not work as it provides no authentication. There are no post-quantum authenticated KEMs as yet.
- namibj 2y agoThere are post quantum KEMs though that authenticate with a classical mechanism, which limits quantum attacks to interactive from the previous total breakage of recorded ciphertext exchanges (e.g. Wireshark capture at a router encountered in both directions of the traffic flow).
- nmadden 2y agoAre there? I’ve advocated for such constructions in the past, but I’ve never seen an actual proposal. Do you have a link?
- namibj 2y agoGoogle's post-quantum TLS experiments that were done in public via Android Chrome are such; basically you just do normal TLS handshake but stack the key derivation from the traditional DH-type perfect-forward-secrecy exchange with a post-quantum-perfect-forward-secrecy exchange that you all seal under the same handshake authentication, and where you make sure to only use post quantum symmetric primitives to fuse the traditional session key material with the PQ session key material such that you don't rely on either one's resistance to keep your secrets secret. Sorry I don't have a link quite on hand right now.
- nmadden 2y agoOK, sure. As far as I’m aware, nobody’s actually made that into an actual AKEM proposal though. (I wish they would, as I think many applications would be fine with pre-quantum authentication and post-quantum confidentiality).