Re: Newbie - Does This Make Sense?

"Larry Lindstrom" <larryl_turbo@xxxxxxxxxxx> wrote in message news:i4kk7k$980$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The reason for keeping the count in the second byte is to take advantage of whatever protection chaining has to offer. Would I benefit from putting more random bytes before the count? Do I benefit from having any random bytes before the count?

That's the picture. Any suggestions?

First suggestion: Take Paul's advice to use an encrypted hard drive.

Assuming that is unacceptable. First pad to a known size, so for example names should be padded to (k*32)-sizeof(length) characters, prepend the real length to the plaintext, this eliminates most of the length leakage, since your database has a maximum size for each field this is a convenient maximum length to use. Just pad with 0s, a pRNG won't affect the security.

For passphrase verification use N iterations of
T[0] = 0x000....000
T[i] = HMAC-SHA-256(T[i-1], passphrase)

store <T[N], N>, an N of 50,000 should be fine. A simple check against this value will detect bad passphrase entry with little leakage.

For the key itself use N iterations of
T[0] = 0x000....000
T[i] = HMAC-SHA-256(passphrase, T[i-1]) //Note the difference in operand order

store N the final i value.

For the encryption, I recommend CBC and HMAC, since you've already got the easy makings. The reason for CBC is to make use of the HMAC for the IV, this makes database storage easier

Encryption
plaintext = <HMAC-SHA-256(data) | data>// | is append, HMAC value is first, this is very important
ciphertext = CBC-AES(IV = 0x000....000, data = plaintext)

Decryption should be obvious. There is a risk, when there is a collision of <data, passphrase, N for key> the ciphertext will collide, if this is unacceptable use a counter for IV, and store it along with the ciphertext.

There is no need for a pRNG at all.

Third suggestion: Take Paul's advice to use an encrypted hard drive. I said it before, but it bears repeating.
Joe

.

Relevant Pages

  • Re: Newbie - Does This Make Sense?
    ... this value will detect bad passphrase entry with little leakage. ... For the encryption, I recommend CBC and HMAC, since you've already got ... unacceptable use a counter for IV, and store it along with the ciphertext. ...
    (sci.crypt)
  • Re: Hash question ...
    ... header of the file. ... When a user enters an incorrect passphrase, ... if I generate an encryption key with the ... could I safely store the SHA of the passphrase ...
    (sci.crypt)
  • Re: verify symmetric cipher key?
    ... the user enters a passphrase. ... ciphertext does not decrypt to the original plaintext. ... the MAC so that they can construct valid ciphertexts without ... off running an off-line brute force attack against it. ...
    (sci.crypt)
  • Re: verify symmetric cipher key?
    ... The passphrase is the only secret that enters the system. ... eg. to use as salts. ... then MAC the result to prevent bit-flipping attacks. ... I could fix this by including salt2 in the ciphertext, ...
    (sci.crypt)
  • Re: and now for something complete different part 2
    ... I would suggest that rather than using passphrase directly you use ... loop you are introducing a vulnerability to a chosen plaintext attack. ... ciphertext attack) if the known plaintext and known ciphertext are the ...
    (sci.crypt)