A few observations about RandomX usage of Argon2d

[doegox]

Argon2d specifies that the salt length in bytes should be comprised between 8 and 2^32-1.

This is correctly defined in argon2.h:

#define ARGON2_MIN_SALT_LENGTH UINT32_C(8)
#define ARGON2_MAX_SALT_LENGTH UINT32_C(0xFFFFFFFF)

and used by the argon2_core.c rxa2_validate_inputs function:

        if (ARGON2_MIN_SALT_LENGTH > context->saltlen) {
                return ARGON2_SALT_TOO_SHORT;
        }
        if (ARGON2_MAX_SALT_LENGTH < context->saltlen) {
                return ARGON2_SALT_TOO_LONG;
        }

RandomX default configuration is

#define RANDOMX_ARGON_SALT         "RandomX\x03"

which is fine with a length of 8.

Nevertheless, for those willing to reuse RandomX in their setup with custom parameters, nothing prevent them to use a shorter salt and no assert will detect it as rxa2_validate_inputs is never used.
Our recommendations:

• configuration.md : Permitted values: Any string of byte values. => this should be fixed into [8, 2**32-1]
• code : make use of a patched version of rxa2_validate_inputs (that would skip the check on output length as RandomX is not using the output)

Similarly, even if these ones are more unlikely to be misused:

RANDOMX_ARGON_LANES, RANDOMX_ARGON_ITERATIONS:

• configuration.md : Permitted values: Any positive integer. => It doesn't specify the maximum theoretical boundary of 2^24-1 for RANDOMX_ARGON_LANES and 2^32-1 for RANDOMX_ARGON_ITERATIONS.

RANDOMX_ARGON_MEMORY:

• configuration.md : Permitted values: Integer powers of 2 in the range 1 - 2097152. => minimum is not 1 but 8 (ARGON2_SYNC_POINTS=4). Upper bound seems correct
  with the assumption that CHAR_BIT=8 and sizeof(void*) >= 4 on all target platforms.

Finally, about Argon2, even if it's not in the critical path, its usage can probably be accelerated by bumping the hardcoded value context.threads = 1 in case RANDOMX_ARGON_LANES > 1

[tevador]

Was fixed in #111