Mass encryption use, and DPI

[Peter Fairbrother]

Florian Weimer wrote:
> * Peter Fairbrother:
> 
>> Been looking for data on this, can't seem to find anything useful. It
>> seems that Facebook average 580 connections per second, and have an
>> average of about 800,000 people connected.
> 
> It's probably 580 logins per second.


'At'swot I meant. :)


>> Using HP AXL300 cards they'd need about 120, costing £35,000, for
>> 2kbit RSA and DH setup. For symmetric encryption they'd need a million
>> or so for asics - or if they used 8800GTX cards for both, that would
>> come to about £100,000 for hardware.
> 
> HP AXL300 cards are no longer relevant, really.  A modern CPU core can
> easily perform 350 private 2048 bit RSA operations per second.  The
> numbers quoted on data sheets are typically 1024 bit unless otherwise
> noted, so this isn't even a fair comparison.

Indeed,  but they are still in the end of their purchase life cycle, and 
give an idea of what's available and it's performance. And it's cost.

And I costed them at 2 kbit ...

(not counting mis-/ab-/Properly-used graphics cards :)

(and not thinking that most people still use 1 kbit RSA/DH today -  but 
IMO if 2 kbit isn't going to be good enough. 4 kbit is probably going to 
be as useless as 2 kbit will be then)

  ... and the cost was neglible.

> 
> But this won't help Facebook et al. much because unless they use
> custom load balancers, they probably need to extend the crypto to
> their load balancers.  

why?


And this can be extraordinarily expensive if
> you don't built them in-house.  The hardware makers tend to assume
> that there's already measurable cost associated with each transaction
> carried out over TLS, and price their products accordingly.  This is
> true for retail online banking.  

ah

It is not true for most ad-funded
> services.

ah hah !!!!


> 
> Two weeks ago, Google announced that it is actively looking at
> providing all services over HTTPS:
> 
> <http://googleonlinesecurity.blogspot.com/2009/06/https-security-for-web-applications.html>
> 
> It's fairly obvious that it's going to happen at some point.

Great, it'll be more than about time :)

Hope they use an individual DH-per-transaction though, not something 
scummy based on a ClientKeyExchange PreMasterSecret message contents, as 
decrypted by the server using a server's static private/public key, and 
demandable-and-verifiable-without-demanding-the-private-key.



> Competitors will likely respond and offer HTTPS as well.  Market
> dynamics could make a non-cooperative payload retention scheme
> obsolete in an instant (compared to how long it takes to design,
> specify and deploy such systems).

:)

> And please don't call it "DPI", that's misleading.  It's either flow
> data retention, or payload retention.  Even if you just want to track
> who logs into what account, you need to keep full payload for quality
> control reasons.

Not my naming, and I think you might be sightly out there - their idea 
is to inspect all packets but only retain some data collected from some 
of them - and shirley both of the above processes incviolve retaining 
all packets?

Or does retention include whatever is necessary to keep a packet for 
long enough to look at it? Could well do.


Whatever, it's phormish, dictatorial, snoopy, and unacceptable.


-- Peter Fairbrother



"For more modest tastes I think there ought to be beer."

Ursula LeGuin,
The Ones Who Walk Away From Omelas



  - couldn't write "incviolve" again if I tired, so I lerft it in