Currently, the maximum version of IDs supported by this library is 63 because it is restricted by the amount of bits in the metadata byte, where 2 bits are already being used by this library.
The VERSION number is primarily useful for being able to change any of the following aspects of the process:
hmac_key of the KeyGenerator
the hash function used in the KeyGenerator
EPOCH of the BinaryId
the signature algorithm associated with a Key ID (although this isn't being directly associated by this library)
With cryptographically-relevant quantum computers on the horizon and potential currently unknown vulnerabilities in our arbitrary algorithms, it might be necessary to eventually change at least the signature algorithm, and that could be assisted by having versioned IDs.
There are two problems with using more bits, which may be insignificant:
For every bit that the version numbers use, there are half as many possible values for that ID version.
Using multiple bytes for the metadata (based on the value of VERSION_BITS) might make the documentation slightly more complicated and would add an extra to check regarding the METADATA_OFFSET value.
(1) might not be significant because we sort of gain between 4-5 extra pseudorandom bytes from the timestamp compression, and the user could compensate for this by making the IdLen larger.
(2) is not exactly an issue with the code because it is fixable.
There are at least 2 ways to increase the maximum VERSION_BITS to either 13 or 14.
One way to increase the version would be to check if VERSION_BITS is greater than 6, and if it is, use VERSION_BITS - 6 bits in the next byte for the upper bits. This could allow for up to 14 bits to be used, or up to 16384 versions.
Another way would ensure that minimal bits are used for VERSIONs less than or equal to 2^5 is by using the largest bit in the first metadata byte to determine if it should use extra bits in the next byte for the version, restricting the total amount of bits to 13, or up to 8192 versions
Currently, the maximum version of IDs supported by this library is
63because it is restricted by the amount of bits in the metadata byte, where 2 bits are already being used by this library.The
VERSIONnumber is primarily useful for being able to change any of the following aspects of the process:hmac_keyof theKeyGeneratorKeyGeneratorEPOCHof theBinaryIdWith cryptographically-relevant quantum computers on the horizon and potential currently unknown vulnerabilities in our arbitrary algorithms, it might be necessary to eventually change at least the signature algorithm, and that could be assisted by having versioned IDs.
There are two problems with using more bits, which may be insignificant:
VERSION_BITS) might make the documentation slightly more complicated and would add an extra to check regarding theMETADATA_OFFSETvalue.(1) might not be significant because we sort of gain between 4-5 extra pseudorandom bytes from the timestamp compression, and the user could compensate for this by making the
IdLenlarger.(2) is not exactly an issue with the code because it is fixable.
There are at least 2 ways to increase the maximum
VERSION_BITSto either 13 or 14.VERSION_BITSis greater than 6, and if it is, useVERSION_BITS - 6bits in the next byte for the upper bits. This could allow for up to 14 bits to be used, or up to 16384 versions.VERSIONs less than or equal to2^5is by using the largest bit in the first metadata byte to determine if it should use extra bits in the next byte for the version, restricting the total amount of bits to 13, or up to 8192 versionsIs it necessary to fix this?