quantum hype

[martin f krafft]

Again, replying to all.

also sprach John S. Denker <jsd at av8n.com> [2003.09.19.0038 +0200]:
> Other key-exchange methods such as DH are comparably
> incapable of solving the DoS problem.  So why bring up
> the issue?

For one, I can un-DoS with QC at any point in time. This may be
relevant for certain attacks.

Second, if I have a strong key exchange protocol, you cannot DoS me
because I can choose other media. If all I can use is QC because of
its "features", you can DoS me easily.

> If you can _prove_ DH is secure, please let us know immediately.

<grin>
I was drunk last night, but I swear I was able to prove it ;^>

> If you have a consistent theory of physics that repeals the
> uncertainty principle, please let us know immediately.

Yeah, solved that in my dream last night. (also ;^>)



also sprach Dave Howe <DaveHowe at gmx.co.uk> [2003.09.19.1416 +0200]:
> QC is a hype-only technology - it relies on a unbroken line
> impervious to MitM, and there ain't no such beast.

I think this may well be the conclusion up to now...

> > Has anyone *proven* that there is no way to read
> > a quantum bit without altering it?
> no. its the "underlieing hard problem" for QC. If there is
> a solution to any of the Hard Problems, nobody knows about them.

right, so it's no better than the arguable hard problem of factoring
a 2048 bit number.

> cryptography is 90% paranoia - you *have* enemies, and don't know
> about them.

wrong. i don't consider those that shouldn't know about some things
to be my enemies. i know that crypto is useful when someone actively
seeks information. but if i want my girlfriend not to see those
mails i send to this other chick (i have no girlfriend btw),
i encrypt them and guard against the risk that i leave the window
open when she comes home and she accidentally hits enter to read
that email.

i also don't consider an ISP an enemy who does network-related
maintenance and happens to read into my data stream. heck, maybe the
guy is even interested and reads along for his pleasure. he's not an
enemy. but using crypto will still prevent this.

i guess it's a matter of definition, so let's just leave it there.

> evesdropping *destroys* the data by removing 50% of the photons
> almost at random. that is the quantum bit of the process - only
> a single photon is sent, so it can only be processed (read) by one
> host; reading the photon destroys its value, and the random
> element ensures it is incorrectly read 50% of the time.

Now this makes a lot more sense. Somehow I thought that QC simply
flipped the bit. But then nature isn't binary, neither is physics,
so I was just dumb.

> I admit to not entirely following the logic behind Quantum
> Cryptography

You seem to have a lot more of a grasp than I.

Anyhow, we are deviating here and there from the topic. So let me
summarise:

  - QC, if correctly used, can serve as the basis for OTP
    encryption.
  - The provable security of QC thus actually comes from OTP.
  - QC needs an unbroken channel. The channel does not have to be
    private because an observer destroys photons, which can be
    detected.
  - This observer could DoS the communication, but that's akin to
    cutting the land-line.
  - Actually, no, because if I don't rely on QC but have other
    means, I can switch to another medium if someone cuts my
    landline.

There were other points, but I concentrated on the technical ones
and hope I left none out.

Btw: is this list archived?

-- 
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!
 
"if beethoven's seventh symphony
 is not by some means abridged,
 it will soon fall into disuse."
                             -- philip hale, boston music critic, 1837
-------------- 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/20030921/cd28ddfc/attachment.pgp>