3 ms·
I would think it common-sense to do that. If nothing else, it makes hard-drive disposal much simpler, and accessing disk storage is slow enough that I can't ima
by lazaroclapp 11y ago
I would think it common-sense to do that. If nothing else, it makes hard-drive disposal much simpler, and accessing disk storage is slow enough that I can't imagine the overhead of (hardware-assisted) encryption is a problem. Most places I worked at require all desktops and laptops to use storage encryption too. Encryption at rest is very different from end-to-end encryption, though.
- bostik 11y agoThe overhead of at-rest encryption is negligible. If you think about it, the files Gmail backends need to access are fairly small: even the upper limit is just couple of tens of megabytes. This is true regardless of whether you get to use hardware acceleration or not. (And in case of modern Xeon servers, you certainly do!) Servers will spend more time waiting for disk seeks to complete than they do decrypting the data once it's read. You can even test it yourself: just run "openssl speed aes". My puny laptop does 85MB/s at the most unoptimal settings (AES-256 with 16B blocks), and 92MB/s with conservative settings at same security level (AES-256 with 1kB blocks). A decent server system can do multiples of that. And once you add hardware acceleration, we're talking about crypto throughput of several hundreds of MB/s. Google servers are connected to top-of-rack switches, and I can make an educated guess that the per-server bandwidth is 1Gb, or roughly ~120MB/s. For hilarious comparison, even my RPi 2 can do 16MB/s. So: if we're talking about on-disk storage, crypto will never be your performance bottleneck.
- wolf550e 11y agoprotip: run `openssl speed -evp AES256` and be amazed by the performance of AESNI!