2

I'm developing a program in Java. In one step data should be encrypted and exported in a file.

As of now we are encrypting in AES-256

I want to slow down a possible brute force attack as much as possible.

The obvious answer would be to make the users choose long strong passwords. But can we also do something to slow down the algorithm?

My first idea is to run the plain text in a loop decrypting it with AES 2000 times. Any downside to this, besides it will take longer for the user to get the file?

Improve this question

2 Answers 2

Reset to default
6

I want to slow down a possible brute force attack as much as possible. The obvious answer would be to make the users choose long strong passwords. But can we also do something to slow down the algorithm?

As far as the resistance of AES to brute-forcing, it's just fine the way it is. Since it sounds like you're using user-input passwords to generate the key, you should do your key strengthening there by hashing the input key multiple times. See The AES Crypt implementation hashes a password 8192 times to generate the key. Is this necessary? for more info.

Improve this answer
7
  • What is the reason not to slow down the encryption but the derivation?
    – Stefan Rasmusson
    Commented Feb 7, 2013 at 13:21
  • 1
    Different reasons including performance. If your encryption is slow then it means you will have a hard time getting performance for Full Disk Encryption. On the other hand, since AES is practically unbreakable if you don't know the key. It's more interesting to slow down the process of guessing the key. Even if the encryption is slow, once you have the key it's good game. So slow down the key derivation and you will still have good performance to encrypt (since you only need to decrypt it once) and you will also have good security, because if you don't have the key,guessing will take very long
    – Lucas Kauffman
    Commented Feb 7, 2013 at 13:45
  • This is assuming the derived key is saved until the decryption takes place, right?
    – Stefan Rasmusson
    Commented Feb 7, 2013 at 13:50
  • 1
    This is assuming any instance. Guessing the key is generally based on the first block, so to attack it's either 1 pw + (2,000 crypto * 1 block), or it's 2,000 pw + (1 crypto * 1 block). However, if you're encrypting / decrypting the whole file, change the block count and see how different the numbers become and you'll see why iterating the password is preferable.
    – Jeff Ferland ♦
    Commented Feb 7, 2013 at 13:56
  • I would like to try out how bad my first solution was which just used 2 iterations. Any of you know a good tool to brute-force/guess the original password and decrypt the file? Typically, what would an attacker us to break this?
    – Stefan Rasmusson
    Commented Feb 7, 2013 at 15:14
2

Brute force is about trying all possible keys or passwords. AES uses keys of at least 128 bits (256 bits in your case) so that brute force fails: it is not feasible, with existing or foreseeable technology, to "try out" a non-laughable proportion of the space of possible 128-bit keys, let alone 256-bit keys.

A more effective brute force attack would try potential passwords which are often from a much smaller space of possible passwords (the space of passwords that a human mind can come up with). This is called a dictionary attack. To make such attacks less effective, you will want to use some slowdown in the process, either in the password-to-key transform, or in the encryption itself. It makes more sense, and is much better for security, to do the slowdown in the password-to-key transform, rather than in the encryption. See this answer for details.

Slowdown is only part of the story; you also want a salt. This points to bcrypt or PBKDF2. And you will also need some checked integrity, to defeat active attacks (which are more realistic than usually assumed). Combining a good password hashing, symmetric encryption and checked integrity is not as easy as it seems, so you should rely on an existing standard and library which does the job and has been scrutinized by many specialists. You could do worse than using OpenPGP and the BouncyCastle Java implementation.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .