client identification concept by wolf using fake maps utilizing a binary tree

[jxsl13]

Client is unknown
The server has 16 or 32 predefined unique maps that have the minimal possible size(one bit, if possible)

The server asks the player, if he has that specific map, does the map not exist, it is being sent by the server, if needed. each map represents the ID of the player in a binary representation.
[15][14][13][12] [11][10][9][8] [7][6][5][4] [3][2][1][0]

for example, we send maps [0], [3], [4]
thus the client gets the ID: 11001 = 25
every map that does not exist is evaluated as 0.

Before setting the ID, the server needs to check for the existence of every possible map that might have been sent to the client, if the client has any of the maps, the identification might have been modified by the user.
If the client does not have the maps, none of them, the maps evaluated as an enabled bit are sent to the client.
after these three maps have been, the server knows that client has the ID 25.

The player is given his ID and can simple join the game.

Client is already known

When a player tries to join the server, the server holds multiple IDs in a set of IDs.

Given a pool of IDs, which should be held in a structure that can be considered a set as well as an ordered priority queue that can be asked for its biggest element.

{1,2,3,4,5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32}

IDs can be simply incremented by one in a priority queue, which is supposed to have as many elements as IDs exist.

Given the biggest element 31 we can calculate the number of max occupied bits, which is 5(2^4 + 2^3 + 2^2 + 2^1 + 2^0 = 32)(thus our binary tree has a depth of 5.)

[4][3][2][1][0]

Bit 4: Exists         -> 1
Bit 3: Exists         -> 1
Bit 2: Doesn't exist  -> 0
Bit 1: Doesn't exist  -> 0
Bit 0: Exists         -> 1

Depending on the current size of the database, we will have to make more checks with time, but this number grows rather slowly (log2(Seen clients))

Has the client responded to all of our requests, the actual map can be loaded.
And the client is assigned a unique ID.

Additional information
It might make sense to calculate IDs differently than simply incrementing them by one.

Another approach might be to add a some crc bits.

Each map should not be visibly assignable to its corresponding bit, thus obscuring the encoding.

The order in which the X bits are requested from the client might also be based on a randomized algorithm, further obscuring the process and the "encryption" of the ID, which then cannot simply be modified without changing the crc code.

let the ID be 25:

[1][1][0][0][1]
bit 4 ....... bit 0

Generator polynomial:
http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

x^2 + x^1 + x^0 = 111

The server knows how map names are mapped to the bit positions, the client doesn't:

bc2bFMEsKupBd7VQ.map -> crc bit 0
Rc84vEaUZbXUR6xw.map -> crc bit 1
hSVfTUXyv4bNfE2E.map -> ID bit 0
mBaEdHDWjn7KJQcG.map -> ID bit 1
E9JzBZfb6SFhyvcK.map -> ID bit 2
pRqA6qPr5PvcRCdL.map -> ID bit 3
ZvZKf5hAAnuM2wjZ.map -> ID bit 4

The client might see a folder of these maps:

bc2bFMEsKupBd7VQ.map
Rc84vEaUZbXUR6xw.map
hSVfTUXyv4bNfE2E.map
pRqA6qPr5PvcRCdL.map
ZvZKf5hAAnuM2wjZ.map

Modifying any of these files will lead to the corruption of the checksum.
The generator polynomial should occupy only 2 to 3 bits at most.
Given the fact that bit corruption can only happen in the way that a bit flips from a 1 to a 0, there might exist some proven strong and short polynomial fitting this purpose.

Is the data corrupted, it can be assumed that the user has modified the files.

Given the bits that still exist, it might be possible to recover the ID, is it not possible to recover the ID, a new ID needs to be assigned that especially contains the still existing bits on the client's side.

It might also make sense to have multiple fallback "maps" of map name - bit position values if the current set of maps has been tempered with by the user.

[jxsl13]

reciovering one's key (set of maps) via a recovery key that can be requested while still having the correct set of maps as identificarion.

[jxsl13]

instead of crc one might use some cryptographic signature as it is used with jwt tokens.