Re:Vesper 2.0 and Vesper Sync
by SeoxyS on Wednesday May 28, 2014 @02:20AM
(#7808645)
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].
[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.
Re:Vesper 2.0 and Vesper Sync
by tptacek on Wednesday May 28, 2014 @08:35AM
(#7809565)
If they don't feel like they know exactly what they're doing with cryptography, I'm glad they opted to be candid about their limitations rather than bragging about their military-grade encryption.
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
[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