Cryptographers achieve perfect secrecy with imperfect devices

Not quite. Classical cryptography of course requires the additional assumption that the computational capacity of the attacker is limited (at least if the amount of key material available is less than the length of the messages to be exchanged). QKD does not need any such computational assumptions. Looking at this purely from a theoretical perspective, I hope you'll agree that the ability to create new shared randomness "out of thin air" by drawing on quantum correlations, and to do so an information-theoretically secure fashion, is a pretty neat trick.

Now, if you asked me how likely it is _in practice_ that $THREE_LETTER_AGENCY has broken your cryptosystem to the point where they can feasibly attack it/have backdoored it, compared to the likelihood that they've bugged your devices in a supply chain attack or found any number of other ways to compromise the practical implementation, I suspect my answer wouldn't be much different to yours. Nevertheless, I still think it is interesting to explore additions to the cryptographer's toolbox that, in a very practical sense, have a rather different profile of assumptions and tradeoffs.

Your general point about QKD "promises" vs. practical IT security is well taken, particularly as I am much more of a general quantum physicist and spare-time compiler/infosec geek than a QKD person myself.

However, note that asymmetric cryptography doesn't really solve the authentication problem you mention either. If you don't want to place your trust in some sort of PKI, you are back to Alice and Bob having to meet first to exchange some sort of key material (e.g. their public keys) to later avoid impersonation. Given an authenticated channel, both QKD and classical public-key cryptography can construct a secure channel for messages of arbitrary length, but the latter only for computationally bounded attackers. Of course, this is not to say that a trusted PKI can't be a sensible assumption in practice.

You probably aren't wrong, but also note that popular science articles are probably not the best basis for judging this. :) A number of people working on QKD have done serious work on classical cryptosystems as well, although the overlap of that set with people working "in the trenches" of practical IT security is of course yet another topic.

> To do the data exchange, it's not encrypted to a key per se […]

I'm not sure whether this is what you are wondering about, but the actual data exchange is completely separate from the key distribution. Particularly for the entanglement-based protocols like used in device-independent scenarios, there isn't really any data exchange between the parties during the key distribution stage at all (apart from the classical post-processing steps such as error correction after the fact). Rather, the quantum resource provides random, but correlated bit strings at the two nodes. Only after the QKD protocol has finished is there actual data exchange using the secret key material, probably using the key as a one-time pad to keep the information-theoretic security guarantees.

Thus, trying to think about these protocols in terms of data transfer doesn't strike me as particularly natural; in fact, if the entangled state shared between Alice and Bob is maximally entangled, the raw bits obtained from the quantum devices are always going to be completely random.

The security proofs are indeed based on careful entropy considerations. You mentioned implementation details of classical cryptosystems. These primitives – S-boxes, etc. – motivate why we should reasonably expect cryptanalysis on such algorithms to be hard in practice, even though we know that they can't be secure considering information theory only. In the QKD case, however, we can make information-theoretic security statements without any reference to computational power. Thus, a security analysis will look at quite a different set of things: on one hand, whether the entropy accounting is correct, and on the other hand, whether the practical implementation actually corresponds to what that accounting assumes.

To the best of my knowledge, multi-party decryption isn't really related to public key cryptography. Sending a message to a single recipient looks like this:

1. You write a message.

2. You encrypt it with a symmetric algorithm.

3. You encrypt the key to the encryption in step (2) with an asymmetric algorithm, using your recipient's public key.

4. You send them the combined message, encrypted ciphertext plus encrypted key-to-the-ciphertext.

5. They use their private key to decrypt the key-to-the-ciphertext.

6. They decrypt the message using the key you just sent them.

It's done that way, as far as I've learned, mostly because symmetric encryption is faster than asymmetric encryption.

But multi-party decryption is exactly the same:

1. You write a message.

2. You encrypt it with a symmetric algorithm.

3. You encrypt the key to the encryption in step (2) using the various public keys associated with each of your intended recipients.

...

So instead of a single-recipient message being a ciphertext accompanied by a header revealing the encryption key to the ciphertext, a ten-recipient message is a ciphertext -- exactly the same ciphertext! -- accompanied by ten headers, each of which is only readable by a particular private key. There's nothing about this method that draws on public key cryptography; if I've exchanged OTP material with each of ten people, I could send a multi-recipient message exactly the same way. (And doing so would be at least as valuable as it is in the public-key case -- doing things that way allows me to send a message of arbitrary length while only consuming a bounded amount of OTP material.)