quantum hype

[martin f krafft]

It took me a while. I would herewith like to reply to all posts on
this I received so far:

also sprach John S. Denker <jsd at av8n.com> [2003.09.13.2343 +0200]:
>   *) In each block, Mallory has a 50/50 chance of being able to
>   copy a bit without being detected.

This is what I don't buy. If Mallory sees the data, it must be
detected, because otherwise the approach is flawed. But in any case
does Mallory have the means to completely DoS any attempt of
communication between the parties, simply by reading along, unless
there is a dedicated channel between Alice and Bob. In which case,
why is there a need for quantum cryptography in the first place?

> There is only one chance in 2^-C that Mallory knows this bit.

One chance in 2^C, otherwise it would be deadly, no? But in any
case, Reasonable keysized DH exchanges give me the same security
with a lot more flexibility, and a lot less chance for DoS. I still
don't buy it.

> The foregoing assumed an error-free channel.  Things get much
> worse if the good guys need to do error correction.

... which is almost always required.

> Not true.  The signal is continually checked for tampering;  no
> assumption need be made.

How can you check for tampering without reading the data off the
channel? Checksums?

> > if we want end-to-end security, one can't stick classical
> > routers or other such equipment in the middle of the connection
> > between you and I.
> 
> That's true.  A classical router is indistinguishable from a tap.

The same argument holds as above, why do I need QC then if I have
a dedicated channel anyhow?

Sending asymmetrically encrypted data over something like the plain
old telephone system strikes me as being more secure than sending
these data over the Internet, and that should hold for any
encryption used. Unless QC is applicable to the Internet (which it
won't be, as far as I can tell), I don't see any use beyond
marketing hype.

Sure, DH and similar approaches are based on mathematical
assumptions and are not secure, just incredibly hard to crack. But
just as I can choose a larger C for QC to diminish Mallory's chance
of decoding enough data to be able to make sense of the message
without being detected, I can choose a keysize of 16k if the
application calls for it. DH has been scrutinised and is, to current
knowledge, a theoretically secure algorithm. Or am I mistaken?



also sprach David Wagner <daw at cs.berkeley.edu> [2003.09.13.2343 +0200]:
> I believe the following is an accurate characterization:
>  Quantum provides confidentiality (protection against eavesdropping),
>  but only if you've already established authenticity (protection
>  against man-in-the-middle attacks) some other way.
> Tell me if I got anything wrong.

I don't think this is wrong, but I still don't see how QC guards
against eavesdropping. No, wrong, I see how a key exchange with QC
can make it very difficult to eavesdrop the key (more difficult than
DH?), but I do render the communication susceptible to complete DoS,
and I don't really gain security, IMHO.



also sprach John S. Denker <jsd at av8n.com> [2003.09.14.0102 +0200]:
> That means you can establish a confidential but
> anonymous tunnel, and then send authentication
> messages through the tunnel.

But the tunnel is only confidential as long as it isn't being
eavesdropped. As soon as someone eavesdrops it, I may be able to
find out, but I have already lost data to unwanted eyes. And if
I thus choose to end communication due to the risk of disclosing
more, the DoS worked.

I hope I am not annoying anyone while continually banging on this.
I just have not been convinced of the other side of this argument.



also sprach David Wagner <daw at mozart.cs.berkeley.edu> [2003.09.14.0018 +0200]:
> One could reasonably ask how often it is in practice that we have
> a physical channel whose authenticity we trust, but where
> eavesdropping is a threat.  I don't know.

How much of a threat really exists in a channel encrypted with e.g.
Blowfish, 256bit keys, perfect forward secrecy, and a session key
lifetime of 30 minutes???



also sprach Arnold G. Reinhold <reinhold at world.std.com> [2003.09.14.0536 +0200]:
> The 160 GB hard drive has a couple of advantages over quantum key
> exchange:

And a disadvantage: disk corruption, which may render your channel
temporarily inaccessible. Also, once someone gets hold of the data
on the disk, everyone can read along. It's the same problem of all
symmetric algorithms, enhanced by the fact that the key data is
stored on a medium other than a human neural network (which to date
is only readable by one person)

 

also sprach David Wagner <daw at mozart.cs.berkeley.edu> [2003.09.14.1954 +0200]:
> Well, I agree.  If we get to use complexity-based crypto that is
> not proven secure, like AES, RSA, or the like, then we can do much
> better than quantum crypto.  The only real attraction of quantum
> crypto that I can see is that its security does not rely on
> unproven complexity-theoretic conjectures.

Has anyone *proven* that there is no way to read a quantum bit
without altering it? Heisenberg has not been proven really, everyone
seems to believe this, but has it been proven?

I am not a quantum expert at all, so please excuse if this sounds
stupid.

 

also sprach Ian Grigg <iang at systemics.com> [2003.09.14.1831 +0200]:
> What you want is to find out where the enemy is
> listening in, and when.  Then, it just becomes
> another data point in the tracking game.

I use cryptography; I don't have any enemies (at least none that
I care about)

 

also sprach starwars <nobody at tatooine.homelinux.net> [2003.09.14.0332 +0200]:
> The short version is that you don't send your real data, you send
> random bits.  Once both sides have agreed that they were received
> OK and not eavesdropped on (possible with QC because eavesdropping
> changes the data), then you use those random bits as a one time
> pad, xor them with your real data, and send that.

Using just one link and no redundancy, how can you ever check if
a stream of random bytes has been correctly received on the other
side???

Even though eavesdropping changes the data, you have no way to
verify that without access to the original data, or some redundant
form thereof.



also sprach Ed Gerck <egerck at nma.com> [2003.09.15.0556 +0200]:
> This is not relevant when the technology is correctly used for Q key
> transmission because the sender would not be in the dark (sorry for the
> double pun) for so long.

But this technology is DoS'able and thus not applicable to
productive environments. Or is there a way I can't easily DoS?

(of course, cutting the fibre is also a DoS, as is a forced power
outage of the company's ISP)

> That said, Q cryptography is something else and should not be
> confused with Q key distribution.

This is what initially spawned the thread. So what is QC and how is
it secure, or even has potential?

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net at madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
 
"wer ein warum hat, dem ist kein wie zu schwer."
                                                 - friedrich nietzsche
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20030918/dbd74a1a/attachment.pgp>