Peer validation in crypto_kx_*() & thank you!

[etkaar]

First I just wanted to say: Thank you for this library! =)

I also want to ask a short question:

I want to make use of crypto_kx_*() for encryption within a lightweight UDP protocol (Layer A). So far I know how that works. There is only one thing: How can I validate the peer (man-in-the-middle)? I thought about moving that from Layer A to Layer B, where client and server have a secret which is the same for both sides, such like an API key. It is then validated using nonce + hash(nonce, secret) to not transmit the secret itself. This way, a man-in-the-middle can be prevented.

However, an additional authentication packet is needed for that, thus, it would be interesting to have that done already within crypto_kx_*(). Is there a safe way to use that secret, such as hashing of the client/server read/write keys with the secret?

[jedisct1]

The easiest way is to know the peer's public key instead of transmitting it. Without the corresponding secret key, an intermediary cannot compute the shared secret.

If any public key has to be accepted, have the peer sign it, and verify it using a long-term public key.

[etkaar]

Thank you for the fast reply!

If any public key has to be accepted, have the peer sign it, and verify it using a long-term public key.

I am not exactly sure which functions to use in conjunction with crypto_kx_*().

The only thing why I don't want to have fixed long-term keypairs is Perfect Forward Secrecy (PFS).

[jedisct1]

Create an ephemeral key pair (crypto_kx_keygen()) and send the public key along with its signature. You still get PFS with a long-term key used for signatures.

The signature can be replaced with another DH, but a signature is probably easier and more intuitive.

[etkaar]

The function crypto_kx_keygen() does not exist unfortunately. But I have now done following:

Only – but necessarily – the server uses a permanent keypair from crypto_kx_keypair(), while the client generates a new one for each new connection using the same function. The client has stored the public key of the server, while the server retrieves the public key transmitted by the client once a new connection is going to be established.

This way, both Perfect Forward Secrecy (PFS) and peer validation of the server (Man-in-the-Middle) should be achieved, because read/write keys always change. No additional checks are required. Client peer validation is not required. (*)

(*) The client peer is not validated. This could be done if the client also would have a permanent keypair, but in that case the Perfect Forward Secrecy (PFS) would get lost as the read/write secret keys would never change.

Please correct me if I am wrong! :)

[etkaar]

Can you confirm that these of my assumptions are correct? ☺️

The function crypto_kx_keygen() does not exist unfortunately. But I have now done following:

Only – but necessarily – the server uses a permanent keypair from crypto_kx_keypair(), while the client generates a new one for each new connection using the same function. The client has stored the public key of the server, while the server retrieves the public key transmitted by the client once a new connection is going to be established.

This way, both Perfect Forward Secrecy (PFS) and peer validation of the server (Man-in-the-Middle) should be achieved, because read/write keys always change. No additional checks are required. Client peer validation is not required. (*)

(*) The client peer is not validated. This could be done if the client also would have a permanent keypair, but in that case the Perfect Forward Secrecy (PFS) would get lost as the read/write secret keys would never change.

[jedisct1]

If the traffic was recorded and the server's secret key is compromised, all the session keys can be recovered.

[etkaar]

Thank you Sir. Do you have an idea how to prevent that? You referred to signatures of public keys, but I am not sure what you mean with that (I did not find libsodium functions for that use case).