3

For a Java application that I wrote, I take a password provided by a user and generate a 128-bit AES key from it using 100,000 iterations of PBKDF2-HMAC-SHA512 with a randomly generated 512-bit salt. I use this key to encrypt a file using AES-CBC mode encryption and then I do something with that encrypted data.

What bothers me is that it seems like someone could just generate passwords and then decrypt the first couple of bytes of the cipher-text and see if non-garbage comes out.

Am I being paranoid or is there extra work that can be done?

For example, is there a mode of AES which prevents partial decryption of cipher-text? Or anything else that slows down the process of testing lots of keys?

Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90
Lezorte
  • 133
  • 3
  • "Or anything else that slows down the process of testing lots of keys?" - That's what PBKDF2 is for (except passwords, not keys). – AndrolGenhald Jul 18 '18 at 19:54
  • I guess I don't quite understand what PBKDR2 is really doing besides converting a password to a 128-bit AES key. What is it doing to slow it down? – Lezorte Jul 18 '18 at 20:04
  • That's what the iterations are for, take a look at Wikipedia for [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2) and [key stretching](https://en.wikipedia.org/wiki/Key_stretching). – AndrolGenhald Jul 18 '18 at 20:13

2 Answers2

2

The ability to decrypt a portion of the ciphertext is not critical.

It is common practice, for example in disk encryption programs, to add a fixed (known) string to the ciphertext and thus check if the password fails. Regardless which mode you are using, this would not be the critical point.

CBC mode has only one significant weakness: CBC mode does not prevent tampering attacks, that means, an attacker who guesses a part of the ciphertext, is able to modify it according to its purposes. If available, use GCM, EAX, CCM or OCB mode.

BeloumiX
  • 246
  • 1
  • 5
  • Correct me if I'm wrong but CBC mode is XOR with the previous block followed by encryption. Even if I know about the plain text (or even cipher text which is visible anyway) of one block, it's impossible for me to modify it without breaking it and changing the same amount of bits in the following block. – GxTruth Jul 19 '18 at 07:01
  • 1
    @GxTruth correct, though changing a bit in the ciphertext of a block will completely scramble the plaintext. The problem is if you have a block of data that doesn't matter (at least in that it doesn't cause the program reading it to crash) followed by an important block, and you can predict what data is where. See for instance [here](http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/), since the plaintext is known a binary can be altered with the scrambled blocks skipped by `jmp`s. – AndrolGenhald Jul 19 '18 at 12:46
  • Very interesting post @AndrolGenhald, thanks for that. I was not aware how well this can actually work. +1 – GxTruth Jul 19 '18 at 13:24
  • @BeloumiX Thanks for the explanation. Out of the four modes that you mentioned, is any one of them used more often than any of the others? – Lezorte Jul 19 '18 at 21:28
  • @Lezonte OCB has probaly the best performance, but you can only use it freely for open source projects. Some people think, EAX has the highest security margin. GCM is used at most, I think. Any of them is OK. – BeloumiX Jul 20 '18 at 08:01
-1

is there a mode of AES which prevents partial decryption of cipher-text

I claim to be no expert in cryptography, but my understanding of chain block cipher (CBC) is it has weaknesses primarily caused by lack of authentication. Although, because its initialisation vector (IV) is a fixed value (IV predicability), this IV outputs the last block of the ciphertext. You can view how different AES implementations conceal data about an image "Text partially decrypted regardless of IV".

"Decrypting with the incorrect IV causes the first block of plaintext to be corrupt but subsequent plaintext blocks will be correct. This is because each block is XORed with the ciphertext of the previous block, not the plaintext, so one does not need to decrypt the previous block before using it as the IV for the decryption of the current one." - Block cipher mode of operation

Galois/Counter Mode (GCM) is often thought of as GCM = CTR + authentication. AES-GCM with proper IV implementation is considered more secure than other AES alternatives. GCM is preferred because it's a faster algorithm and unlike CBC, GCM supports authentication. However, GCM "if you reuse a nonce. A single repeated nonce allows an adversary to recover its authentication subkey, plus to learn the XOR of the two messages with the same nonce." which is obviously not ideal. Also, GCM uses 96 bits IVs, making collision rates higher and IV reuse potentially more frequent.

