Good write-up. Couple of (unsolicited?) review comments.
Nitpick: I might be mistaken here, but I think PBKDF2 uses a HMAC function not a simple hash function. So it's highly likely you meant HMAC-SHA256, not SHA-256.
Nitpick: I'm guessing the IV is also generated from a cryptographically secure RNG, but you didn't say so in the doc.
Question: Why same IV for all user keys, instead of a different IV per key? Best practice is for each "encrypted message" to have a different IV. Your doc makes it look like each user key is a encrypted and sent separately, so each of the user's keys would be a different encrypted message.
If my understanding is wrong on anything, would appreciate it if I were corrected. Thx.
PS: Opening paragraphs are a bit combative, esp. "So saying ...".
1 comment
[ 6.1 ms ] story [ 11.5 ms ] threadNitpick: I might be mistaken here, but I think PBKDF2 uses a HMAC function not a simple hash function. So it's highly likely you meant HMAC-SHA256, not SHA-256.
Nitpick: I'm guessing the IV is also generated from a cryptographically secure RNG, but you didn't say so in the doc.
Question: Why same IV for all user keys, instead of a different IV per key? Best practice is for each "encrypted message" to have a different IV. Your doc makes it look like each user key is a encrypted and sent separately, so each of the user's keys would be a different encrypted message.
If my understanding is wrong on anything, would appreciate it if I were corrected. Thx.
PS: Opening paragraphs are a bit combative, esp. "So saying ...".