
Serious Flaw Emerges In Quantum Cryptography - llambda
http://www.technologyreview.com/blog/arxiv/27522/
======
srl
If I'm understanding this correctly, the "serious flaw" recently uncovered is
that if the manufacturer of the crypto devices is malicious, the crypto
devices can be made to be insecure. Despite the fact that this same "serious
flaw" exists with classical cryptography devices, only worse (since the
quantum attack doesn't reveal plaintext A until B is sent).

(Disclosure: haven't bothered to read the arXicle.)

~~~
tjoff
_Despite the fact that this same "serious flaw" exists with classical
cryptography devices, only worse (since the quantum attack doesn't reveal
plaintext A until B is sent)._

How would you do this with classical cryptography?

Isn't the point about this particular flaw that it is pretty much undetectable
(other than inspecting the hardware itself (which is outside the scope of the
article that treats it as a black box)). If the same were to be implemented on
classical cryptography it would be comparatively trivial to detect if someone
tried to sneak in an old message interleaved with a new message (you know the
plaintext + key and thus you know exactly what that will generate).

The compelling argument for quantum cryptography is that it is _provably_
secure (well, that's the theory) and it is quite difficult to prove that the
hardware has not been tampered with.

The thing you could do with classical cryptography is to in some way "leak"
the key (such as what debian inadvertently did with openssl) but the whole
point of quantum cryptography is to have a _perfect_ key distribution to
combat any known or unknown attacks.

I found the abstract, <http://arxiv.org/abs/1201.4407> , shorter and more
informative than the article.

~~~
aidenn0
"How would you do this with classical cryptography?"

Nearly every classical cryptography device uses a source of entropy; if you
break that intentionally then you have a side-channel.

------
Groxx
> _"In short, the problem is that an adversary can program devices to store
> data in one protocol and leak it in subsequent protocols, in ways that are
> hard or impossible to counter if the devices are reused," say Barrett and
> co._

You mean, if you store the encryption key and later reveal it to outside
sources, your secure communication is no longer secure? SHOCK AND AWE.

It's complete fluff that has nothing to do with quantum cryptography, just the
intrinsic chain-of-trust of whatever hardware you're using. If something
you're using is untrustworthy, the whole chain is - this is not a new
discovery.

------
benmmurphy
i don't understand how it is not susceptible to MITM attacks. how do you know
you know the thing at the other end is really who you want to talk to without
using some kind of preshared key? maybe an eavesdropper can't view the
conversation between you and the other end but that doesn't matter if someone
can easily pretend to be the other end.

~~~
greeneggs
Both standard quantum key distribution (QKD) and device-independent quantum
key distribution schemes assume that the two parties share an authenticated
classical channel. Without authentication, of course you cannot prevent man-
in-the-middle attacks.

Authentication can be established using a shared secret (which is why purists
sometimes refer to QKD as a key _expansion_ protocol). Or, it can be
established using signatures and certificate authorities. It is worth pointing
out that man-in-the-middle (MITM) attacks must be made online; if you break a
signature scheme a year after the QKD protocol finishes, it does not
compromise the key.

------
VikingCoder
Okay, here I go on a tangent:

If I buy two 5-bay DROBOs, 10 2 TB HDs, and a hardware random number
generator, I could make a multi-TB One Time Pad, and copy it onto the second
DROBO.

I keep DROBO one, and physically carry DROBO two to my intended recipient.

What are the problems with this?

It's cheap. It's as secure as any communication could possibly be. It provides
for a whole lot of communication, with relatively little physical effort.

~~~
tptacek
The problem with this is that it is unlikely to be in practical terms better
than using two slips of paper to write down a 256 bit random number and using
that to establish a long-lived AES-256-CTR session.

(This is without getting into the fact that a single keystream is not a secure
message exchange protocol, and that conventional cryptography has well-tested
ways of linking confidentiality secrets to integrity secrets and of
marshalling and canonicalizing messages; I'm just answering your question on
its own terms).

None of this has much to do with QC, by the way; as I understand it, QC
replaces conventional number-theoretic public key crypto, not block and stream
ciphers.

~~~
VikingCoder
> a single keystream is not a secure message exchange protocol

I have to build protocols around making sure to not re-use parts of my One
Time Pad. Around making sure that I validate messages. Asking for a re-send of
a message. Destroy the One Time Pad because it's been compromised, etc.

But at it's core, using a One Time Pad is a secure message exchange protocol.
I'm surprised to see you contradict that.

> and that conventional cryptography has well-tested ways of linking
> confidentiality secrets to integrity secrets and of marshalling and
> canonicalizing messages

I'm sorry - I don't know what you mean. Can you explain it to me more simply?

Cryptotext = Plaintext XOR OneTimePad.

Plaintext = Cryptotext XOR OneTimePad.

As I said, I have a lot of work to do to handle my One Time Pad... But the
fundamental mathematics are secure. And you seem to be saying they are not.
What do you mean?

> None of this has much to do with QC,

Agreed - that's why I called it a tangent.

~~~
tptacek
The difference between a stream of bytes and a "message" is crucial, and if
you don't understand it, the best reason you shouldn't do your Drobo OTP
scheme is that you don't understand crypto well enough to implement any
cryptosystem. Just use TLS.

(I don't mean to be offensive. I don't understand bioinformatics, for
instance, and probably shouldn't build mission critical things that rely on
it.)

~~~
VikingCoder
I'm not proposing that you buy my system - I'm asking what's wrong with my
design for the core mechanic.

And you've genuinely offered no substantive critiques. Sounds like the core
mechanic is gold, then.

If there's nothing wrong with the core mechanic, I should be able to buy a
commercial system built on it, and know that it has all of the inherent
strengths and weaknesses of my core mechanic. And possibly more weaknesses,
inherent in the implementation of any security system.

~~~
tptacek
Thank you. It's people like you who are steadily paying for my kids' college
education. :)

I don't blame you for being frustrated with my responses, but it's my
experience that detailed critiques of random crypto schemes on message boards
are counterproductive; the designer just "yes, but"'s the critique until all
the low-hanging fruit is picked (each of which was a devastating flaw in their
original scheme), and the conversation ends with a no- less- fatally- flawed
system and a designer who is perversely _more_ confident.

~~~
VikingCoder
People are using Quantum Entanglement to exchange keys.

I'm proposing a hard drive and a plane ticket.

Your critique is based upon ego alone.