This thread How to choose an AES encryption mode? should assist as it outlines different AES implementations, which should allow you to choose which is appropriate for your infrastructure.

Although, despite all this, I would opt for CBC for local storage. GCM has felt more for network (real time) encrypted communications.

Or anything else that slows down the process of testing lots of keys

I will presume by keys you refer to passwords. Where you want to pass the passwords through a one-way hashing function with multiple iterations (rounds) for storage by something (likely database).

Password hashing seems more important. I have read multiple disputes regarding using SHA-2 family for password hashing, most criticism comes from SHA-2 not performing multiple iterations, something you have already done, but this does not concern your scenario directly as you are using PBKDF2 with HMAC SHA512. However, I would review what type of system your potential attacker has, and implement a modern hashing algorithm to protect against that. E.g. do they use CPU, GPU or ASIC to brute force the PBKDF2. Argon2 has been known for good resistance against most brute forcing attempts. Comparing the three Argon2 algorithms:

  • Argon2d: best protection against GPU brute force.
  • Argon2i: optimised to resist side-channel attacks. It accesses the memory array in a password independent order.
  • Argon2id: a hybrid of Argon2d and Argon2i.

All three modes allow specification by three parameters that control:

  • execution time
  • memory required
  • degree of parallelism

These specifications should be considered for all password hashing algorithms. PBKDF2 is a known, and recognised hashing function which is considered to be secure for password hashing. However, it's recognised as being weak against an ASIC brute force.

I would choose between Argon2id or PBKDF2 HMAC SHA512, and evaluate depending upon which type of attacker I am defending against.

safesploit
  • 1,827
  • 8
  • 18
  • 1
    You need to read up on IVs, "this IV outputs the last block of the ciphertext" makes no sense to me, and "its initialisation vector (IV) is a fixed value" is a clear misunderstanding. The IV should be generated randomly, but is then generally included with the ciphertext. This does not mean that the IV is a fixed value or that it is predictable. A fixed or predictable IV would mean using the same IV (or a predictable IV) for multiple plaintexts. – AndrolGenhald Jul 18 '18 at 21:44
  • 1
    PBKDF2 is not a cipher, it is a key derivation function, (a Password Based Key Derivation Function). – AndrolGenhald Jul 18 '18 at 21:47
  • A fixed IV, indicating that it increments: x1,...,xN. [ https://link.springer.com/content/pdf/10.1007/3-540-46035-7_35.pdf ] and [ https://security.stackexchange.com/questions/9113/incrementing-initialization-vector-by-1 ] . For the cipher, I was under the impression cipher was defined as "a disguised way of writing a code" (which would allow room for one-way functions) clearly not relevant within computer science, which stats "encryption and decryption" must be available. – safesploit Jul 18 '18 at 21:57
  • I have no idea what your first reference is about, but your second link is a question about what would happen if you use CBC mode _incorrectly_ by using a non-random IV. The fact that CBC breaks if you use a non-random IV doesn't mean that CBC is always bad, it just means you have to use a random IV. – AndrolGenhald Jul 18 '18 at 22:04
  • The first citation gave in-depth analysis of CBC padding. And I was not necessarily saying CBC is bad. This said I frequently use it. However, I was making a clear statement of weaknesses it posses as it had relevance to the question " is there a mode of AES which prevents partial decryption of cypher-text" as I wanted @Lezorte to make an informed decision for the ideal AES implementation for their requirements. – safesploit Jul 18 '18 at 22:11
  • Why are we talking about padding now? The issue is that you say CBC uses a fixed IV. This is either factually incorrect, or at the very least extremely misleading. – AndrolGenhald Jul 18 '18 at 22:29
  • I think perhaps the misunderstanding is with the definition of IV, there is only 1 IV for a ciphertext. It's the _initialization_ vector, it's only needed for the first block. The encrypted block isn't "used as the IV for the next block", it'd be more accurate to say "the IV is used for the first block since there is no previously encrypted block." – AndrolGenhald Jul 18 '18 at 22:34
  • I have removed that section and left the citations. So others can derive the information regarding weaknesses of CBC, for their own evaluation. – safesploit Jul 18 '18 at 22:46
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/80360/discussion-between-androlgenhald-and-safesploit). – AndrolGenhald Jul 18 '18 at 23:44