3 ms·
> With QKD you only have to trust that the person you want to talk to is on the other side of the quantum link you've established To trust that (without PKI),
by bsza 5y ago
> With QKD you only have to trust that the person you want to talk to is on the other side of the quantum link you've established
To trust that (without PKI), you have to meet your peer in person, don't you? If so, at that point you can just hand an HSM to them with your symmetric key on it. No need to use a quantum device.
- dandanua 5y agoYes, but what if you want to generate a new secret key? You can encrypt it and send through a channel. But, in theory, an eavesdropper can capture it and decrypt at some point in future. In QKD an eavesdropper is absolutely helpless, he can't capture traffic at all (it will be ruined otherwise).
- bsza 5y agoBut the same applies to the messages themselves, no? QKD is only for key exchange, so I assume the resulting keys themselves are just random (non-quantum) bits of data, and the encrypted messages are sent through plain old TCP/IP. If a message is intercepted, the same tactics of waiting until the encryption is no longer secure could work.
- dandanua 5y agoI thought about the scenario when some old secret key is revealed. Sure, you can decrypt old messages with it if they were transmitted classically. But in a classical channel if you're capturing all the traffic then you can derive the current secret key and decrypt current messages as well. This is not possible in a quantum case.
- bsza 5y agoWhat if you store a large number of keys on the module right from the start, and get all the new keys from that list. That way the key switch message only needs to contain the index of the new key. Even better, store a huge random seed and generate all subsequent keys from that. Then you can also change key size and algorithm as needed without ever having to meet your contact in person again.
- cryptonector 5y agoNot just a symmetric key, but probably also ECDH and RSA keys.