Slashdot Mirror
Code for Unbreakable Quantum Encryption
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.'"
Why go fast when you can go anywhere? O|||||||O
Let's see what DVD Jon has to say about this first...
People really need to quit referring to anything as "unbreakable" or 100% secure. It's never going to happen. Just as making anything idiot proof, they will always build a better idiot. Saying it's unbreakable is just going to challenge someone to do it.
IMAGE VERIFICATION IS EVIL!
I'd like to think that this would be used for something useful like secure financial transactions or transmission of other personal data, but it is disc ouraging to see that TFA focuses on securing video transmissions.
Linux : Hotrod
This message encrypted with rotsqrt(-1).
> how is the key shared with the end terminal?
Come on you Einsteinian caveman! Clearly the sending terminal is quantumly entangled with the receiving terminal, thus providing the key via spooky-action-at-a-distance(tm).
- For the complete works of Shakespeare: cat
My question, however, is this: Once hackers obtain quantum computers themselves to use for cracking quantum codes, will they actually have to run them? After all, it was just proven that a quantum program doesn't even have to run to come up with an answer. That's all we need - a new generation of lazy quantum hackers! What's this world coming to? What happened to good old-fashioned dishonest work?
"A little misunderstanding? Galileo and the Pope had a little misunderstanding."
If it can be decrypted its not unbreakable. Unbreakable encryption is easy, just not that usefull if you ever want access to what you encrytped.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
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?
GetOuttaMySpace - The Anti-Social Network
Nice bit of text going over the key exchange. Dosn't even involve hurting cats.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
That's like giving a DEA agent in Columbia a "bulletproof" vest.
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.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
The article is about quantum encryption, not computing. IIRC, quantum encryption employs the quantum characteristics of photons to make it impossible to eavesdrop on a communication without altering it, thus rendering it uncrackable. Whereas quantum computing employs the overlapping of quantum states of systems in order to provide a kind of natural ability to perform "parallel" computations.
If it weren't for deadlines, nothing would be late.
The idea of quantum cryptography is that you have some form of signal sent both ways that only the receivers can receive, since it can't be tapped in the middle due to detected signal loss and single-atomic-unit transmissions being measured. It's pointless, because anything the actual receiver can do, I can do too, and anything the actual receiver can't do I can't do either.
Eeeehh... Quantum entaglment encryption isn't that simple.
Here is a site by Colossalstorage that explains one of the patents involved in it:
http://colossalstorage.net/entangled.htm
To give a layman's translation... You take two photons and entagle them and then send them down two fiber optic line of the same length (say 4km) and then a device on each end determines which direction the spin is.
Since the spin is the same for the particles regardless of how far apart they are (no information being transfered faster than the speed of light) they have a reference of what the other party is seeing.
Now of course particle spin is random, but the key factor is knowing what the other party is seeing.
Now, you can use the spin as a one time pad and basically encrypt everything based off this... Or rather changes are you'll need another method of communication such as having the actual encrypted data on another fiber line and knowing the spin of the photon gives you the key to unencrypt it.
Now if someone spliced the fiber line, you instantly know it has been comprised because data no longer unencrypts because the particle spin changed on observation and chances are unless the eves dropper has the ability to observe particle spin he might not get much useful data either.
"I am the king of the Romans, and am superior to rules of grammar!"
-Sigismund, Holy Roman Emperor (1368-1437)
So the code is unbreakable. It's also highly susceptible to DOS attacks. As soon as someone attempts to view the photons, they disrupt the key, which will disrupt the transmission of information. In the case of surveillance, I would think that this is as least as useful as being able to watch the stream itself.
The one big vulnerability with OTPs is that you've now got to send the key securely. Since it is equal in size to the message and is only valid for one message, it is equally hard to send the key securely as it is to send the message securely. Because the pad is pure randomness, it is possible (using existing methods) to send the pad by public key encryption, as it is non-trivial for someone intercepting the message to know how to decrypt it, as it's hard to know when you've broken the encryption. One piece of randomness looks much like another.
Generally, though, people take shortcuts. Instead of using a full-sized one-time pad, a much smaller, repeatedly-used pad is used instead, with some form of pseudo-random mangling to churn things up so that it acts in a very similar manner to a one-time pad. This is generally how stream ciphers work.
Quantum Cryptography - if used sensibly - would involve transmitting a gigantic OTP. Far bigger than the one you need. You then drop all of the bytes that are intercepted. The only bytes used in the pad are the ones the intercepting person does NOT have, so you know the pad is free of holes.
A "better" solution would be to not transmit the key at all, but somehow exploit photon teleportation to deliver the key in a secure manner. However, if you could do that, you wouldn't need encryption in the first place.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Well, the point is that your pad can be sent at a time when you have secure communication - such as on an USB drive in face to face contact. Then, you can send the message later at any time without secure communication. It's a method of shifting the moment that messages have to be sent to be a time when you can guarantee security.
The reason you transmit the pad instead of the actual data is that the properties of the system don't prevent evesdropping, they only make it detectable. If you transmitted the actual data over the "secure" stream, someone could still intercept it. You'd know that they intercepted it, but by then it would be too late to do anything about it. However, if you transmit the pad over the secure stream you can know which bits were intercepted prior to encrypting the data and can remove those bits from the pad. NOTE: I see someone already posted something similar after I started posting, but I think this version is a bit easier to understand for someone who isn't used to quantum cryptography.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Its not encryption, but is what is called a hash. Think of it more like a fingerprint of data. If you alter the data then the fingerprint is no longer the same.
/. thread is 2 way encryption, meaning you would determine the original data from the encrypted data.
Now a hash is what would be called one-way encryption. That means from the 'encrypted data' there is _no way whatsoever_ to determine what the original data was. What is being discussed in this
The md5 hash is useful if you want to verify a password without sending the password itself across the line, you can just compare hashes without fear that someone is going to intercept the password itself. It is been proven that 2 datasets can produce the same md5 hash (this is known as a collision). This is why you have run into md5 being used in conjunction with passwords. That being said, as it is a one way encryption, md5 would be of no use whatsoever if you were trying to securely transmit a file, it would only be useful for the person on the other end to determine if the file had been altered in-route.
Hope that helps.
If Alice and Bob are going to do the key exchange thing, what is to stop Eve from stepping into the middle before it begins. Then Alice actually winds up doing a key exchange with Eve and Eve does a corresponding (but different one) with Alice.
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.