System encryption LUKS: What's the strongest and most secure key size?

Question

I'm reading an article on the Arch Linux wiki about system encryption, in an example the author specified a 512 bit key. From what I read on Wikipedia regarding encryption ciphers it doesn't seem to be secure enough. That leads me to the question: what's the strongest possible key size?

Solution 1

I don't have enough reputation to comment on the above answers concerning RSA, but they're both wrong in the context of the question asked, so for all people who happen to read this question in the future:

LUKS uses symmetric ciphers (encryption and decryption use the same key). RSA is an asymmetric cryptosystem, which uses a key to encrypt and another to decrypt. To make this possible, it uses a neat piece of mathematics. Its security is based on the difficulty of factoring large numbers. This is why the key size for RSA must be thousands of bits (otherwise the numbers involved are not large enough and can be factored in acceptable time given an attacker with enough resources).

Symmetric cryptosystems like LUKS do not need the same large key sizes because the keys are not tied to a number that can be factored to break the encryption. Therefore they are considered safe with much lower key sizes. Currently 128 bits are considered safe. AES, the standard algorithm for symmetric crypto, also supports 256 bits in case you're paranoid.

It would take 2ⁿ tries to exhaustively search the keyspace of a symmetric cipher, where n is the length of the key in bits.

To give you an idea of the scales involved: If you had 10 million computers who could each test 10 million keys per second, it would still take several thousand times the current age of the universe to search all of the keys for a key size of 128 bits.

This means you're safe from a brute-force attack, no matter who the attacker is. Brute-forcing a symmetric key is not the way to go. Even attacking weaknesses in the cipher is difficult when you use high-quality ciphers like AES, etc, although the NSA might have some insights that the rest of the world doesn't have. But frankly it is way easier to hit you over the head with a large stick until you give up the passphrase.

Solution 2

There isn't any strongest possible key.

For each key of length n you can always add one bit to make it stronger.

Solution 3

RSA itself contains weaknesses, as see RSA Algorithm section "Weaknesses in RSA", as well as Cracking RSA and RSA: Hacking and Cracking.

That said, and if the method being used to crack your encryption is only brute force, then the strongest possible key size is the one that will require more computing power than is available to the hacker that is trying to decrypt your messages, or more time than he is willing to spend.

Recently, a 200-long RSA key was factored in 50 years of computer time, and 307-long in 100 years of computer time. I suppose even 128-bit will still take a few years of computer time.

1024 bits might be proof against most crime-rings, but so are probably 512-bits and even 128-bit. 1024 bits is surer, but do you expect an agency with the computing-power of the US National Security Agency to be used against you ?

If all you are trying to protect yourself against is the neighborhood script-kiddo, then 128 bits are enough. If you are trying to protect your bank transactions, then no hacker wastes his time trying to decrypt RSA, but rather will try to trick you into installing his trojan.

Solution 4

As part of a starting point, measuring performance of encryption types on the system you plan to use may aid in a feasible decision.

cryptsetup benchmark

View more solutions

Comments

[user1686]

See also: rubber-hose cryptanalysis (obligatory xkcd)

[Cry Havok]

And ultimately the weakest link will almost always be the passphrase chosen.

[Apache]

@Peter - You can also use TrueCrypt for a 3-striped encryption if you are that paranoid. (But yes, the key is THE most important part.)

[Peter]

@Shiki - I've been thinking of using TrueCrypt, however it seems more suitable to use LUKS for Arch Linux. It also seem more easy to map partitions and have them mounted in the proper order. But if TrueCrypt is preferable, I'll check it out again. Thanks.

[Apache]

@Peter - The maximum allowed? :) (Just don't forget it.. lol)

[Peter]

@Shiki - Then what's the preferable cihper and it's maximum key size? As you've probably noticed, I don't know so much about stuff like this. Maybe I should use TrueCrypt anyway? It does seem more user friendly but less flexible. Is it possible to have it automatically decrypt all the other partitions when you decrypt the root-partition? That's possible when using luks.

[Jürgen A. Erhard]

Depending on algo, you can't just make keys longer and thus make them more secure. Of course, the maximum supported size (for a well-tested/analyzed algo, of course) is "the most secure".

[Peter]

Then what's the most preferable cipher? The example I mentioned before in the Arch Wiki uses aes-xts-plain. Would that be a good choice along with either a 1024 or 2048 bit sized key? Thanks.

[FJ de Brienne]

If you have a nice powerful machine (anything modern should do fine) then go for 2048. If your machine is a little older (say a P3) then don't go above 1024 bit.

[Apache]

@Peter - You can use a poem, with spaces and special characters. Also add some number at the end, so on. That should work. You can remember it, even have a 'source' if you forget about your key, so YOU can figure it out what is your key.

[Apache]

@Peter - Also, I think TrueCrypt is more user friendly, but that may be just my opinion.. beats me. Give it a try. TrueCrypt is much more "clickety-click".

[DrColossos]

Good point, many people are confused about the difference between symmetric and asymmetric. And good job with this first post!

[bertieb]

Welcome to Super User and thank you for your contribution. OP however asked "what's the strongest possible key size"

[Carlo Wood]

However, at some point you reach so much information that, when stored inside a PC of average dimensions, it collapses into a blackhole. That means you can't recover (decrypt) the data anymore, so I'd say that is definitely an upper limit.