I benchmakerked them also about two years ago. At that time anibus encryption, xtc and lrw modes didnt exist in the kernel. I concentrated on 256 bits for AES, Serpant and Twofish. I dont recall the exact numbers, but this is the order from slowest (and also most secure) to fastest:
The tests were run with bonnie++
I recall something like a 20% penalty for using CBC versus ECB on any variant. If your going to encrypt many times, you might want to consider only using one agressive mode and you might want to consider leaving the other encryption instances with ECB
I am interested to see what the results are for LRW and XTC compared to ECB and CBC.
On Friday February 29 2008 7:48 pm, Dan Reidy wrote:
> On Wednesday 27 February 2008 01:58:11 pm Florian Philipp wrote:
> > Hi!
> > I just did some benchmarking on different ciphers for cryptsetup-luks
> > and now I've got some questions:
> > 1. Is it a valid way to benchmark by using "time dd if=/dev/zero
> > of=/dev/mapper/cryptmapping -bs=1M"? The results seem to match other
> > benchmarks but I just want to be sure.
> > 2. I've tested every (sensible) cipher with 64, 128, 256 and 320bits
> > keysize (if supported). Apparently I can choose between:
> > Blowfish 64-256bit
> > Twofish 128-256bit
> > AES 128-256bit
> > Anubis 128-320bit
> I've never done any benchmarks myself, however a few years back I did read
> up on which crytpo engine would be best for a large hard disk or partition.
> I do remember clearly that there is a bug in AES's block cyper that causes
> it to repeat keys on large disks/partitions. This "feature" could make it
> easier for your key to be cracked. I personally use Twofish 256 with
> SHA256, ive never tried any other hash method. I also use Serpent on my
> swap, for no other reason than to try something different - and it's a cool
> name. (flame on!).
> I tried to find that link that explains that AES flaw, but to no avail.
> Maybe you'll have better luck if it's something that concerns you.
> ps. i am obviously no expert in cryptology - take my comments with a grain
> of salt.