# crypto design with AES256 MODE OFB

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)
own entry IV (payload is encrypted with AES256 MODE OFB, IV stored in clear text )
own entry SALT (64bytes random appended to payload before encryption, SALT stored in clear text)
encrypted entry is stored base64 encoded
model a) only passwords are allowed
model b) additional data is allowed

Is it secure to allow multiple keys on the key store if the key store SALT is shared on all keys? (the key store SALT is used for apple crypt function CCKeyDerivationPBKDF which extends the user password to 256bits to be used for AES256)

Can an attacker use the shared SALT for some attack ? (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).

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?

-

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.

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.

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.

-
Thank you very much. You answer does precisely show me, how much I do not know about cryptography. For your suggestions: unfortunately I can not pick the "newer" op modes, I currently stick to those apple provides (which are ECB,CBC,CFB and OFB (to avoid mistakes I would do on my implementation). I choosed OFB because it is currently hard to parallelize from what I understood). The main goal is to make it impossible to guess how many password are used in the store. Additionally increase the pain to brute force the passwords (it will be public domain app to store passwords in a secure manner). – user11942 Feb 12 '14 at 18:12
You didn't do too badly. Using OFB over CBC doesn't add significantly to the adversary's cost, that is taken care of by PBKDF2. It would be good to use something that preserves integrity. You could probably do something like tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-02 using the tools you have. – K.G. Feb 13 '14 at 7:44
Thank you for you comment. The key store is protected by SHA512 hash in clear text (at minimum) or optionally with an key store password encrypted SHA512 hash if the user wishes that (which has some implication on usability because any change must be immediately saved and even changes on clear text data must be authorized by key store password and if the user uses more than one password, he must remember which of these unlocks the SHA512).After all I think I'm too paranoid. – user11942 Feb 13 '14 at 9:34
Usability is important. Nobody wants to type the same password over and over again. Typically, you solve this by remembering the password for some time (or until something happens). Preserving the integrity of the entire database may be a good idea, and may remove the need for per-entry integrity protection, but do use HMAC with a key derived from the passphrase. BTW. It is probably not the case that SHA512 gives you more security than SHA256. Overdoing key size and hash length looks silly. – K.G. Feb 13 '14 at 10:07