I don't know if my concept would be secure so I ask here. The main purpose is to log in with password x and also use that password to encrypt an RSA private key with AES to store that in the main database, so when I log in with another account that private key can be reused and I can encrypt all incoming messages with that private key, so other users only need one single public key from me.

Due I don't want anyone to be able to read the message I use that RSA encryption but I also don't want the server to be able to know the AES password.

So my thought was that I use password x and hash it with PBKDF2WithHmacSHA512 and use that first hash as the AES password. Then I hash the hash again with the same algorithm and use that to log in in my account. So the double-hashed-password will be sent to the server and will be treated as my account password. With my understanding the server will never know what the AES password is so will never be able to get the private key.

The private key will be generated when no private key is in the database yet, encrypted and sent to the database. When I log in again I will get this encrypted private key and can decrypt it.

Now I'm wondering if I'm missing something. Would that be secure?


Your strategy has a few issues. It is a bit confusing, but I'll try to address:

Firstly if you use the output of a hashed password as the input to something else, then you'll not be able to change passwords, since after this the output of the hashed password would be different and would therefore end up being a different key.

Secondly, the premise that you don't trust the server implies that you cannot send passwords or keys in any way to the server, which would certainly be the case for web applications. So you can't use your password or the hashed password which is used as an AES key (considering that this is possible and feasible). Otherwise it is always possible for the server to collect enough information to recover all your keys.

The last aspect is a deal-breaker. Either you change your model and somehow trust the server, or you change your model to ensure that private keys never touch the server.

| improve this answer | |
  • I do trust the server. I own it. But for extra security I don't want the server to know the private key so that it will never even be able to read messages between clients. The password which is sent to the server is the double-hashed one. The server will not be able to reverse that password to the single-hased version which is the AES password. Change password would be possible if the keypair would be regenerated. Then you would have to login once again on all clients. If I still made a mistake in thinking, please tell me – Jannis636 May 1 at 15:06
  • I understand the concept, but I find the process quite confusing with the information you provide. Can you walk through the process? User logins with which parameters exactly? What is stored on the database? Keys are decrypted and retrieved and used in which way? Messages are encrypted and sent and received and handled how? – Pedro May 1 at 15:37
  • I've added two pictures to explain. imgur.com/FFkrM4k imgur.com/V7jirbM. I should also mention that the server-side login works also secure. The password will be encrypted once again and compared with the encrypted login password. An salt is also added. In this case the password is an hash but that doesn't matter to the server. It uses what it gets. – Jannis636 May 1 at 16:27

There is at least one mobile password manager application that chooses not to totally trust the server run by the company who made the mobile application. The idea being that only the mobile phones that hold and synchronise the users “secret local database” replicated to each phone can decrypt the content or any messages exchanged via the server. The server only facilitates exchange of encrypted messages between the users devices. So it is possible to maintain secrets at many clients without exposing them to the server. The challenge is to make this simple for the user. If a user could memorise and type out a private key it would be trivial to setup. What is harder is to secure it with a “master password” that a user can hopefully memorise.

Here is an outline:

  1. The user at their phone chooses a strong master password. This is checked against the “troy hunter have i been p0ned” API.
  2. The phone generates a strong random public salt. The phone first runs a key stretching algorithm over the password (e.g., PBKDF2) and then computes an SRP6a password verifier using the salt. This as is sent to the server which stores it into an encrypts column within its database. At this point only a brute force attack is possible which is slowed down by the key stretching.
  3. The phone creates an asymmetric key pair and registers the public key at the server. All the users phones and browser plugins create unique asymmetrical keys. The user synchronises public keys between all devices. The public keys can be hmac signed by joining the public salt to the master password and key stretching the result. That way the server cannot pass an attackers public key to any device.
  4. In this manner all the users devices can know and trust all the public keys of all the phones owned by the user. They can all synchronise the users private data using public key crypto.
  5. As the users master password never leaves the phone it can be used to encrypted a backup of the database that can be updated to a backup service by the user in case all their phones are destroyed at the same time.

The next challenges are what happens if the users forgets their master password. This can be handled by Shamir’s Secret Sharing Scheme. The phone can generate several shares of the master password where some minimum number must be combined to recover the master password. These might be in the form of QR codes. The user can use different apps to send the shares to different friends and backup other shares to safe locations. This technique is used by bitcoin wallet apps to backup a users master password. If the user dies if his family has a share of the password each but need an additional password share held by the dead persons lawyer the family can recover the bitcoins.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.