Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I'm reading that AES uses 4x4 bytes (4*4*8 = 256 bits key) matrix for performances matters (since it's a requirement for common standard encryption algorithms), but are there implementations with choosable key size for this particular algorithm, so I can make brute-force attacks harder with a good password ?

Also, if I'm worried that I can't make user use good passwords (it's a shame, but lets imagine that), can I make an algorithm deliberately slow to make brute-force attacks infeasible with weak passwords, but really secure ?

Could we one day make users switch to key files instead of passwords to completely forget about brute-force, even with the potentially theft of those keys ?

share|improve this question
    
Actually, AES comes in three versions: 128, 256 and 512 bits of keysize. This is what was wanted in the competition. –  Paŭlo Ebermann Aug 20 '11 at 23:47
1  
About using passwords, see other questions tagged passwords here. Most are about password storage, but when using them as a key you would want to use similar measures. –  Paŭlo Ebermann Aug 20 '11 at 23:49
    
When you ask about other implementations, do you mean other implementations of AES, or other crypto-systems? –  user476 Aug 20 '11 at 23:54
    
@Bill: both. AES is made for performance, but I just want to know "what if we make a slower system so it can resist bruteforce ?" –  jokoon Aug 21 '11 at 0:11
    
@gokoon - As Paulo said, there are 128, 256 and 512 bit versions of AES, as this was the requirement of the competition. If you want an example of another cryptosystem that offers greater security than AES, have a look at Lattice-Based cryptosystems as these have been known to resist quantum attacks. Unfortunately, the key sizes required to make them secure do not make them practical. As for your other questions, there should be some password checker/management software that prevents users from entering weak passwords. –  user476 Aug 21 '11 at 0:23
add comment

2 Answers 2

Bruteforcing the AES algorithm itself (i.e. trying all possible keys to encrypt or decrypt some blocks to see if they give the right result in a known-plaintext attack or similar) is not really a problem, even in the 128-bit key version.

(This takes on average 2127 tries. If you can try 230=109 AES-keys per second, it will still take around 5·1021 years, much longer than the universe existed, and any life will exist. Parallelizing this makes it faster, but there is some limit, too ... if you can calculate on 109 processors in parallel, it still needs 5·1013 years ... about three times the estimated age of the universe until now.)

So, the attackable point is not bruteforcing the AES key, but bruteforcing the derivation of a key from a password. And here is where we have to enforce our design. You should not use the password directly (maybe with padding) as an AES key. Instead, use a slow password derivation function, and incorporate some salt.

NIST proposes the PBKDF2 construction based on iterated calling of some fast hash function. Setting the iteration number high enough will make it slow enough. PBKDF2 is easily parallelizable on GPUs, which makes brute-forcing slightly faster than we would wish, though.

Other alternatives might be , or the newer scrypt.
These are firstly slow hash functions for secure password storage, but I think one can also reuse their output as a key for AES or any other symmetric cipher of the right key size. (You just have to think of a protocol to transfer the salt.)

share|improve this answer
add comment

The way to solve this problem is to use a well-chosen function for deriving the key from the password. You should use PBKDF2, bcrypt, or scrypt to derive the key from the password, and set the number of iterations to make them very slow (e.g., to make them take 100-200 milliseconds on your machine). Once you've done that, you don't need to make any changes to AES. This is an elegant way to solve the problem: you decouple the problem of making password search hard, from the problem of building a secure encryption algorithm.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.