Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serious Flaw Emerges In Quantum Cryptography

technologyreview.com

Post reply on HN
Print view View original

41–47 of 47 posts

Re: Serious Flaw Emerges In Quantum Cryptography

#41

Post by VikingCoder »

tptacek wrote: post #40
VikingCoder wrote: post #39

Earlier quoted context omitted.

If you know any plaintext, then you know the OTP that corresponds to that one section of the key, and you know the salt that was used for that one hash. Since I will never use, or accept, that portion of the OTP again, this doesn't gain you the ability to decypher a message, or fake a message without detection. If you both know the plain text, and you have prevented transmission of my original message, then you have…

No, using an OTP isn't actually better. The problems I'm talking about don't depend on keystream reuse; they depend on the fact that you don't have "keys", you have a single keystream. A real, sound cryptosystem would use keys in at least two places in the protocol (once to provide confidentiality for the message, and once to provide integrity).

I use the OTP to encrypt the message. I use the OTP as salt for a hash to verify.

Confidentiality, and integrity.

Re: Serious Flaw Emerges In Quantum Cryptography

#42

Post by tptacek »

VikingCoder wrote: post #41
tptacek wrote: post #40

Earlier quoted context omitted.

No, using an OTP isn't actually better. The problems I'm talking about don't depend on keystream reuse; they depend on the fact that you don't have "keys", you have a single keystream. A real, sound cryptosystem would use keys in at least two places in the protocol (once to provide confidentiality for the message, and once to provide integrity).

I use the OTP to encrypt the message. I use the OTP as salt for a hash to verify. Confidentiality, and integrity.

Or it would be if "simply concatenating a keystream with a secure hash function" created a secure MAC, which it doesn't.

You see what I mean about "yes-but"-ing ones way into treacherous confidence. Believe me when I say that a lot of systems have been deployed using this same design process, and all of them failed --- it is hard to name a well-designed cryptosystem that didn't succumb to spectacular failures.

And, on another tangent, you can see how your design now begs a pretty big question: between AES and SHA-256, virtually everyone would agree that SHA-256 is the less sound primitive (they're both "sound", but SHA-2 will fall before AES, which is why we're busily selecting SHA-3 right now).

Concern about AES drives you to contemplate OTPs, but forces you to rely on something like SHA-2. An AES design could use AES both for confidentiality and integrity. Either way, you're not getting "perfect" security; you have all the downsides of OTPs and none of the upside.

OTP's are kind of silly.

Re: Serious Flaw Emerges In Quantum Cryptography

#43

Post by VikingCoder »

tptacek wrote: post #42
VikingCoder wrote: post #41

Earlier quoted context omitted.

I use the OTP to encrypt the message. I use the OTP as salt for a hash to verify. Confidentiality, and integrity.

Or it would be if "simply concatenating a keystream with a secure hash function" created a secure MAC, which it doesn't. You see what I mean about "yes-but"-ing ones way into treacherous confidence. Believe me when I say that a lot of systems have been deployed using this same design process, and all of them failed --- it is hard to name a well-designed cryptosystem that didn't succumb to spectacular failures. And, o…

Thank you for all of your responses.

Unfortunately, all you've done is tell me "it won't work."

When you attempt to inform me why it won't work, your answers boil down to "because."

Why doesn't concatenating "MESSAGE XOR OTP" with "HASH(OTP-SALT, MESSAGE)" both a) provide confidentiality for the message, and B) provide integrity?

It certainly provides confidentially for the message. Without knowing the OTP I use, you will not decipher the message.

And by using another portion of the OTP as a unique, one-time salt for a hashing function (I don't care which hashing function), I am preventing a man in the middle from twiddling bits undetected.

If you want to tell me that I'm wrong - that's great. If you want to explain why I'm wrong, that would actually be useful.

...and Quantum Cryptography boils down to being a fancy way to generate a OTP. Your argument then becomes, "All of the researchers working on Quantum Cryptography are idiots, and they should know better." Extraordinary claims require extraordinary proof. If your claim is that they can't build a physically secure system, because you can't trust a quantum-entagled particle pair to really arrive at both ends uncorrupted, that's one thing. No, your claim is that the underlying math behind OTP is inherently flawed. Message XOR OTP is not secure, even if the man in the middle does not know the OTP.

From the definition on Wikipedia, "A MAC algorithm, sometimes called a keyed (cryptographic) hash function, accepts as input a secret key and an arbitrary-length message to be authenticated, and outputs a MAC (sometimes known as a tag). The MAC value protects both a message's data integrity as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content."

The secret key is a sequence of bytes from my OTP. They have never been used before, and they will never be used again.

"While MAC functions are similar to cryptographic hash functions, they possess different security requirements. To be considered secure, a MAC function must resist existential forgery under chosen-plaintext attacks. This means that even if an attacker has access to an oracle which possesses the secret key and generates MACs for messages of the attacker's choosing, the attacker cannot guess the MAC for other messages without performing infeasible amounts of computation."

They cannot guess the MAC for other messages, because they cannot guess the key for other messages, because they do not know the OTP for other messages, because I will never reuse any of my OTP, thus making it a ONE Time Pad.

"MACs differ from digital signatures as MAC values are both generated and verified using the same secret key. This implies that the sender and receiver of a message must agree on the same key before initiating communications, as is the case with symmetric encryption."

No problem. That's what my system does. I tell you what portion of the OTP to use, and you use it. If it's ever been used before, you know the communication channel has been compromised.

http://upload.wikimedia.org/wikipedia/commons/0/08/MAC.svg

The Key (K) is determined by the position in the OTP, specified by the message header.

Re: Serious Flaw Emerges In Quantum Cryptography

#44

Post by mindslight »

VikingCoder wrote: post #43
tptacek wrote: post #42

Earlier quoted context omitted.

Or it would be if "simply concatenating a keystream with a secure hash function" created a secure MAC, which it doesn't. You see what I mean about "yes-but"-ing ones way into treacherous confidence. Believe me when I say that a lot of systems have been deployed using this same design process, and all of them failed --- it is hard to name a well-designed cryptosystem that didn't succumb to spectacular failures. And, o…

Thank you for all of your responses. Unfortunately, all you've done is tell me "it won't work." When you attempt to inform me why it won't work, your answers boil down to "because." Why doesn't concatenating "MESSAGE XOR OTP" with "HASH(OTP-SALT, MESSAGE)" both a) provide confidentiality for the message, and B) provide integrity? It certainly provides confidentially for the message. Without knowing the OTP I use, you…

1. The general pathology when people focus on 'One Time Pads' is that they're blinded by the 'absolute security' of that one primitive, and don't think about the security properties of everything else. Breaking your hash function allows a plaintext-knowing attacker to rewrite a message, which is considered a break of your entire system. In other words, your system is only as secure as your hash function.

2. Since the general security of a system is contingent upon its easiest attack (even if that attack is somehow 'rarer'), you might as well use that same hash function to create a stream cipher and once again avoid the huge OTP. (which is why it won't be taken seriously)

3. Security of actual cryptosystems comes from widespread implementation, study, and abuse. While your system may indeed have stronger confidentiality properties, it most likely will have undetected implementation errors due to it not being widely scrutinized.

4. I think the meat of your argument is that BKD (backpack key distribution) is comparable to QKD. I do agree that your comparison is appropriate, but think it says more about QKD than BKD. Quantum key distribution still relies on classical algorithms for authenticating the classical channel (some kind of MAC), and today's QKD products even rely on classical block ciphers, as the QKD-produced keys are quite small.

5. I see no benefits to QKD in general. It only works between prearranged (and physically connected!) pairs of parties. Reimplementing the Internet with QKD means the links are secure, but ISPs still see everything. If quantum computing really does ruin the RSA and DLOG parties, there's certainly other public key algorithms.

Re: Serious Flaw Emerges In Quantum Cryptography

#45

Post by VikingCoder »

mindslight wrote: post #44
VikingCoder wrote: post #43

Earlier quoted context omitted.

Thank you for all of your responses. Unfortunately, all you've done is tell me "it won't work." When you attempt to inform me why it won't work, your answers boil down to "because." Why doesn't concatenating "MESSAGE XOR OTP" with "HASH(OTP-SALT, MESSAGE)" both a) provide confidentiality for the message, and B) provide integrity? It certainly provides confidentially for the message. Without knowing the OTP I use, you…

1. The general pathology when people focus on 'One Time Pads' is that they're blinded by the 'absolute security' of that one primitive, and don't think about the security properties of everything else. Breaking your hash function allows a plaintext-knowing attacker to rewrite a message, which is considered a break of your entire system. In other words, your system is only as secure as your hash function. 2. Since the…

Thanks for the detailed response!

That's interesting. I didn't know that a system was considered broken if, knowing plaintext (and breaking a hash function) allows an attacker to rewrite a message. Probably pretty basic stuff to you.

Re: Serious Flaw Emerges In Quantum Cryptography

#46

Post by tptacek »

VikingCoder wrote: post #45
mindslight wrote: post #44

Earlier quoted context omitted.

1. The general pathology when people focus on 'One Time Pads' is that they're blinded by the 'absolute security' of that one primitive, and don't think about the security properties of everything else. Breaking your hash function allows a plaintext-knowing attacker to rewrite a message, which is considered a break of your entire system. In other words, your system is only as secure as your hash function. 2. Since the…

Thanks for the detailed response! That's interesting. I didn't know that a system was considered broken if, knowing plaintext (and breaking a hash function) allows an attacker to rewrite a message. Probably pretty basic stuff to you.

Different kinds of attacks often play off each other, so that a small amount of known plaintext allows you to modify the decrypted plaintext of a message in ways that will reveal more plaintext.

So, for instance, a CBC padding oracle is an attack that allows you to decrypt messages byte-by-byte --- but it's stopped entirely by a proper MAC on the message.

Re: Serious Flaw Emerges In Quantum Cryptography

#47

Post by Groxx »

beloch wrote: post #4
bcl wrote: post #3

Earlier quoted context omitted.

I read it and you're right. I'm puzzled as to why they would think this 'scuppers' all of quantum cryptography. They also mention imperfect hardware, but hardware always improves.

This obviously doesn't have any impact on those who own and trust the sender and receiver and only need to be cautious about what happens in between them. However, part of the desire for device independent security is that you can use public infrastructure without trusting it and still be certain that your communication is secure. i.e. If quantum networks replace/augment classical networks, can you trust them without…

Isn't that everyone? Quantum crypto does nothing for authentication as far as I'm aware, so you still need to identify your recipient by some method. It requires hardware as far as I'm aware, so you still need to trust the sending and receiving hardware. Which leaves you with just the medium of transmission; if it's crypto you're trusting, the medium doesn't matter. If it's quantum effects for communicating, the only trick I'm aware of lets quantum-crypto-communication detect observers, which this 'scuppering' has no effect on.
Post reply on HN