[amluto]

> You can get them with computationally secure primitives, but then there's no point in using QKD in the first place.

I don’t entirely agree. You can build a computationally secure authenticated channel using symmetric primitives (e.g. hashes) that are very, very likely to survive for a long time. And you can build comparably secure asymmetric authentication schemes from the same primitives (hash-based signatures are a thing).

But to build a classical key exchange system, you need more exotic primitives (Diffie-Hellman or public-key encryption / KEM schemes), and the primitives of this sort that are supposedly post-quantum secure have not been studied for nearly as long and have much more structure that might make them attackable.

Not to mention that attacking the authenticated channel in QKD cannot give a store-now-decrypt-later attack.

[fsh]

At that point you can just pre-share a key and use AES.

[amluto]

Nope -- that gives neither public-key capabilities nor forward secrecy.

[maqp]

The point is there is no public key capability in BB84 that requires pre-sharing a symmetric key.

You absolutely do get forward secrecy with pre-shared keys. You just need to make the protocol derive the next key with a cryptographic hash function, and deliver the iteration count with the packet so the recipient knows which key is the correct one. This is called a SCMIP or hash ratchet, and it's used e.g. in Signal protocol.

(As implementation details, you'll also want to hash the hash ratchet counter with the key to prevent theoretical loops, and you'll probably want to encrypt the ratchet counter during delivery with static header key, or the very least authenticate it.)