> From: Discuss [mailto:discuss-bounces+blu=nedharvey....@blu.org] On > Behalf Of Tom Metro > > > You seem to think there's an obstacle which isn't really real - > > Encryption is very cheap computationally, so cheap indeed it can be > > done by the disks themselves. > > Yes, disk that have hardware acceleration for that purpose.
Yes, aka "self encrypting drives." Which are very common and readily available. If you don't have a self-encrypting drive, then obviously the encryption must be done on your CPU. Some appliances have support for self-encrypting drives. The appliance only needs to store the encryption key somehow (exercise left to reader) and in BIOS, tell the drives to encrypt themselves. I know how Microsoft securely stores the encryption keys in TPM - I can't speak to any other OSes or appliances that use the TPM or other techniques. > While we are certainly heading in the direction where the CPU overhead > for encryption can be ignored, even in low-end embedded devices, we are > not there yet. We are certainly there, *except* in situations with puny cpu's and no hardware acceleration. On a CPU that has AES-NI (the AES New Instruction set, which was new around 6-7 years ago), you can max out your SATA bus and it will utilize around 3-4% CPU time of a single core. This compares to around 30-40% if you don't have AES-NI. But admittedly - this is an x86 laptop processor, which is going to be much more powerful than a little ARM or similar. So even if you lack the hardware acceleration, you don't get CPU performance limited; you just burn some unnecessary CPU power. > Doing AES-256 CBC 1024, the Pi is about 10x slower than an i5 per the Agreed. It is not going to work well, to run encryption on an ARM processor without AES hardware acceleration. _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
