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 format. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
