Two parties: a client and a server are to a agree on a symmetric key. Both the client and the server are aware of a
master password. The way this is currently done is:
- Both parties hash the
master passwordusing SHA-256 to create a
password hashis used by the client to encrypt a message which includes, amongst other things 128 pseudo-random bits. This encrypted message is then sent to the server.
- The server checks if the message is valid since it knows the
master passwordand in turn the
password hash. If the message is indeed valid, the server also generates a message (of similar structure to the client's message) and in the same way encrypts it using the
password hash. The server then responds to the client using the encrypted message.
- The client decrypts the encrypted response using the
- At this point both parties have agreed on 256 random bits (128 bits from the client's request and 128 bits from the server's response).
The aim is to make sure that:
- It is infeasible to recover the unencrypted contents of either the client request or the server response.
- It is infeasible to recover the master password or the password hash from either the client request or the server response.
The problem is that this technique leaves room for offline attacks to guess the master password (online attacks can be dealt with) and there may be other attacks that I haven't thought of yet. This gives rise to the question:
Are there any other possible attacks?
I considered that I could use PKC (RSA specifically) to add another layer of encryption (PKC on top of SKC) on both the client request and the server response so that an attacker cannot brute-force the low entropy master password without having the RSA private key.
Now, additional questions arise:
- Is this a valid method for achieving the goals mentioned above?
- In either case are there better solutions?
- Are there solutions which do not involve PKC?
- Which alternative solutions are the most secure?