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.'"
Buzzwords and Challenges. (Score:2, Insightful)
Re:Buzzwords and Challenges. (Score:2, Insightful)
Re:Hold on just a sec... (Score:1, Insightful)
Change to "near" Unbreakable. (Score:3, Insightful)
Physics 101 (Score:3, Insightful)
Ok, maybe I missed something back when I took QM in college, but photons are the only particle of light, aren't they? They are not the only electromagentic particle, but are the only constituents of the light we see. Or has the universe become even stranger and no one told me?
"unbreakable"? (Score:3, Insightful)
from the article (Score:2, Insightful)
What about the noise of some of the photons being lost (absorption)? The system has to be stable against it. Ergo, one can hide herself under the noise threshold.
PS. It has been 20 years since my quantum mechanics exams.
Re:Change to "near" Unbreakable. (Score:4, Insightful)
Insider attacks (mole, rootkit, spy camera, etc) which occur AFTER reception and decryption do not count, because the encryption method has nothing to do with that.
Re:One time pads are... (Score:3, Insightful)
Re:Actual transmission? (Score:3, Insightful)
Re:Change to "near" Unbreakable. (Score:5, Insightful)
Which is exactly why this is a solution looking for a problem. No one ever breaks modern crypto when it's used correctly. Attacking the periphery of the system is orders of magnitude easier. Your resources are much better spent guarding against insider attacks than buying the next useless whiz-bang crypto device.
Re:Unbreakable != Useful (Score:3, Insightful)
Re:Change to "near" Unbreakable. (Score:2, Insightful)
It's not "souped-up OTP" it's just regular old OTP with a wrapper that prevents a man-in-the-middle attack. As stated in TFA: This is just a system for transmitting an arbitrary-length string of bits with absolute integrity. This is both non-revolutionary and non-trivial.
How messed up our heads are... (Score:2, Insightful)
Surveillance, on us. Unbreakable, uncrackable without detection, so our paranoia-clamped citizenry can rest easy that our boss and our government can surveil anyone they like without fear of having some third party, such as a lawyer, see what they are watching.
Mind-boggling. A pro-authoritarian mindset slipped in so easily.
It's unbreakable, so you break something else. (Score:1, Insightful)
This application of QM allows you to exchange data where the laws of physics themselves guarantee that no one but God could eavesdrop on the data in transit without you knowing about it. So they *can* eavesdrop, you'll just know if they do. They can also steal the data before or after it is transmitted (e.g. NSA has the hardware secretly cache all keys sent over it for later recovery, or whatever). The endpoint computers probably aren't unbreakable, although they may be very close if they're made by the NSA or someone. And if you're getting hardware like this, you *ought* to have a good admin, but I digress.
Okay, so you have this super-ultra good link where you can send data and *know* that no one intercepted it. What now? Well, you have a few options:
A) Send one-time pad data. This encryption method is perfect--EVERY plaintext of the proper length is a possible decryption of any given ciphertext. And you would be padding the length, anyhow. So long as you use a good random source for the pad's data, you'll be fine. Of course, if you use a random source that's somehow deficient, well... Note that it would be good practice to compress (i.e. zip, 7z, rar, whatever) the data before sending it to increase its entropy. Doing this is good for many reasons and is pretty much always helpful when encrypting things.
B) Send keys. You can send secret keys and use your favorite normal cipher. Because you know if someone was eavesdropping (and can discard any keys they eavesdropped upon), you will know that the key is secret (unless, of course, an endpoint is compromised). Now, so long as you're using a good cipher here, you'll be fine. Of course, if your cipher is deficient here, you're hosed. One good thing about this is that you can keep making new secret keys, to limit how much damage it does if an adversary breaks your cipher. This is a very helpful thing to do because some attacks require a lot of ciphertext, and you're not putting out all that much ciphertext for them to use to recover your key if the key changes for each message. Suddenly they have a lot of crumbs, when they need a large block, all encrypted with the same key(s).
C) A little of each. There may be reasons to do both. Maybe you want to send short text messages or small files and these can all be done via a true one time pad, but the large files are more efficient to do via some stream cipher. After all, with a stream cipher you only have to transmit file + a relatively small key, whereas a true OTP requires you to send 2 * file worth of data, the first being the OTP, and the second being file [xor] OTP. And that's neglecting overhead, of course. Normally, you want to do a number of things I'm neglecting here to avoid misc. side channel attacks that could reveal things like how large a message you're sending, *that* you're currently sending a message, etc., which can all leak information.
After all, if you know that A is asking B whether or not A should do something (which you know via other means) and you saw A transfer the ciphertext ^s@ or possibly ÿÿ it wouldn't take a genius to figure out that one was yes and the other was no with or without an OTP
Re:Hold on just a sec... (Score:3, Insightful)
But seriously, what would stop someone intercepting the key, then resending it? If the original transmitter can send the key, and the receiver can receive it, why can't a repeater-station type device in the middle read the key, then send out a new duplicate?