# Tag Info

2

This is a very difficult question. But first the standard information: Don't roll your own crypto if anyhow possible. (which isn't the case here) No protocol should be considered secure until formally proven secure. (TLSv1.2 is) That being said I can still provide "ad-hoc" security argumentations why it's likely that your handshake is (in)secure.I can't ...

1

For a pre-shared secret, you just use a secure MAC to authenticate the key exchange, e.g. for the exchanged public ephemeral keys $A$, $B$ and the resultant shared secret $S$, one side could send $HMAC(PSK, S, A, B)$ and the other $HMAC(PSK, S, B, A)$. Each side can easily verify that the other is using the same exchanged values and shared secret, and that ...

1

The client generates a random symmetric key and encrypts it with the public key. This public key needs to be trusted. Make sure you use a good padding mode, OAEP should do it. Send to server, server decrypts it with the private key. Eh, that's it. No forward security though, the session can be decrypted if the RSA scheme is broken or if the private key is ...

1

Your scheme is not a good approach -- it is not safe. Your scheme is vulnerable to rollback attacks. Ideally, the security property we'd like is that this will select the best (highest) version that both client and server support. However, that security property is not achieved. A man-in-the-middle can force both parties to end up using the worst ...

1

Note: Until told otherwise this answer will assume the following things: The "Master-Key" is secure. (unextractable, 128-bit+ entropy) Ephermal (EC-) Diffie-Hellman is available and secure (keys unextractable, 2048 bit DH / 256 bit ECDH available) The random number generator used is secure. (i.e. not just relies on the time, e.g. it's a cryptographically ...

Only top voted, non community-wiki answers of a minimum length are eligible