Quick Test for whether you need a quantum random number generator:
1. Write down a random number on a piece of paper (9 digits should do).
2. Set the paper on fire, capturing the smoke and ashes.
3. Hand the smoke and ashes to the person trying to sell you the quantum random number generator.
4. Ask them to tell you your number. Be careful to allow only 1-4 guesses, otherwise you need more digits.
5. If they can tell you your number, buy the quantum random number generator. If they can't, don't.
@sophieschmieg This is all fine, but it seems like there is a much larger market for quantum key distribution nodes. What is your test for those?
@paulehoffman can your little black box that needs to be distributed to both endpoints beat my little black box which is actually just a 5 TB hard drive filled with random numbers?
@sophieschmieg @paulehoffman
Curious, do you have an ELI5 explanation against a QKD setup for more than a pair of nodes?
NIST's arguments against QKD are concise and fine (overall complexity, huuuuge attack surface, ..) but they usually require some time to explain..
@icrawler @paulehoffman afaik you can't do QKD with more than two nodes. At least not if you, like me, like end to end encryption. Or at least not decryption at somewhat dubiously trusted Middleware.
@sophieschmieg @paulehoffman
Yes, you're right, sorry for my loose wording: strict QKD (like in BB84) is a two-party thing (I remember seeing some papers about quantum key agreement on groups, but never heard them being implemented).
I asked about systems with decryption of a minted key by the mentioned middleware ;) (thus huge attack surface) with compensating controls in form of some other -- PQC or classic symmetric -- crypto (thus complexity due to such "hybrid" -- as on Soatok's blog -- crypto construction)
@icrawler @paulehoffman yeah, I consider such proposals kind of non sensical.