How to deal with matcher restart/multiple matchers?

[SirLynix]

Hi there,

I've been reading your netcode spec and I got some questions about the matchers: they're using a nonce (incremented for every token generated) and a private key (known by the game server).
As far as I know, a nonce and a key should be used together only once to prevent security breaches.

So what about matchers restart (after a system/application crash)? Is it a big deal its nonce restarts at 0 (which means it already have been used)? Should the key be regenerated?

How about multiple matchers (for load balancing/failover/etc)? Should each matcher gets its own private key? How does the game server should handle this?

Thank you

[gafferongames]

I believe that we widened the nonce for the connect token such that it much wider than 64bits and is a randomly generated number. This makes it safe on restarts, and for multiple instances of the matcher!

[gafferongames]

While the nonce for the packets themselves are 64bit sequence numbers, and yes, these start at 0 and increase with each packet sent... but we make this work by having different private keys per-client/server connection.

[gafferongames]

Please let me know if this is not the case in the standard, or if it is not clear, and we can fix it. I believe that this is what we did by design though, and that the nonce is randomly generated each time before creating a connect token, hence the reset to 0 is just clearing it and has no effect.

[SirLynix]

Thank you for your reply.

I understand the game packets themselves are secure due to the newly pair of keys generated for each token, I'm talking about the token (private part) encryption by the matcher using the fixed private key and the matcher sequence.

The nonce used for encryption is a 64 bit sequence number that starts at zero and increases with each connect token generated. The sequence number is extended by padding high bits with zero to create a 96 bit nonce.

Since all matchers share the same private key, using the same nonce twice with different inputs can be dangerous (afaik, I may be wrong though). So they should use a different private key? Should they share the same nonce (using a database like Redis to atomically increment it)? Should they generate a random nonce at launch and then increment it?

I may be missing something here.

Thank you for your time

[gafferongames]

I understand.

You are correct about the same nonce being reused being bad.

I will investigate further!

cheers

[SirLynix]

An alternative would be to use XChacha20 instead of Chacha20 for private token data encryption, since this use 192bits nonce which allows for random nonce to be safely used.

From: https://libsodium.gitbook.io/doc/secret-key_cryptography/aead/chacha20-poly1305/xchacha20-poly1305_construction

[gafferongames]

I complete agree. Would you be willing to create a pull request to implement this change? I will accept it. This is the correct solution.

[gafferongames]

Ah yes, now I remember. In another project derived from netcode.io I switched to private/public key encryption of the equivalent tokens rather than symmetric, which in libsodium has a wide enough nonce for random. That is what caused my confusion...

[SirLynix]

Sure 😃, but I won't have time until this weekend.

I guess version info also has to be changed to "NETCODE 1.02"?

I'll take care of that.

[gafferongames]

Yes, we must bump up the minor version. Thank you!

[SirLynix]

Just for information, I have to update libsodium since the bundled version (1.0.10) doesn't have xchacha20 (introduced in 1.0.12), this is not a problem for Windows but it can be for some linux distributions (like Debian, which on its stable repository only has libsodium 1.0.11).

Should I do something special about this or is it fine to tell Debian users to build libsodium themselves?

[SirLynix]

Also, do you want netcode_generate_connect_token to take the nonce by argument (as it did with the sequence number) or do you want it to generate the nonce internally?

[gafferongames]

I like it generating it internally now that it's random, since this removes the possibility for user error!

[gafferongames]

Looks like this one is solved! Thanks!