| > | ...Also, I hate to say this, we may need to also require that all | > | encrypted traffic allow inspection of their contents under proper | > | authority (CALEA essentially).... | > 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? | | 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). 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. Just because it *looks* like SSL doesn't mean that the key it leaks to you is actually valid. And if it *is* actually valid, it doesn't mean that there isn't a second layer of encryption inside the SSL session.
Go back to my example: How will you distinguish between random bits and a compressed video stream? Do you assume that every codec in the world will be registered? How about a big scientific dataset of floating point values? Or some huge, validly formatted, spreadsheet of such values? And that doesn't even consider obvious countermeasures. What happens if you decrypt and see a bunch of ASCII values that follow the first and second order statistics of English text? Sure, encoding my encrypted data like that costs me some overhead - but given the speed of today's networks, who cares? This train left the station a *long* time ago. -- Jerry | | - Alex | | -- | | Alex Alten | [EMAIL PROTECTED] | | | | | --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]