3

I'm working on a project to build software for file encryption with AES in Java, it's operation is quite simple, but I was wondering if it is really safe.

The program prompts the user for a passphrase to encrypt the selected file, after entering the passphrase, it's secured with a Key Derivation Function PBKDF2 With Hmac-SHA256, salt is a Pseudorandom Number Generator to 8-byte SHA1 PRNG, iterations are 100,000 and key length is 256-bit.

The secure key generated is used to encrypt the file. The Initialization Vector for the AES is a Pseudorandom Number Generator of 16 byte SHA1 PRNG, the file is now encrypted.

The first 16 bytes of the encrypted file is saved to the IV and for the past 8-bytes to store the salt of PBKDF2.

The salt and IV are not encrypted along with the files, but are added later. Are these operations are safe?

Thealexzava
  • 33
  • 5

1 Answers1

6

First: Please don't roll your own crypto.

If you're doing this for production purposes I've to strongly recommend against using it. If it you want to improve your programming skills or this is a smiliar research project, it's fine as long as you do not expect strong (professional) security from it.

Now to the actual points which are improvable on what you gave here (in order of appearance in the post):

  • PKCS#5 PBKDF2 with HMAC-SHA-256. Please. PBKDF2 is an old standard for password based key derivation and should be replaced by at least bcrypt or even better Argon2. Also see our canonical answer on password hashing.
  • 100,000 iterations. Please don't hard-code the iteration count but rather dynmically find it at run-time depending on what the CPU can do. This is especially true if you don't know your exact target platform and if your software will be around for some time. TrueCrypt also fell about this issue.
  • 8-byte salt. While an 8-byte (=64-bit) salt may be fine, a 16 byte (= 128-bit) salt is a better choice, to prevent pre-computation attacks on the limited range of salts.
  • SHA-1-PRNG. You didn't give any details about this one. This looks OK, but you should upgrade if possible (to SHA-256 or SHA-3), to avoid SHA-1 which is still OK for running a PRNG but may shine a bad light on your tool for using such an old and "broken" algorithm.
  • 16 byte IV for AES. Note while this is the appropriate choice for CBC, CFB, CTR, OFB, ... (i.e. all unauthenticated encryption modes) it usually isn't the appropriate choice for authenticated encryption modes which require a 12-byte nonce for optimal security. If you can guarantee unique keys (which it looks like you can), you can let the nonce default to all-zero.
  • AES/CBC/PKCS5Padding. This would be an OK choice (not a good one!) if you'd have some means to authenticate the message (i.e. confirm it hasn't been tampered with). You don't, so the better choice would be to use an authenticated encryption scheme like AES-GCM, AES-CCM, AES-EAX, ...
  • The associated data (salt + IV). First, you can let the IV default to some value (all zero?) if you files stay small (less than 68GB) and use AES-GCM. Second, you should authenticate this data as "associated data" and add an authentication tag (in clear) at the end of the file (decent libraries will do that automatically). If you were to use this is as it stands, an attacker (who knows the first block) could change the IV to make the legitimate user decrypt a plaintext of the attacker's choice. Additionally you'd want to add the key derivation parameters (like iteration counts, time and space parameters and other configuration) to your associated data to ensure long-term adaptibility of the format.
SEJPM
  • 9,540
  • 6
  • 37
  • 67
  • 1
    Note that if you use a variable iteration count (which you should), you will need to store the iteration count with the file so you can re-derive the key correctly for each individual file later. This also applies if you use different key derivation functions; they all have some sort of "work factor" which you'll need to store with the encrypted file. – CBHacking Mar 02 '16 at 19:55