Given the following assumptions:

  • A server's availability is implicitly trusted, but it is not trusted to keep data private (for reasons such as having questionable security or being suspect to government warrants).
  • The client software is implicitly trusted (for instance, due to being open source software, possibly developed by a third party).
  • The communication between the client and server is trusted to be private (for instance, due to being encrypted by TLS).

Are there any security primitives that allow a client to supply a password instead of an encryption key in order to appropriately secure encrypted data that's stored on a remote server? Is it secure for the client software to XOR a data encryption key with a hash of the user's password for the server, then to store the result on the server in order to later regenerate the original encryption key? If this (either in general or though the outlined process) is inherently insecure, what makes it insecure?

  • 1
    sounds like your asking about "password based key derivation" functions and ultimately E2E, both are secure
    – dandavis
    Jan 9, 2017 at 23:31
  • @dandavis What specifically are you referring to by "E2E"? "End-to-end"? A Google search didn't turn up very much that seemed relevant to this context. Jan 10, 2017 at 6:12
  • yes end to end. it's entirely feasible to derive a key from a password and use that for AES client-side. Since the server can only see the ciphertext, there's no need to trust it, other than mechanically.
    – dandavis
    Jan 10, 2017 at 10:54

1 Answer 1


Since the server is not trusted to keep data private the data have to be encrypted and decrypted locally at the client and the server should never have access to the key used for encryption. And since only already encrypted data are exchanged with the server this way it would not even matter much if the transport is secure or not.

Methods to derive a key from a password exist and called key derivation functions. The functionality of locally encrypting and decrypting data exists already in a variety of application and many of them open source too. Examples are GPG and Veracrypt.

  • So, based on your comment, 1) it's entirely feasible to do client side encryption and server side data storage without distributing a key across clients, and 2) it's a whole lot easier to do than I thought. It's good to know that it's possible, though I'm surprised that it's not done more often (maybe it happens more than I realize, given that an implentation is likely to be completely transparent to users?). Jan 10, 2017 at 6:08
  • @redyoshi49q: I think this is done a lot and mostly transparent. For example I think LastPass or Firefox Sync use a similar scheme where the data is encrypted and decrypted only on the client and the server never sees the key. Jan 10, 2017 at 6:20
  • @redyoshi49q Not " without distributing a key across clients". They have a password which is used to derive a key. So there is a shared key.
    – Josef
    Jan 10, 2017 at 11:13
  • @Josef: Shared key does not imply distributing the key. The key can be implicitly shared by having the same master password (entered by the user) and the same KDF. But the key itself is not explicitly distributed, i.e. not transported from one client to the other. Jan 10, 2017 at 11:38
  • If you share the same master password, it is distributed. It must be distributed. This distribution can happen by a person which has the password stored in their brain, who then enters the same password in multiple devices. This password, effectively, is equal to the key (because you have to use the exact same key derivation or it obviously won't work). It's mostly about semantics here, but for example you cannot upload some file and expect your friend in [OTHER_SIDE_OF_THE_WORLD] to decrypt it, without telling him the password (which is basically the key).
    – Josef
    Jan 10, 2017 at 12:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .