**PART 1**
Cryptography/software engineering topic coming up.
I am building a client - server application and I'm looking to add a bit of extra security with regards to the communication between the client and the server. I have come up with the following design, and I have some things that I would like to validate.
All communication between the client and the server happens over TLS. The first thing that the client needs to do is login with a username/password combination. The password salted with a stored salt and then hashed with bcrypt. This login results in a sessionID (which is sent back to the client) that is used to identify the client during all future communication.
**Creating a session key bound to a sessionID**
A layer of extra security that I am considering here, is to also have the client and server perform a KeyAgreement handshake to create a session key. The usage of this session key I'll describe a bit further down. The handshake for this session key works as follows:
1. Client sends a request (TLS protected) to the server, sharing a Curve25519 public key from a freshly generated Curve25519 keypair.
2. Server receives this request. Creates a new Curve25519 keypair, uses HKDF to calculate a shared secret (using as input FE public key, BE private key and a salt) and ultimately create a new symmetric session key (ChaCha20-Poly1305)
3. Server creates a new 32-byte (256-bit) session ID and keeps it in memory together with the session key. For future requests that the client performs, the client needs to send along the session ID which the server used to lookup the session key.
4. Server sends back the session ID + salt + public key from freshly generated Curve25519 keypair.
5. Client uses server public key + salt + client private key to calculate same secret and create the session key.
**Note**: All communication still happens over TLS.
Cryptography/software engineering topic coming up.
I am building a client - server application and I'm looking to add a bit of extra security with regards to the communication between the client and the server. I have come up with the following design, and I have some things that I would like to validate.
All communication between the client and the server happens over TLS. The first thing that the client needs to do is login with a username/password combination. The password salted with a stored salt and then hashed with bcrypt. This login results in a sessionID (which is sent back to the client) that is used to identify the client during all future communication.
**Creating a session key bound to a sessionID**
A layer of extra security that I am considering here, is to also have the client and server perform a KeyAgreement handshake to create a session key. The usage of this session key I'll describe a bit further down. The handshake for this session key works as follows:
1. Client sends a request (TLS protected) to the server, sharing a Curve25519 public key from a freshly generated Curve25519 keypair.
2. Server receives this request. Creates a new Curve25519 keypair, uses HKDF to calculate a shared secret (using as input FE public key, BE private key and a salt) and ultimately create a new symmetric session key (ChaCha20-Poly1305)
3. Server creates a new 32-byte (256-bit) session ID and keeps it in memory together with the session key. For future requests that the client performs, the client needs to send along the session ID which the server used to lookup the session key.
4. Server sends back the session ID + salt + public key from freshly generated Curve25519 keypair.
5. Client uses server public key + salt + client private key to calculate same secret and create the session key.
**Note**: All communication still happens over TLS.
