crypto design with AES-256 MODE OFB

Question

I have the following APP Design

• key store (contains 1:n user payload as 1:n key store entries)
• key store salt (is used to extend to key store password to 256 bits, stored in clear text)

• key store entry (what the user wants to encrypt) with:

  • own entry IV (payload is encrypted with AES-256 MODE OFB, IV stored in clear text )
  • own entry SALT (64 bytes random appended to payload before encryption, SALT stored in clear text)

The encrypted entry is stored base64 encoded:

• model (a): only passwords are allowed
• model (b): additional data is allowed

Here the additional data may be comments / remarks in the users language, links or email addresses.

The key store SALT is used for apple crypt function CCKeyDerivationPBKDF which extends the user password to 256 bits to be used for AES256.

1. Is it secure to allow multiple keys on the key store if the key store SALT is shared on all keys?

The number of used passwords is not detectable as the application accepts every entry as valid. You must decide on the decrypted information if the key is valid or not. This is also true for the user who should know the correct password.

2. Can an attacker use the shared SALT for some attack?

3. Is there a security risk when I use model (b) which allows the attacker to guess, that there is user language (or links / email addresses) in the encrypted entry?

Answer 1

Problem statement

You have a list of messages $(m_1, m_2, \dots, m_n)$, possibly with corresponding tags/descriptions $(t_1, t_2, \dots, t_n)$, that you want to store. You want to protect confidentiality of the messages (but not the tags/descriptions) against an adversary that compromises your storage. You have a single secret passphrase $pw$ at your disposal.

The adversary may know/be able to guess part or all of some or all of the messages.

Your solution

What you propose (based on AES-OFB, $c = \mathrm{AES{-}OFB{-}}\mathcal{E}(k, m)$, $m = \mathrm{AES{-}OFB{-}}\mathcal{D}(k,c)$, the encryption algorithm generates the IV and includes it with the ciphertext; your software may have a different interface):

1. Generate a salt $s_0$.
2. For each entry, generate a salt $s_i$.
3. For each entry, compute $k_i = \mathrm{PBKDF2}(pw, s_0 || s_1, \mathit{iterations})$.
4. Compute $c_i = \mathrm{AES{-}OFB{-}}\mathcal{E}(k_i, m_i)$.
5. Store the two lists $(c_1,c_2, \dots, c_n)$ and $(t_1, t_2, \dots, t_n)$.

Q&A

Q: Do you need the per-entry salts? A: No. The salt is there to keep the per-passphrase search cost high for attackers that have compromised the stores of many users. The salt $s_0$ is sufficient.

Q: Is it a problem that the adversary can guess/know part of the message? A: No. AES-OFB provides confidentiality against chosen plaintext attacks.

More than you asked for

You shouldn't be doing this kind of design on your own, nor should you rely on advice given on a random web site.

• Don't think that the adversary won't be able to recognize correct passwords.
• Don't assume that the user will be able to recognize an incorrect decryption.
• Don't use OFB mode. It is sometimes inefficient and does not provide integrity.

The following natural proposal is better than yours (based on AES-GCM, a symmetric encryption scheme that encrypts messages and protects the integrity of associated data as well: $c = \mathrm{AES{-}GCM{-}}\mathcal{E}(k, ad, m)$, $m = \mathrm{AES{-}GCM{-}}\mathcal{D}(k, ad, c)$. (Note that I am assuming that the encryption algorithm generates a fresh IV/nonce for each encryption and attaches it to the ciphertext. Your software may have a different interface.))

1. Choose a salt $s$.
2. Use PBKDF2 (or something similar) to derive a key $k$ from $s$ and $pw$, using a suitable number of iterations.
3. Encrypt each secret as $c_i = \mathrm{AES{-}GCM{-}}\mathcal{E}(k, i || t_i, m_i)$.
4. Store the two lists $(c_1, c_2, \dots, c_n)$ and $(t_1, t_2, \dots, t_n)$.

PS. Don't use a scheme you got for free on the internet.