Coverity points out that we don't need to check the output buffer
bound before writing out the first 32 bytes of each full-length
BLAKE2b invocation, because the only time we're doing a full-length
one in the first place is if the output buffer bound was at least 64
bytes.
(More specifically: whenever we're in the while loop, length > 64, so
setting chunk = 32 and then checking if chunk > length has a totally
predictable answer.)
The next version of the Internet-Draft for Argon2 has come out, and it
resolves the discrepancy between the Argon2i algorithm description and
the test vector.
The resolution is the same one I'd already guessed: the PDF in the
github repo, the C reference implementation in the same repo, and the
test vector in the I-D all agreed with each other, and only the
algorithm spec in the I-D disagreed with them all. The latter has been
corrected, so now all four sources agree with each other, and also
agree with my code.
So now everything is consistent and I don't have to have a comment
explaining which side I came down on.
This is going to be used in the new version of the PPK file format. It
was the winner of the Password Hashing Context, which I think makes it
a reasonable choice.
Argon2 comes in three flavours: one with no data dependency in its
memory addressing, one with _deliberate_ data dependency (intended to
serialise computation, to hinder parallel brute-forcing), and a hybrid
form that starts off data-independent and then switches over to the
dependent version once the sensitive input data has been adequately
mixed around. I test all three in the test suite; the side-channel
tester can only expect Argon2i to pass; and, following the spec's
recommendation, I'll be using Argon2id for the actual key file
encryption.
