First, I create a 500 MBytes file full of random bytes:
dd if=/dev/urandom of=/tmp/foo bs=1000000 count=500
then I encrypt it using GnuPG, measuring the time taken by that process ("
keyID" is the UID of the public key I am using):
time gpg -r "keyID" --cipher-algo AES256 --compress-algo none -o /tmp/bar --encrypt /tmp/foo
Total time on my machine (Intel i7 at 2.7 GHz, 64-bit mode, GnuPG 2.0.22):
3.77s user 0.55s system 99% cpu 4.328 total
so an encryption bandwidth of 115 MBytes per second: that's not so bad ! Now let's try again, but this time without deactivating the compression (i.e. let's remove the "
--compress-algo none" options):
20.99s user 0.79s system 98% cpu 22.038 total
which is 5 times slower. So there you have it: it is not the encryption which is "slow", it is the compression (although more than 20 MB/s can still be decently fast for many usages).
115 MB/s is consistent with a "portable" implementation of AES. Code which uses the specialized AES opcodes (which are available on my i7) would be faster, up to, say, 300 to 400 MB/s (though AES-NI opcodes have a very high throughput, they also have a non-negligible latency, which means that the best performance requires parallel processing, i.e. CTR mode; but the OpenPGP standard mandates CFB, which is sequential).
Anyway, since a good mechanical hard disk tops at about 120 MB/s, while a very good Internet access (optic fiber) will be below 10 MB/s, one can say that 115 MB/s of raw encryption speed is sufficient.