That's a fair complaint. The PBKDF2 answer is quite satisfactory (though I think that these days 10k iterations is warranted). What I'm much more concerned abo

That's a fair complaint. The PBKDF2 answer is quite satisfactory (though I think that these days 10k iterations is warranted). What I'm much more concerned about though is the server-side encryption of the notes[1]. Having the notes encrypted with a key that's kept on the same server, however frequently changes, adds barely any security. It gives the illusion of security: they can now truthfully say "your notes are encrypted on the server, yay!" But that's disingenuous, because the keys are stored on the same server. A much better system would be to encrypt the notes on the device, using a key derived from the password. That way, the server can never see the plaintext of the notes, except for during login and when the password is being changed[2]. [1]: http://inessential.com/2014/04/17/vesper_sync_diary_14_keys http://inessential.com/2014/04/17/vesper_sync_diary_14_keys [2]: This is actually pretty easy to get around, by not sending the plaintext password to the server for login, but rather a different password-derived key. But if it were built that way it'd make it a little harder to update all the notes when changing passwords. But again, you could fix that by simply storing an encrypted version of a randomly generated encryption key on the service, and simply re-generating that when the password is changed, without having to chain the note ciphertexts. Kind of like how OS X full disk encryption works. I actually touched on this by mentioning it to Brent via twitter the other day: https://twitter.com/kob/status/471152663384440832 https://twitter.com/kob/status/471152663384440832