OK, so I've been hacking on and testing my shiny new One A110 mini-laptop during the last few days and I must say I'm very happy with it. I'll write up some more details later (check the wiki if you're impatient), but today I want to highlight a very nice feature of this laptop (compared to, for instance, the Eee PC): The VIA C7-M ULV CPU in the laptop has VIA Padlock support.
VIA Padlock is a hardware feature in recent VIA CPUs which provides hardware-accelerated AES and SHA-1/SHA-256 support, among other things. This can be used in Linux (with the proper drivers and patches) to improve performance of dm-crypt, OpenSSL (and all programs using it), scp, sha1sum, OpenVPN, etc. etc.
I have written a quite extensive VIA Padlock HOWTO and benchmarks in the A110 wiki (but all of this will work on other systems which have VIA Padlock, too). To summarize, here are the most important benchmarks:
Without VIA Padlock support:
$ hdparm -tT /dev/mapper/hdc2_crypt /dev/mapper/hdc2_crypt: Timing cached reads: 448 MB in 2.00 seconds = 223.47 MB/sec Timing buffered disk reads: 22 MB in 3.07 seconds = 7.17 MB/sec
With VIA Padlock support:
$ hdparm -tT /dev/mapper/hdc2_crypt /dev/mapper/hdc2_crypt: Timing cached reads: 502 MB in 2.00 seconds = 250.41 MB/sec Timing buffered disk reads: 90 MB in 3.07 seconds = 29.36 MB/sec
The native speed of the SSD in the laptop is 31.01 MB/sec, so there is almost no performance penalty when using VIA Padlock.
OpenSSL speed benchmark, first line without Padlock, second line with Padlock enabled:
$ openssl speed -evp aes-256-cbc [-engine padlock] type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256-cbc 9187.18k 10572.28k 11054.32k 11179.36k 11218.02k aes-256-cbc 47955.92k 150619.73k 325730.73k 458320.11k 520520.79k
Without VIA Padlock support:
$ scp -c aes256-cbc bigfile.dat localhost:/dev/null bigfile.dat 100% 159MB 5.9MB/s 00:27
With VIA Padlock support:
$ scp -c aes256-cbc bigfile.dat localhost:/dev/null bigfile.dat 100% 159MB 14.5MB/s 00:11
A real speed benchmark is pending (not measurable easily on 100MBit LAN, will try on a slower link), but as OpenVPN uses OpenSSL it should have roughly the same speedup iff you tell OpenVPN to use AES (it uses Blowfish per default).
Also, there's a measurable difference in CPU load while tranferring large files over OpenVPN: 8% CPU load with VIA Padlock (vs. 20% CPU load without VIA Padlock).
phe_sum is a small C program which can be used as drop-in replacement for sha1sum (which doesn't support VIA Padlock yet). Quick benchmark:
sha1sum, without VIA Padlock:
$ time sha1sum bigfile.dat real 0m6.511s user 0m5.864s sys 0m0.412s
phe_sum (with VIA Padlock support):
$ time ./phe_sum bigfile.dat real 0m1.149s user 0m0.704s sys 0m0.424s
All in all VIA Padlock gives you a pretty impressive speedup for many crypto-using applications on Linux, which is especially useful on the A110 mini-laptop (think OpenVPN or scp for mobile usage, and dm-crypt for an encrypted SSD, of course).
I was recently thinking about SMS encryption (you know, the short messages sent from your cell phone). Or MMS encryption for that matter. Are there any Free Software solutions to implement such a thing, based on well-known crypto primitives and proven implementations thereof?
From a quick glance I could not find anything usable, only lots of commercial, closed-source "solutions" which cost money and are basically crap.
I was thinking about hacking together a small Java application (so that most modern phones can run it) which basically asks for a password and pipes your text through AES before sending the SMS. On the receiver's side, you enter the same password and get to see the plaintext. That's pretty much it.
If you want something more elaborate you can use public-key crypto (basically embed GnuPG or similar into the application), but the above should be fine for most uses.
Anyways, I do not want to start implementing something like this if there are other, more mature projects out there which do the same...
Why you'd want to do this (other than simple paranoia, or the fact that governments and other institutions are spying on everyone these days, whether they're allowed to or not)? Well, one good reason for SMS encryption is when you're using some kind of SMS gateways, e.g. a website which gives you 2-3 free SMS per month if you sign up with them and give them tons of personal data. That alone is crappy enough, but you don't want their admins to be able to read and store all your SMSes in addition (which consist of simple plain-text, transmitted though HTTP in this case!). Neither should any local or remote scriptkiddy who knows how to use a sniffer be able to read your private SMSes.
Solution: Write the text in your favorite text editor, pipe it through aespipe (for example), cut'n'paste the result in the web form of the SMS service. The receiver does everthing backwards and you're done.
Yet another thing that has been on my TODO list for quite a while: encrypted USB thumb drives and/or encrypted external USB hard drives.
I have finally tried this over the weekend using loop-AES. This is very useful for securing your USB thumb drive contents in case you lose it or it gets stolen. Also, I use an external USB hard drive for backups (previously unencrypted). This is encryped now, too.
Here's a quick HOWTO:
AES encrypted loop device support" in "
Device Drivers -> Block Devices -> Loopback device support", and recompile the kernel.
loop encryption key scrubbing support" as it seems to promise higher security (can anybody confirm that?).
apt-get install loop-aes-2.6-686(or a similar package) should suffice.
apt-get install loop-aes-utils
shred -n 1 -v /dev/sda3.
-n 25or higher if you want more security and have a few days time to wait for the thing to finish...
losetup -e aes256 -C 3 -S 'seed' /dev/loop0 /dev/sda3.
-C 3means "run hashed password through 3000 iterations of AES-256 before using it for loop encryption. This consumes lots of CPU cycles at loop setup/mount time but not thereafter." (see
losetup(8)). This is supposed to be more secure.
-S 'seed'(replace "
seed" with a secret string like "
g7sN4" or something) should make brute force attacks a bit harder. Don't forget the seed!
mke2fs -j /dev/loop0
losetup -d /dev/loop0
/dev/sda3 /mnt/crypted_sda3 ext3 noauto,loop=/dev/loop0,encryption=AES256,itercountk=3 0 0
mount -o pseed=seed /mnt/crypted_sda3
/mnt/crypted_sda3which will be encrypted automatically.
For a more detailed guide read the Encrypted-Root-Filesystem-HOWTO. A performance comparison of different ciphers is available, but in general I didn't notice too much of a slow-down because of the encryption...