Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That to me seems like the coolest possibility.

Encryption that breaks if someone other than the authorized parties observes it. Something which isn't possible with "traditional" encryption.



Yes, this is pretty much the basis to quantum key distribution protocols, and probably one of the first studied uses of quantum information in general. Consider BB84 (http://www.cse.wustl.edu/~jain/cse571-07/ftp/quantum/, https://en.wikipedia.org/wiki/BB84, apparently the first quantum cryptography protocol), which would allow the transmission of a one time pad with an any eavesdropper being unnoticed with provably exponentially decreasing probability in terms of key length. The one time pad can then be used to securely transmit data.

Thus it is possible to transmit arbitrary (classical) data with exponentially decreasing probability that we do not detect an eavesdropper. Alice and Bob can communicate with each other knowing that there is provably pretty much no chance that anyone else knows what they said to each other.


> Encryption that breaks if someone other than the authorized parties observes it. Something which isn't possible with "traditional" encryption.

As stated, this isn't possible with encryption enabled by quantum key exchange, either, nor is it an intended goal of the procedure. Quantum key exchange empowers integrity in the cryptographic key exchange process, but it doesn't intrinsically do anything to empower confidentiality (encryption) or authentication. If you successfully share a key with another party using a channel established via quantum entanglement, you will be (theoretically) capable of discerning with certainty whether or not there has been an attempt to record the key "outside" the channel.

The quantum innovation ceases once the key has been successfully shared. The ciphertexts encrypted with a key shared via quantum key exchange are just like ciphertexts encrypted with a key shared via traditional key exchange. They will not "break" if observed by an unauthorized party; in fact, there is no way to endow a ciphertext with that property. Either a party has the correct key or the don't, but the ciphertext will not "self-destruct" or cease to become usable if the incorrect key is used.

I feel this is an important nit to pick because even if you understand this, others reading your comment might not. Conceptually speaking, assurance of secure channel integrity is very different from assurance of confidentiality. It would be more accurate to say that in a quantum channel, you could exchange information in such a way that it cannot feasibly be read or tampered with; however, if the ciphertext were extracted from that channel, it would not be meaningfully different from a ciphertext extracted from TLS.


No but if you treat the "key exchange" process as a one time pad key and simply xor it with the message it doesn't matter that the actual ciphertext can be intercepted, since it's impossible to decrypt it. The only catch is that you would need to delay reading the "key" until the last possible second, and of course side channel attacks are still possible on both sides.

Now with how complicated and costly creation of the entangled particles will be, I'm assuming that usage like this will be very very rare, but it's still possible.


> No but if you treat the "key exchange" process as a one time pad key, it doesn't matter that the actual ciphertext can be intercepted, since it's impossible to decrypt it.

Sure, I'm not saying you can't achieve information theoretic security. My point here is that discussion of quantum key exchange should use precision in terminology - integrity and confidentiality are meaningfully different. If the ciphertext from a quantum channel is extracted (in whatever way), it is not more secure than a ciphertext in which the keys were shared in person and promptly destroyed via Cold War-era means. You won't be aware of an adversary trying to break the encryption once they have it in their possession, and the ciphertext won't "break" if plied with an incorrect key (though it would be secure for other reasons). Rather, you'd know if the key exchange process is being broken, or if information was not transmitted correctly.


Sounds like a denial of service attack though. Just keep trying to read messages and render the channel unusable.


This kind of observation would already require physical access to the communications medium (e.g. a fiber optic cable). So if you could DoS a quantum encrypted channel by measuring it, you could equally well DoS a classical channel by just cutting the fiber.


If you have secrets to keep, and your adversaries have that kind of access, better a DDOS than a leak.

Edit: This kind of observation would already require physical access to the communications medium (e.g. a fiber optic cable). So if you could DoS a quantum encrypted channel by measuring it, you could equally well DoS a classical channel by just cutting the fiber.

The comment just above mine, which does a better job than me of explaining the degree of access required.

Besides which, it’s not as though you can only use this. You try your quantum channel first, and if it’s down you know you’re under attack, and act accordingly with your Classical backups.


Well, the whole point of encryption is that you can send your message through despite the fact that your adversary can see it.

Replacing that with a system where your adversary can't see your message, and neither can your correspondent, is a downgrade, not an upgrade.


That depends entirely on your application.


Could you give some examples of applications of encryption where the purpose is not to send a message that adversaries may see but cannot understand?


Encrypting data at rest, for example. (Depends on how wide your definition of 'send' is.)


encryption breaks if someone "observes more" than is allowed by error correction. Physical world is rarely binary.


Well it basically boils down to if somebody observes enough to be able to make any use of it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: