Crypto Algorithm Question - Password Management (problem use-case)

Well, this is my first forum activity.
I hope you can help clear this.

Let's suppose I have a program and the user enter a password, and the user data is stored encrypted using AES-128.

The data and passwords (hash...) must be stored in the same file.

Data is encrypted with a password other than the user ("random password" based key derivation function for example PBKDF). because I read that this is the usual and if the user wants to change password only re-encrypts the "random password" and not all data.

And to save the user password is hashed using jasypt.org.(StrongPasswordEncryptor -> jasypt.org/api/jasypt/1.8/org/jasypt/util/password/StrongPasswordEncryptor.html))
Is it okay? .

My question is, how the "random password "is encrypted? Does this not be a weak point?. What I described, is it the right way?. I guess I'm confused on this issue.
Sorry for my English.
thanks

The random password would be encrypted and decrypted using a user-supplied password. The user-supplied password would not be stored.

Sorry for the time I have slow to respond, is that this application is for personal use and not have time lately.

But the more I read the more complicated it seems.

I think what I want is a system similar to this
(for my reputation I can not add link, concatenate "www." to )
security.stackexchange.com/questions/30193/encrypting-user-data-using-password-and-forgot-my-password/30197#30197

but I would like to see is it the way to go? I personally find it a bit odd and I do not understand the concept of "lock" key from the password.



I've also seen other things. Eg use pbkdf2 to derive a key from the password, encrypt using said key and discard the password/key. You can verify if the data is decrypted correctly by appending some predefined characters at the start of the plaintext before encryption and check for said characters after decryption. I think this would be the safest but not my use case.


Would be very grateful if you help me to choose the best way.
no matter the cost of the algorithm

Just consider the encrypted Data-Key as a separate encrypted message, which you simply add to the finally encrypted plaintext.

1) Generate a keysteam of at least 512 bit using the memorable keyword.

2) Take this keystream as Data-Key for the actual encryption of the plaintext.

3) Finally encrypt the keytream just as you encrypt any other data, in this case using the memorable keyword.

4) Append this result to the encrypted data.

The system accepts one piece of data as input:
(1) The user supplied password
The user must keep this secret.

Based on (1), the system derives one piece of data:
(2) A "lock" key (I don't think this is a technical term)
The process of deriving (2) from (1) is not secret (ie: something like PBKDF2).

The system stores two pieces of data long-term:
(3) An encryption key; this is called a surrogate key
(4) The secret data
Both pieces of data are stored encrypted.

(3) is decrypted using (2)
(4) is decrypted using the decrypted value of (3)

(4) cannot be decrypted without first decrypting (3), and (3) cannot be decrypted without knowing (2), and (2) cannot be known without knowing (1).

The point of having (2) is so that you can change (1) without having to re-encrypt (4). (4) is assumed to be large, and therefore time consuming to re-encrypt with a new key. The decrypted value of (3) does not change as a result of changing (1), but the encrypted value of (3) does because changing (1) requires (3) to be re-encrypted with the new value of (2).

Most encryption algorithms cannot use a user supplied password directly as the key. This is because the algorithms require the key to be an exact number of bits. One use of algorithms like PBK2DF is to stretch the user supplied password so that it is the right number of bits for use in the algorithm. For example, if the key length of the algorithm is 256 bits, then the user would be forced to supply a 32 character password if you were using the password directly as the key. This is why (2) is derived from (1) and used to encrypt (3), rather than using (1) directly to encrypt (3).

(1) and (2) are not stored long-term.


For real encryption, there is no such thing as a "forgotten password" feature. If you lose the decrypted value of (3), you lose (4) permanently.

Sorry for my ignorance.
But I can think following.
An algorithm like AES, is designed to encrypt.
That is not very large computational cost as PBKDF2 (I guess in my ignorance).
Then an attacker could try to decipher (3) in a brute force attack (I mean to try all the key).
Or the fact that the key is long (PBKDF2 result) ensures safety.
Do you understand me?


And now sorry for my stupidity.
If (2) is not stored then how it would perform the authentication (login)?


Thank you very much for your help.

That is correct; AES is designed to be fast, PBKDF2 is designed to be slow. This is another reason why PBKDF2 is used to stretch the key used to encrypt (3).


An attacker has three options if they are going to try to brute force the system.

a) They can attempt to guess (1). In order to determine whether a given value for (1) is correct, they need to derive (2) and use it to decrypt (3). Deriving (2) is slowed by the use of a proper key stretching function. However, if (1) is a weak password the attacker will still probably succeed.

b) They can attempt to guess (2) directly. However, (2) is very long and very difficult to predict, so the probability of success is very low.

c) They can attempt to guess the decrypted value of (3) directly. However, (3) is also very long and should be a completely random value and therefore even more difficult to predict, so the probability of success is even lower.


If the password provided by the user can successfully decrypt (3) (after deriving (2) from the password), then the password is correct. Otherwise, the value of (2) derived from the password will not successfully decrypt (3), which means the password is wrong.

At least to my knowledge there is a solution for the case that even if the user has lost his password, the encrypted data are still accessible. It's called "Enterprise Recovery" and an example of its usage can be found here

http://thelowedown.wordpress.com/2008/11/27/data-encryption-for-mac-osx-sparse-images-with-enterprise-recovery/

Just scroll a bit down to "Encrypted Disk Images" were it reads

"Images can be protected with a passphrase, but also provide a secondary access method using a certificate. The end-user can set the passphrase, but the enterprise holds the private key for the certificate so that recovery is always possible."

Thank you very much to all.
I clarified many doubts.