Is it safe to store both the AES-related data and the PBKDF2-related data (except passwords) in one file?

Question

Assume an "encrypted data package" file format which includes the following data

• PBKDF2

  • algorithm
  • salt
  • rounds
  • keylen

• AES

  • algorithm & mode
  • IV
  • ciphertext

where the PBKDF2 salt and AES IV are generated using a CSPRNG upon individual encryption.

This would make the individual password (used as PBKDF2 input parameter) the only seperately stored data (secret to the "encrypted data package" file) which is stored in a secure place.

Is it safe to store both the AES-related data and the PBKDF2-related data (except passwords) in one file, or are there any cryptographic implications when doing so? If there are implications, what would be the advantages (from a security point of view) of storing the PBKDF2 data separately from the AES data?

When describing potential pitfalls, it would be nice when answers would assume and expand on the following two scenarios:

1. AES-256-CTR, with the PBKDF2 parameters simply prepended to the ciphertext, and
2. AES-256-GCM, with the PBKDF2 parameters fed into the AES mode as associated data.

---

Think of this more as a canonical question, hinting at

• *“Do seperate storages resemble security by obfuscation?” and
• ”What's the minimum data we would need to store in a secure location, and what other data can we safely store next to the ciphertext 'out in the open' so that we don’t introduce cryptographical problems?”

Answer 1

All the parameters you've mentioned can be public. Furthermore, only the salt, IV and ciphertext cannot simply be guessed.

The IV is generally easy to retrieve once the key is known, so the making the IV secret doesn't make sense. In CBC mode and many other modes you may just not get the first plaintext block if the IV is completely absent, but the rest of the ciphertext will be available. In CTR mode you would get the IV directly once the key is known and if part of the first plaintext block is known.

So that basically leaves the salt. Now the salt is sometimes kept partially secret. This static, secret part is called a pepper. If you keep this secure then it can be seen as an additional input key that is required to generate the resulting output key. There still should be a random or at least unique salt otherwise identical passwords will result in the same key, which is definitely something you would want to avoid.

---

TL;DR you could use a pepper which sometimes makes sense if the pepper has different access requirements. All the other information can simply be stored with the ciphertext (but read on).

---

Note that there certainly is a danger when storing the algorithm with the ciphertext. The problem is that if an attacker can switch the algorithm from GCM to CTR that you suddenly get unauthenticated plaintext. You'd better make sure that an attacker cannot simply change a few parameters to make your protocol less secure.

That would be a lot more dangerous than storing any of these public parameters together with the ciphertext.

---

If you decide to use authenticated ciphertext then yes, please make all the parameters part of the Additional Authenticated Data (AAD). Note that all AEAD modes already include the IV in the verification, so there is absolutely no reason to include it in the AAD.