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 <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> [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:"; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! "wer ein warum hat, dem ist kein wie zu schwer." - friedrich nietzsche
pgp00000.pgp
Description: PGP signature
