[amluto]

In my opinion, QKD (implemented correctly) performs key exchange, basically like Diffie-Hellman except that it’s secure even against an adversary with unlimited computing power. If I had a quantum computer and a quantum network anyway, may I’d use it, but probably not with Wegman-Carter. If not, I wouldn’t.

(BB84 is from 1984. The terminology was different, and the understanding of what mattered in cryptography was different.)

[mswphd]

BB84 (and QKD overall) requires authenticated channels. You have to get those somewhere. You can get them from an information-theoretically secure MAC, but it has significant downsides. You can get them with computationally secure primitives, but then there's no point in using QKD in the first place. You cannot instantiate QKD securely without one of those two choices though.

[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.)