| > | ...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

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

Reply via email to