crypto design with AES-256 MODE OFB
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):


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


Q&amp;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.))


Choose a salt $s$.
Use PBKDF2 (or something similar) to derive a key $k$ from $s$ and $pw$, using a suitable number of iterations.
Encrypt each secret as $c_i = \mathrm{AES{-}GCM{-}}\mathcal{E}(k, i || t_i, m_i)$.
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.