undersea taps

[Eugene.Leitl at lrz.uni-muenchen.de]

Matthew Pemble wrote:

> No, the "sane" assumption is that everything that goes out in clear is *
> potentially * captured and stored for later analysis.  As previously
> discussed, the sheer volumes of data transmitted on the monitorable
> networks are so vast that filtering at time of capture is necessary.

This does not follow. It's clearly pointless to store multimedia
streams, or even web access trails of persons (perhaps not too poinless,
if you pare down the set of targets to monitor), but email is the 
canonical case of low-bandwidth-high-content. Not too many people 
have email capabilities world-wide (as of yet, but the bulk of
my spam is in Chinese already), and given the limited input rate 
(how many hours/day do you do email? How much of this is effective 
text input?) it's perfectly possible (albeit a tad expensive, 
even given current hardware prices, but the spooks -- whether
budget being classified, or not -- *are* sufficiently lavishly 
funded) to capture and store at least the entire email traffic, 
world wide (weeding out redundancy like mail reflectors is a 
piece of cake, just filter out anything which' body hashes to same
number, just keep one body and a set of emails parsed from headers).

If you happen to become overwhelmed (doesn't appear likely, hard
drive array and robot tape library space is cheap, especially 
in quantities and for feds), you can fall back to keyword 
triggers, semantic analysis and/or a set of email addresses 
which are interesting (rest assured, you people here are all 
interesting alone by virtue of being on this list).

If they're not doing realtime fingerprinting, keyword and semantical
analysis and the usual warehousing I'd call them 1) stupid 2) criminally
negligent. Whatever they are, stupid they're not.
 
> Now, this means that you should, from a risk analysis point of view,
> assume that it is your sensitive data that is going to trip the filters
> - this is the "security by obscurity" versus "security by design"
> argument.

You have to titrate the professional paranoia at a level which makes you
still sufficiently operational while not opening too many angles of attack.
 
> Many individual emails are low data volume, but I normally get a dozen
> or so .5MB to 2MB emails a week, never mind the couple of thousand 5kB

If this is a binary attachement, it can be stripped. If this is redundant
email (mailing list), it can be stored as a single instance (the spooks
should be actually selling spam protection services, they'd be hard to 
beat, unfortunately that would be showing their hand), and a list of 
recipients. I don't think I ever write more than 100 k plain ascii
email/day, usually a lot less. If extrapolated to other guys out there,
drinking from the firehose this is certainly not, and filtering for 
classes of traffic is cheap, especially if done in hardware. ASIC
arrays strike here.

> emails.  There are lots of people out there.  Storage is relatively

How many people world-wide use email, half a billion? Most of them
never write an email daily. Even assuming 1 kByte of email person/day,
half a billion is piece of cake.

> cheap, true, but accessing that volume is, as anyone who has been
> designing backup solutions recently will testify, not keeping up to
> speed.

A modern PC cluster scales up to ~10 kNodes. Assuming each node
can store and process 100 GByte (a low figure, given modern
IDE drive density, soon to go up to one TByte/drive), you've 
got ~exabyte online, with full data warehousing capability, 
on a shoestring budget of a few 10 megabucks at best. Old traffic
is moved out to tape library, of course.

It is not rational to assume they're not doing it, as the 
capabilites are well within range.

______________________________________________________________
ICBMTO  : N48 10'07'' E011 33'53'' http://www.lrz.de/~ui22204
57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com