Low Speed CPUs without AES: Preferred Algo & Key-Length?

I have a couple of "older" netbooks and laptops (like Acer Aspire One 753, Asus Eee PC 901GO, IBM ThinkPad T42p), and since I consider disk encryption essential on mobile computers, I am wondering which algorithm & encryption-key-length are best suited for such low speed CPUs without hardware AES.

In the handbook and manpage AES-XTS is mentioned as the default and recommended algo with a key-length of 128 bit.

Should I stick with the default, or would anybody recommend AES-CBC instead?

Is the performance impact noticeable choosing a key-length of 256 instead of 128 bit?
 
AES-XTS is considered to be most secure, still along with all of its implementation issues.
AES-XTS 256 is still more secure than AES-XTS 128 given proper key length. None of the new attacks are still computationaly feasable unless some information about keys is already known. Remember that there is no any guarantee against a weak password key.

As for the speed, AES-XTS 256 will be slower, but not by much, which begs the implementation question.

As for some practical examples with/without hardware acceleration check post here.

Keep in mind that something secure now might not be in 5-10 years, which for most people is not relevant.
 
I wasn't exactly sure, if the recommendation for AES-XTS is still up-to-date, because I read somewhere (must have been something about NAS4FREE, where the AES-CBC options seems to have been added just recently) that AES-CBC is newer and can offer slightly better performance.

I don't have super high secret documents to protect, but I am just not comfortable to have any mobile devices with unencrypted data storage.
 
There are design considerations which make AES-CBC more susceptible to certain attack vectors compared to AES-XTS. However, AES-CBC is considerably faster. For a random laptop, my guess is anything that is thwarting a would be attacker an easy access to stolen disk is good enough.
 
In cryptography you do better not to compromise for performance. All algorithms of GELI should be able to hold up an attacker for a considerable time, but out of those algorithms IIRC Blowfish withstood reduced rounds attacks best so far.

If you go for AES, use 256 bit block size. It's only about 30% slower then 128 bit one and "doubles" the cryptographic strength.
 
AFAIK concerning encryption algorithm Debian Linux defaults to AES-CBC, and Openbsd to Blowfish, so with FreeBSD on AES-XTS there are three different preferred algos. As said, I have nothing against the default selection, and I do not have special security needs, it's just to choose the most practical combination of algo & key-lengths for my "older" low speed mobile computers without hardware AES support.
 
@MasterOne

I do not have aesni capable CPU (Core 2 Duo), so I use 128 bit AES-CBC, here are the results on SSD:

Code:
% [B][color="Blue"]dd < /dev/zero > ~/FILE bs=8m count=200[/color][/B]
200+0 records in
200+0 records out
1677721600 bytes transferred in 21.483876 secs (78092128 bytes/sec)

% [color="blue"][B]dd < /dev/zero > ~/FILE bs=8m count=200[/B][/color]
200+0 records in
200+0 records out
1677721600 bytes transferred in 31.257991 secs (53673367 bytes/sec)

So its about 50-70 MB/s.

Earlier I used 256 bit AES-XTS and the performance was about 20 MB/s.
 
xibo said:
If you go for AES, use 256 bit block size. It's only about 30% slower then 128 bit one and "doubles" the cryptographic strength.

While the Rijndael algorithm that AES is derived from does support 256 bit blocks, the AES standard only supports 128 bit blocks. AES does support key sizes of 128, 192, and 256 bits. So far, the cryptanalytic results do not bear out the assumption of double the cryptographic strength of AES-256 over AES-128.

In any case, brute forcing an AES key is still considered impractical (in 2012).
 
vermaden, that's quite a difference in performance. I guess I really should stick to 128 bit key-length, I don't want the harddisk to be even more the bottleneck it already is.

Obviously I am no crypto expert, and without studying the topic, I am still wondering about the reasons for choosing AES-XTS vs. AES-CBC vs. Blowfish as the preferred algo (I mean why devs of three different projects think their selection is suited best). Someone with the proper knowledge should be able to clearly tell which of the three is suited best for the task of block-level-encryption, after all it just comes down to technical specifications.

Can somebody tell anything about Blowfish in that context?
 
The problem with choosing crypto is that you need to have assurance that the selected cryptosystem will not give up your secrets until they are essentially irrelevant. Who cares if it only takes your enemy 2 hours to decrypt your order to attack their command post in 15 minutes?

AES-CBC is faster, but not considered quite as secure as AES-XTS.

Nobody has successfully cryptanalyzed Blowfish, maybe partly because it has not become hugely popular. Blowfish is reasonably fast, except when setting up a new key. Key setup is considered to take about as long as encrypting 4K of plaintext. This makes it pretty good for password verification because it takes a long time to check huge numbers of passwords. The OpenBSD folks use it for that. Maybe their experience with it led them to decide it should be used for disk encryption, too. Also, their stated bias is for security in preference to anything else, including performance.

The creator of Blowfish, Bruce Schneier, no longer recommends its use in new systems/applications. Others have cited concerns that the short (64-bit) block size might be a problem in applications with large amounts of plaintext, e.g. data archiving.
 
Blowfish was the fastest secure block cipher on scalar 32 bit CPUs in 199x. It's still a good cipher on similar CPUs unless you need a larger block size or fast key scheduling. Block level disk encryption requires very fast key scheduling because most modes of operation require one key schedule operation per block access (read or write). The given the common sector size for GELI is 4KiB the Blowfish key schedule will take about the same time as the decryption/encryption of a whole sector. AES avoids with (too) fast key schedule algorithm. Modern 64 bit out-of-order super scalar CPUs are also limited by the data dependencies in Blowfish's round function and heavy use of 32 bit memory accesses.
 
These performance comparing between AES-XTS and AES-CBC is meaningless though, because FreeBSD-9 does not support AES-XTS to begin with. I just found this when browsing the geli() code in search for iv modes:

sys/geom/eli/g_eli_crypto.c:220:
Code:
	/* We prefer AES-CBC for metadata protection. */
	if (algo == CRYPTO_AES_XTS)
		algo = CRYPTO_AES_CBC;
which gets emphasized by

sys/geom/eli/g_eli_crypto.c:72:
Code:
	KASSERT(algo != CRYPTO_AES_XTS,
	    ("%s: CRYPTO_AES_XTS unexpected here", __func__));
 
Back
Top