# Tag Info

0

As Thor already notes, you code is already quite close to PBKDF2, and it would not be difficult to turn it into a proper PBKDF2 implementation. Specifically, here's some (vaguely C / C++ / C# / Java / JavaScript like) pseudocode to implement PBKDF2-HMAC-SHA512, given a function HMAC_SHA512(key, message): function PBKDF2_HMAC_SHA512 (password, salt) { ...

2

If there would be risk from related inputs one would know that because then HMAC would be target to chosen plaintext attacks and hence PBKDF2 would have been fully obsolete. So there's no weakness in using related inputs. As each cell basically has a different password there's no faster way than brute-force to find out the values. However, if you know how ...

0

As this question is still on the list of "questions without answers", I'll quickly answer it (Basically repeating all of the above comments). Increase iteration count to something larger (1 Million?) You don't want to attach your HMAC of the plain-text after the contents. Rather authenticate either the ciphertext or (even better) use CCM/EAX/GCM mode. ...

1

If I'm reading your specs correctly, you do this: $IV||VAL||K_E||K_A=KDF(PBKDF(PW,Salt,Iterations))$. (Order doesn't matter here) As far as I know this is common practice and shouldn't pose any security threats, as the IV is in fact unpredictable as it needs to be. If I may I'd suggest you using EAX, CCM GCM mode if available, as this is easier than using ...

Top 50 recent answers are included