Leichter, Jerry
> > Why not just require that the senders of malign
> > packets set the Evil Bit in their IP headers?
> >
> > How can you possibly require that encrypted traffic
> > *generated by the attackers* will allow itself to be
> > inspected?

Alex Alten wrote:
> You misunderstand me.  We can for the most part easily
> identify encrypted data, either it is using a standard
> like SSL or it is non-standard but can be identified
> by data payload characteristics (i.e. random bits).

Steganography will beat that.  If the government demands
non random bits, non random bits will be provided.

> If it is a standard (or even a defacto standard like
> Skype) we can require access under proper authority.
> If it is not (or access under authority is refused),
> then just simply block or drop the packets, there's no
> need to inspect them.

This means that only authorized, regulated, officially
registered data formats shall be permitted.  It will be
almost impossible, most likely completely impossible,
for *my* format to get registered even though it sends
data completely in the clear.  Skype will be
grandfathered in, but the next Skype will not be.

So I will do what the bad guys do - steganograph my
entirely innocuous application, which would not need
cryptography at all except to escape intrusive
regulation, forcing me to hide my actual data format
inside a registered and officially authorized data

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to