4 ms·

The author writes that the encrypted private key (DEK) is susceptible to decryption if the server is compromised because then there are no more limits on incorr

The author writes that the encrypted private key (DEK) is susceptible to decryption if the server is compromised because then there are no more limits on incorrect attempts, allowing an attacker to walk the whole key space (of the KEK). But doesn't strong password requirements and a proper derivation function provide a large enough key space, making decryption by guessing (through any of various methods) infeasible? The author only mentions two alternatives for this problem, hardware security modules to prevent the compromise of the DEK from the server in the first place, or "sharding" between independent hosts to minimize the odds of that. Both certainly harden the server, but what about hardening the KEK? The author mentions PINs for the KEK because they are easy to memorize, which certainly makes for a poor key space, but why not use the same password the user already memorized to login, which should have strong requirements? Proton Mail, which also stores user's (encrypted) private keys,[1] initially had two passwords, one for login and one for decryption, and now allows users to have a single one, used both for login and decryption but never transmitted to the server, by using SRP for authentication.[2] Yet another approach is taken by Mozilla for Firefox Sync, which does two key-derivations on your password at your machine, creating one key for authentication and a separate one for decryption.[3] I wrote more about both approaches, check my submission history if you're interested. Anyway a nice read, I just missed more discussion about hardening the key in the first place, and how far that gets you in case of server compromise. [1] https://proton.me/support/how-is-the-private-key-stored https://proton.me/support/how-is-the-private-key-stored [2] http://srp.stanford.edu/ndss.html http://srp.stanford.edu/ndss.html [3] https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ https://hacks.mozilla.org/2018/11/firefox-sync-privacy/

bink 1y ago
If the server is compromised then the attacker can probably just grab a copy of the private key when it's decrypted for use.
matthewdgreen 1y ago
The nice thing about these protocols is that you can add a memory-hard hash function like scrypt or Argon2 into the middle of the protocol. This is computed on the client’s side, and will “harden” the key derivation by a bunch: essentially slowing down brute-force attacks by as much as the hash function costs. As best I can tell if you combine this with a very strong password, the problems I mention in the post won’t bother you (but no guarantees.) Unfortunately this still probably won’t save most users who choose short PINs and weak passwords, because offline password guessing is embarrassingly parallel and there’s only so much scrypt you can throw at any real system before everything becomes unusable.
deleted 1y ago
[deleted]

bink 1y ago

If the server is compromised then the attacker can probably just grab a copy of the private key when it's decrypted for use.

matthewdgreen 1y ago

The nice thing about these protocols is that you can add a memory-hard hash function like scrypt or Argon2 into the middle of the protocol. This is computed on the client’s side, and will “harden” the key derivation by a bunch: essentially slowing down brute-force attacks by as much as the hash function costs. As best I can tell if you combine this with a very strong password, the problems I mention in the post won’t bother you (but no guarantees.) Unfortunately this still probably won’t save most users who choose short PINs and weak passwords, because offline password guessing is embarrassingly parallel and there’s only so much scrypt you can throw at any real system before everything becomes unusable.

deleted 1y ago

[deleted]