Increase radix^minlen lower bound of FF1 to account for new distinguisher

[str4d]

https://eprint.iacr.org/2020/1311 published a distinguisher for FF1 against binary numeral strings, that has a data complexity of $2^{2n((r-1)-\frac{1}{2}) - n}$ and a time complexity of $2^{2n((r-1)-\frac{1}{2})}$. FF1 has 10 rounds, corresponding to $r = 5$, and its minimum binary string length corresponds to $n = 10$; this gives a data complexity of $2^{60}$ and time complexity of $2^{70}$.

While this is clearly not secure for such short inputs, it does not invalidate FF1 as a whole. For example, on the 88-bit inputs used for Zcash diversifiers ( $n = 44$ ), we get a data complexity of $2^{264}$ and time complexity of $2^{308}$, which remains sufficient.

The best fix for this is to raise the $\mathsf{radix}^\mathsf{minlen}$ requirement (once we implement #31) to be greater than what NIST SP 800-38G Rev. 1 requires. For instance, 42-bit binary strings ( $n = 21$ ) are the longest that have a data and time complexity for this distinguisher smaller than $2^{128}$.

[str4d]

Using $n = 21$ gives a data complexity of $2^{126}$ for the distinguisher, which is close enough to the 128-bit security level that I think it is sufficiently close to justify using it to set the lower bound.

Used directly as the lower bound, we get $\mathsf{radix}^\mathsf{minlen} \geq 2^{42} = 4,398,046,511,104$. For binary strings expressed as byte arrays, this means a minimum length of 6 bytes (48 bits). Decimal strings would have a minimum length of 13 digits, rounded up from $\log(4,398,046,511,104) \approx 12.64$.

Given that a partial digit isn't useful, we may as well round the lower bound up to $\mathsf{radix}^\mathsf{minlen} \geq 10,000,000,000,000$, which is precisely 13 decimal digits. For binary numeral strings this is 43.19 bits which rounds up to 44 bits, or $n = 22$, which is the shortest binary numeral string that has both data and time complexity greater than $2^{128}$ for this binary distinguisher.

[str4d]

Another possible consideration is to raise the floor for encryption, but not decryption (allowing decryption of previously-encrypted values). Given that NIST have not yet released a revised standard, this seems like the most compatible approach.

[Direktor799]

Regarding the minlen bound, in readme it saids that it implement FF1 specified in NIST Special Publication 800-38G, but the MIN_NS_DOMAIN_SIZE is actually from NIST SP 800-38G Revision 1, which is not consistent.