Code for Unbreakable Quantum Encryption 210
An anonymous reader writes "ITO is running a story on NIST's latest quantum encryption key generation. From the article: 'Raw code for "unbreakable" quantum encryption has been generated at record speed over optical fiber at NIST. The work is a step toward using conventional high-speed networks such as broadband Internet and local-area networks to transmit ultra-secure video for applications such as surveillance.'"
Damn more DRM (Score:2, Interesting)
Comment removed (Score:2, Interesting)
Re:Hold on just a sec... (Score:2, Interesting)
Re:Hold on just a sec... (Score:3, Interesting)
Unbreakable != Useful (Score:2, Interesting)
Re:One time pads are... (Score:1, Interesting)
All the real intelligence agencies that have used one-time pads would probably be surprised to learn they have no practicality. Encryption is not all about turning big secrets into small secrets, its all about communicating valuable secrets while preventing unwanted spread of the secrets. Reducing the problem of exchanging big secrets to exchanging small secrets that unlock the bigger secrets so that the latter can be safely sent where they can be seen by all without being intelligible is a means, not the ends, of encryption. A better description of the general problem avoids the focus on size, and says that encryption is all about eliminating vulnerabilities in the exchange of secrets. OTP's eliminate analytical attacks on the message ideally, but suck in most other ways. Quantum encryption eliminates covert interception of the message, but do little in any other way.
One-time pads aren't optimal solutions in any general sense. They are narrowly optimal in that the transmission containing the valuable secret cannot be broken without the key (the pad), since, implemented properly, every possible message of the given length is an equally likely decryption, and there is no way to narrow it down, even knowing what part of the message is. So they are optimal in that sense.
On the other hand, they require secure advance exchange of a large (but, independently, not valuable) secret before hand, which must be protected lest it be combined later with the valuable secret to unlock it. This doesn't give them "no practicality", it means that they are useful in particular cases, but not in others.
Similarly, quantum encryption, which is perfectly immune to man-in-the-middle attacks, but has lots of its own problems. You can't, for instance, store a quantum-encrypted message practically, so it has to be encrypted by some other system as well if it is going to be stored securely at the receiving end, and it's real security even against interception en route will be determined by the other encryption scheme, not the quantum scheme, since all quantum encryption guarantees is that you can't intercept the message without interfering with the intended receiver getting it, and therefore your interception will be detected.
Re:Man in the Middle (Score:3, Interesting)
Keep in mind that Eve's (let's call her Mallory, M) key must be different. A's key is random, and there's no way to forcably regenerate A's states given B's intended reception.
So instead of sending the OTP you want to use for the message, send more. Let's send three times the amount, in fact. We'll use one third for the message (once it's verified secure), and one third to verify the key. The other third I'll explain in a bit.
Note that each of those thirds is independent, but if you have one third, you have all thirds. So you send this OTP, and then A establishes communications with B via a different channel. Doesn't have to be secure. Just has to be definitely with B. This includes physically going to B's location (I guess I'm assuming that M can't physically clone and replace B and somehow convince A that M's in B's location...).
Now, once that's done: so B definitely has a copy of A's OTP. Included in that OTP is one third that won't be used for anything - A uses this in the next OTP transmission to insert keyed states - that is, instead of a completely random string, there are 1s and 0s in places that are determined by the previous OTP. M can't know this - she doesn't have the previous OTP. And she can't recognize anything's wrong until the entire key's transmitted and she does a frequency analysis and realize that it doesn't look entirely random.
The problem was that she attempted to send the OTP to B without knowing about those positions. So she sent random noise in those locations. So now B knows that M isn't A, and the attack fails.
The one-third OTP can continue to be used in future exchanges to verify that A is A and B is B.
That sort of thing could be done with a normal OTP exchange too, I think. The main benefit is the initial exchange, where you know that if your recipient has one third of the key - or really, any part - they, and only they - have the whole thing.
Which is why 'physically going there' is probably unnecessary. It doesn't matter if someone wiretaps the phone hearing the verification OTP. That doesn't help them at all. The only thing 'physically going there' prevents is a universal man-in-the-middle attack.