A few observations about RandomX strings

[doegox]

RandomX is using defined strings at several places in its algorithm:

• RANDOMX_ARGON_SALT = "RandomX\x03"
• AesGenerator1R_seed = "RandomX AesGenerator1R keys" and AesGenerator1R keys computed from Hash512(AesGenerator1R_seed)
• AesGenerator4R_seed1 = "RandomX AesGenerator4R keys 0-3" and AesGenerator4R keys 0-3 computed from Hash512(AesGenerator4R_seed1)
• AesGenerator4R_seed2 = "RandomX AesGenerator4R keys 4-7" and AesGenerator4R keys 4-7 computed from Hash512(AesGenerator4R_seed2)
• AesHash1R_seed1 = "RandomX AesHash1R state" and AesHash1R state computed from Hash512(AesHash1R_seed)
• AesHash1R_seed2 = "RandomX AesHash1R xkeys" and AesHash1R xkeys computed from Hash256(AesHash1R_seed2)
• SuperScalarHash_seed = "RandomX SuperScalarHash initialize" and SuperScalarHash XOR constants computed from subset of Hash512(SuperScalarHash_seed)

Currently only the first one, RANDOMX_ARGON_SALT, is meant to be diversified for usages in other contexts. The other strings don't have official names, we came up with our own labeling in the list above to ease the discussion. E.g., Arweave has chosen RANDOMX_ARGON_SALT = "RandomX-Arweave\x01" (1) and Wownero RANDOMX_ARGON_SALT = "RandomWOW\x01" (2).

Even if security-wise, alternatives can live with the strings hardcoded with identical values, provided that they diversify the other existing configuration parameters, it would seem very natural to us that these strings would become part of the configuration parameters.

• Such defined strings in cryptographic protocols are typically present, beside their nothing-up-my-sleeve nature, to allow easy reuse in different contexts with a content bound to their usage, here e.g., "RandomX Arweave AesGenerator1R keys" etc.
• These are very safe parameters to modify, contrary to some other parameters of RandomX which require careful attention before being changed. So it costs no design effort to choose other values for other usages.
• If they become part of the configuration, in order to keep the implementation flexible, you would need to compute the hashes during the compilation phase or the first run phase (as well as other derived values such as the soft-AES LUTs) which is in our opinion a good thing for peer-review, rather than having directly hardcoded values in the implementation for which there is today no explanation in the code itself. Indeed today one must look in the spec itself to understand and verify by herself these hardcoded values.
• While we're at it, you could adapt AesHash1R xkeys creation and usage as for AesGenerator4R, let's say mostly for aesthetic reasons and to avoid people to (wrongly) raise concerns even if it has been demonstrated in previous discussions that it's not a security issue to reuse xkey0 and xkey1. Every other key derivation is using Hash512, so you could just use Hash512 instead of Hash256 for these xkeys and get 4 of them.