So the latter, PITA, reason then... -Mike
> On Nov 1, 2013, at 19:32, Harry Hoffman <[email protected]> wrote: > > So, I'm not sure if I'm being too simple-minded in my response. Please let me > know if I am. > The purpose of encrypting data is so others can't read your secrets. > If you use a simple substitution cipher it's pretty easy to derive the set of > substitution rules used. > Stronger encryption algorithms employ more "difficult" math. Figuring out how > to get from the ciphertext to the plaintext becomes a, computationally, > difficult task. > If your encryption algorithms are "good" *and* your source of random data is > really random then the amount of time it takes to decrypt the data is so far > out that it makes the data useless. > > Cheers, > Harry > > Mike Lyon <[email protected]> wrote: > >> So even if Goog or Yahoo encrypt their data between DCs, what stops >> the NSA from decrypting that data? Or would it be done simply to make >> their lives a bit more of a PiTA to get the data they want? >> >> -Mike >> >> >> >>> On Nov 1, 2013, at 19:08, Harry Hoffman <[email protected]> wrote: >>> >>> That's with a recommendation of using RC4. >>> Head on over to the Wikipedia page for SSL/TLS and then decide if you want >>> rc4 to be your preference when trying to defend against a adversary with >>> the resources of a nation-state. >>> >>> Cheers, >>> Harry >>> >>> Niels Bakker <[email protected]> wrote: >>> >>>> * [email protected] (Michael Still) [Fri 01 Nov 2013, 05:27 CET]: >>>>> Its about the CPU cost of the crypto. I was once told the number of >>>>> CPUs required to do SSL on web search (which I have now forgotten) >>>>> and it was a bigger number than you'd expect -- certainly hundreds. >>>> >>>> False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html >>>> >>>> "On our production frontend machines, SSL/TLS accounts for less than >>>> 1% of the CPU load, less than 10KB of memory per connection and less >>>> than 2% of network overhead. Many people believe that SSL takes a lot >>>> of CPU time and we hope the above numbers (public for the first time) >>>> will help to dispel that." >>>> >>>> >>>> -- Niels. >>>>
