1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-25 01:02:24 +00:00

Update references for Argon2.

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 commit is contained in:
Simon Tatham 2021-03-22 18:11:38 +00:00
parent 66265d30f5
commit 049acf9ef5

View File

@ -6,20 +6,7 @@
* the Internet-Draft description:
*
* https://github.com/P-H-C/phc-winner-argon2
* https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-12
*
* Note on the spec: I believe draft-irtf-cfrg-argon2-12 has an error in the
* description. When making the pseudorandom data used for calculating Argon2i
* block indices, the spec in the Github repository says that you make a block
* of preimage data and then apply the block-mixing function G to it _twice_
* in iteration. But draft-irtf-cfrg-argon2-12 only mentions applying it once.
*
* The test vectors and reference implementation settle the difference: the
* reference implementation also applies G twice, and comes with a program
* that regenerates the test vectors as found in draft-irtf-cfrg-argon2-12. So
* draft-irtf-cfrg-argon2-12 is not consistent within itself - the algorithm
* with G applied just once does not pass its own test vectors. I'm convinced
* that the intention was to apply G twice.
* https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-13
*/
#include <assert.h>
@ -343,15 +330,14 @@ static void argon2_internal(uint32_t p, uint32_t T, uint32_t m, uint32_t t,
* this point in the algorithm (array position and
* pass number) to make all the hash outputs distinct.
*
* The hash we use is G itself, applied twice (see
* comment at top of file). So we generate 1Kb of data
* at a time, which is enough for 128 (J1,J2) pairs.
* Hence we only need to do the hashing if our index
* within the segment is a multiple of 128, or if
* we're at the very start of the algorithm (in which
* case we started at 2 rather than 0). After that we
* can just keep picking data out of our most recent
* hash output.
* The hash we use is G itself, applied twice. So we
* generate 1Kb of data at a time, which is enough for
* 128 (J1,J2) pairs. Hence we only need to do the
* hashing if our index within the segment is a
* multiple of 128, or if we're at the very start of
* the algorithm (in which case we started at 2 rather
* than 0). After that we can just keep picking data
* out of our most recent hash output.
*/
if (jpre == jstart || jpre % 128 == 0) {
/*