} > I'm not saying I could "break" it. I'm just saying that, given two
} > bit streams, A and B, I could tell whether they were generated by the
} > same encryption algorithm, or different algorithms.
} Good for you, I certainly couldn't. As somebody said, you probably could
} so in case RC4, which seems to be a pathological case, showing a
} fingerprint, but then, most algorithms don't.
Hah, and given its speed, RC4 could well be a standard algorithm.
Actually, it is -- Netscape's SSLs. So much for the usefulness of
fingerprinting.
As far as I can tell, this entire subthread arose from Eugene saying
that it would still be useful to build weak encryption into TCP/IP; Lyle
challenged this saying that those who then used strong encryption would
be drawing attention to themselves.
(1) Lyle's argument rests on method identification being much easier
than method breaking. Eugene denies this point above; I don't think John
Clark's responses have been addressin this poine.
(2) Lyle's argument also rests on there being a diverse population of
messages; most guared with a standard weak algorithm, some bearing PGP
headers. But if the strong crypto was happening underneath the weak, as
it would if some method was built into TCP/IP, then any fingerprinting
should be obscured; wide-target eavesdroppers would have to decrypt
everything routinely to find the strongly guarded messages.
(3) Given the current Internet community, I think it likely that TCP/IP
will either not change at all (whups) or have strong crypto built into
it. The paranoid could then wrap their messages themselves before
putting them onto the Net. Not pretty for eavesdroppers.
Have I missed anything?
Merry part,
-xx- Damien R. Sullivan X-) <*> http://www.ugcs.caltech.edu/~phoenix
"Ah hates crickets...He is as invisible as God but with a MUCH louder
voice." -- JMS