How to safely use a Key Derivation Function to secure private data - need guidance

Question

I have some secure data created in my client app which I wish to store on the server as backup for the user.

The user already has a password to authenticate with the server. The password is never sent to the server (I use SRP6 to authenticate the user).

So here is my thinking...

1. Use Fortuna PRNG with multiple event inputs (mouse, keyboard etc) to generate a salt.
2. Use salt and password as inputs to either Scrypt or PBKDF2+SHA512 with 40,000+ iterations to generate a 512-bit key.
3. Use the first 256 bits of the key to encrypt the private data using AES-256-CBC with random IV.
4. Send the ciphertext and salt to the server.
5. Show the user the KDF iteration count as a number they need to memorize. We will ask for it when we need to decrypt the data client-side later on.

So my question is...is this secure enough? Initially I was going to store the iteration count server-side too but felt that an attacker who gained access to the server might then be able to easily brute force the key. Then again, whether users will be able to remember a password and a number is another question.

Answer 1

"Is this secure enough?" This depends on who you're defending against.

In theory, it looks like it'll stand up to non-TLA attackers reasonably well, although decrypting might be a bit tricky, as you don't seem to be storing the encryption IV anywhere.

In practice, it's got a major security hole. No real-world user is going to memorize the KDF iteration count. It'll get written down somewhere, and since the user is writing it down, they'll probably put their username and password right next to it.

Answer 2

The scheme seems fine as long as it's implemented correctly. It also seems like a pretty standard symmetric encryption requirement, which is why I'd recommend using a ready-made high-level implementation, rather than rolling your own from cryptograhic primitives. Any good implementation will generate the IV and do the key derivation for you.

If it leaves the number of rounds up to you, choose the maximum number of rounds which is tolerable for your customers. I don't see a good reason for making it variable.