0

In a game client/server that I'm developing, I want to allow a user to authenticate over TLS (via a REST endpoint on an HTTPS server) before dropping to an unencrypted low-latency UDP protocol. To prevent spoofing and replay attacks, the UDP protocol uses a SHA-256 HMAC and a nonce in each packet.

I want to make sure that the shared secret used as the HMAC key is secure. Not being a security expert, my first thought is to use a secure RNG to generate the secret at the server, then send it to the client over the TLS connection. Is this approach secure, or is this somewhere that I should be wary of "rolling my own crypto"? And if it's insecure, am I better off using e.g. libsodium's key exchange APIs? Or is this second key exchange (after the key exchange that happens when the TLS connection is established) redundant?

Improve this question
2
  • Is DTLS, possibly using a 'with_none' (MAC-only) ciphersuite, and possibly using resumption from a TLS session if you want to simplify the handshake a little, unsuitable for your application?
    – dave_thompson_085
    Jul 9, 2019 at 4:03
  • Resumption is a challenge because the TLS handshake is done by a termination proxy, so sharing the shared secret between the proxy and the game server is nontrivial. In this case I'm not sure that DTLS adds much value compared to an HMAC + a nonce, which is much simpler to integrate with the UDP-based network library I'm using.
    – opticfluorine
    Jul 9, 2019 at 23:40

1 Answer 1

Reset to default
0

It's redundant. This is no different, conceptually, from sending an unencrypted API key over a TLS connection.

That said, an HMAC won't prevent all types of attacks against such a protocol. An attacker in the middle can replay and/or withhold messages of their choosing, for one.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .