Timeline for Is it problematic to use PBKDF2-HMAC-SHA256 to derive a 512-bit XTS key?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 23, 2019 at 18:15 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Fix spacing of |...| around Pr.
|
| May 25, 2018 at 17:12 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Clarify how it's not relevant to laptop disk encryption: namely, _in the password-guessing part_.
|
| May 25, 2018 at 15:45 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Missed a spot.
|
| May 25, 2018 at 5:13 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Clarify what the adversary's scenario is.
|
| May 25, 2018 at 4:56 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Close up that paren.
|
| May 25, 2018 at 4:43 | comment | added | forest | I would imagine that XTS mode using iSCSI (or NBD or anything similar) would have other problems as well, given that it would allow observing a single sector's contents changing over time (something XTS mode does not much like dealing with). | |
| May 25, 2018 at 4:24 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Make a better verbal spectacle of it.
|
| May 25, 2018 at 4:19 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Add another caveat. Is this paragraph of caveats long enough yet?
|
| May 25, 2018 at 4:15 | comment | added | Squeamish Ossifrage | @forest Correction: The gist is that it accidentally works out that the stupid design of PBKDF2 does not hurt security in the case of laptop disk encryption against a thief who steals the laptop. But an iSCSI server is a different story. I updated the question. | |
| May 25, 2018 at 4:14 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Accidentally that word back to where it came from.
|
| May 25, 2018 at 4:00 | vote | accept | forest | ||
| May 25, 2018 at 4:00 | comment | added | Squeamish Ossifrage | @forest The gist is that it accidentally works out that the stupid design of PBKDF2 does not hurt security in this case. What if you generated three blocks of output instead of two with PBKDF2, and stashed the third one in the clear as a way to let the legitimate user verify they typed in their password correctly before trying to read a randomized disk decrypted under the wrong key? Then you do hurt security. Single-block PBKDF2 followed by HMAC would be generally safer. scrypt and argon2 are better both because they're memory-hard and because they avoid this stupid design. | |
| May 25, 2018 at 3:24 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Cite MMO construction and BRS analysis.
|
| May 25, 2018 at 3:17 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Missed a subscript.
|
| May 25, 2018 at 3:07 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Tweak.
|
| May 25, 2018 at 3:01 | history | edited | Squeamish Ossifrage | CC BY-SA 4.0 |
Clarify that some details of XTS are not missing but not relevant here.
|
| May 24, 2018 at 5:41 | history | answered | Squeamish Ossifrage | CC BY-SA 4.0 |