In a typical mobile project, a user can register and login into an app, and the app communicates with a server. For simplicity, consider an app where the user can register/login using the OAuth2 standard with his google account.

Now, the own developed server would like to fetch additional information; in the example the server could fetch the google server for some critical user specific data. This data is needed later on, so the server would like to store this data.

  • Requirement 1.1: the server admin should not be able to get this ciritcal user data e.g. by reading the data base.

  • Requirement 1.2: the server should be able to encrypt this user specific data specifically for this user

  • Requirement 1.3: the server should only be able to decrypt this data when the actual user is involved ("user secret").

One solution idea could be, that the user generates kind of a private and public keys on registration time and sends the public key to the server. The server encrypts the fetched sensible data with the public key of the user.

If the user wants the server to use this data on another operation, it must provide an additional part to the server to decrypt the data (e.g. the private key).

  • Requirement 2.1: The server should be able to decrypt with a user secret, but should not need to re-encrypt. Can this be archived by e.g. a signed "secret", which is only valid to decrypt the data once, or in limited time?

  • Requirement 2.2: The app should be able to synchronize the secret to another app installation on another phone, so that the user can trigger the operation from another phne, without the need to share the key over the server itself.

Do you have any advices or hints how these requirements can be met? (partial solutions are also highly welcome)

  • 4
    Please describe the capabilities of the "server admin". The common case is that the server admin is not only able to read the database but has also the ability to change the code of the web application, i.e. both server side (PHP, ASP...) but also the html, script etc provided to the browser. In this case the admin could modify the code and add a backdoor, some way to log the password or to disable encryption at all. Commented Sep 24, 2019 at 16:36

1 Answer 1


Requirements 1.1 and 1.3 are incompatible; there's nothing that software can do which an admin of that software cannot do.

If you don't need the server to be able to decrypt the data at all, that works fine and is called end-to-end encryption (E2E) and is used for a wide variety of very secure tools. With E2E, only the client can decrypt the data; the server can only receive, store, and transmit encrypted blobs with no access to their contents.

Requirement 1.2 can be met by having the server store a public key for each user, and - when it wants to encrypt data to that particular user - first creating a new symmetric key, encrypting data with that key, and then encrypting ("wrapping") the symmetric key with the user's public key and storing the encrypted data and wrapped symmetric key together. The user, which is the only entity with access to the corresponding private key, is the only entity that can unwrap the symmetric key. However, this still requires that the server be trusted, or else it (or a malicious admin) might do something like also wrap the symmetric key with their own public key, or just store the symmetric key (or the data itself) in plain text somewhere.

Requirement 2.1 is fundamentally impossible if there is no fully-trusted agent to do the decryption for you. If the server is doing the decryption itself (and is not fully trusted, because the admin isn't fully trusted) then the server/admin can steal the decryption key and hold onto it for later use. You can mark a key as "don't use after this date" but there's no (known) way to mathematically enforce such an inherently non-mathematical concept and cryptography is just math. Enforcement is up to the agent doing the decryption, and the key expiry is nothing but a suggestion.

Requirement 2.2 can be achieved by transmitting the key over a local network or Bluetooth, or encoding it as a QR code and displaying it on the screen, or other such methods. For maximum security, though, the key should be encrypted using a user-supplied password and decrypted on the other end, or better yet transmitted over an encrypted channel using an ephemeral key with the passwords used only to verify the ephemeral key parameters (this is known as "forward secrecy" and prevents an attacker from decrypting the key even if they recorded all the network traffic and later learn the password that was used).

Given the questions that you are asking, you almost certainly do not have enough security knowledge to design this system securely, or securely implement even a secure design. Designing new cryptosystems is hard, as is implementing them. For example, the SSL/TLS protocol is decades old, designed by people who theoretically know what they're doing, and has been through 6 different published versions because people keep finding weaknesses in the old ones... and that's just the design; the actual implementations in libraries like OpenSSL have had numerous and occasionally massive vulnerabilities.

If you have a specific use case in mind, there may exist well-reviewed software that already provides it (for example, nobody should be attempting to roll their own password manager unless they fully understand how the existing ones work and have some specific improvement they want to make but can't just get LastPass/1Password/etc. to implement it). Don't re-invent the wheel if you don't have to, especially if you're not quite sure how wheels work and want them to do several incompatible things.

If you're trying to create something that's totally new, document it and put out the document in a Request For Comments (RFC) so the industry can try to poke holes in the idea, and then after the design is done, open-source the code you write so that the industry can review your implementation. If the design and/or code must remain proprietary, you're probably not going to be able to achieve as good of security but you should still hire a cryptographic security expert (perhaps as a consultant) to review the design and implementation.

You must log in to answer this question.

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