1. Remove recommendation for 512-bit BLAKE2b.
32 bytes is enough, and it's not like we offer EC functions of a
higher security level either.
The text added in
628f027 already does enough to recommend proper
hash output lengths.
2. Bump .Dd date in crypto_poly1305.3monocypher.
3. crypto_verify16 add "byte by byte" for both accuracy of how a MAC
with a variable-time comparison function will be found and
for dramatic reasons because it sounds like doom is slowly
approaching, byte by byte.
.Fa hash ,
in bytes.
Must be between 1 and 64.
-64 is recommended.
Anything below 32 is discouraged when using Blake2b as a general-purpose
hash function;
anything below 16 is discouraged when using Blake2b as a message
.\" with this software. If not, see
.\" <https://creativecommons.org/publicdomain/zero/1.0/>
.\"
-.Dd March 2, 2020
+.Dd March 31, 2020
.Dt CRYPTO_POLY1305 3MONOCYPHER
.Os
.Sh NAME
.Dq your MAC is wrong, Em and it took 384 microseconds to tell .
If the next attempt takes 462 microseconds instead, it tells the
attacker they just guessed a byte correctly.
-That way, an attacker can derive the correct MAC, and successfully
-forge a message.
+That way, an attacker can derive the correct MAC byte by byte,
+and successfully forge a message.
This has lead to practical attacks in the past.
.Pp
To avoid such catastrophic failure,