Re: [Cfrg] IRSG review of draft-irtf-cfrg-argon2-09

Hi Stephen,

thank you so much for a detailed review.

Unfortunately, I have no control nor experience with the third-party
implementations you are talking about. I do not know if they allow printing
so detailed test vectors. I am afraid given that they contain only-memory
values, you may not see them in full in the output.

On Wed, Dec 11, 2019 at 4:41 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hiya,
> The issue: What is a "primary variant" and what is an
> implementer supposed to do?

This is given in section "Parameter Choice".

- Do we know if someone has implemented from the draft and

> gotten the correct result? I looked back at the cfrg list
> and didn't see that anyone said they had. It'd be great if
> we knew the text was good enough for that. (It looks fine
> to me, but I've not tried to implement from the draft.)
>
>
I did not check that.

> Nits:
>
> - intro: The URL for [ARGON2ESP] gets me a 404.
> That's: https://www.cryptolux.org/images/0/0d/Argon2ESP.pdf
>
> fixed

> - intro: I don't know what "Argon2 summarizes the state of
> the art" is meant to mean. Maybe you mean that argon2 is
> intended to reflect the current state of the art?
>
> fixed

> - 3.1: can the nonce/salt (S) have zero length?  It looks
> like that would work but be undesirable, so why not set
> a non-zero minimum? (Implementations seem to do that
> already, not sure if with the same minimum.)
>

Yes when bruteforce search is not an issue (key derivation for example).

>
> - 3.1: would it be better to say that the nonce needs to
> appear random and not reveal anything about the password
> as well as being unique-per-password? MD5(pwd) would be
> (sufficiently:-) unique-per-password but would not be a
> good nonce. I guess it's just about possible that an
> implementer might do something that silly;-(
>

No, the nonce does not have to be random. It can (and actually should) be
non-random but unique. In practice, it can be just User ID for many
backends.

>
> - 3.1: are the optional K and X values considered "absent"
> when they have length zero? (I guess so as the lengths are
> input to H_0) It might be better to be explicit about
> that.
>

Added.

>
> - 3.4: 'S' was already defined as the salt, so S = 4 for
> the slices is a bit unfortunate, though not a real issue.
>
>
Fixed

>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>

-- 
Best regards,
Dmitry Khovratovich