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

Colin Perkins <> Thu, 12 December 2019 18:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7D2212016E; Thu, 12 Dec 2019 10:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7iHO97QZzojp; Thu, 12 Dec 2019 10:38:10 -0800 (PST)
Received: from ( [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5558B1200E5; Thu, 12 Dec 2019 10:38:10 -0800 (PST)
Received: from [] (port=52957 helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1ifTLg-0000R0-Cu; Thu, 12 Dec 2019 18:38:09 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Thu, 12 Dec 2019 18:37:56 +0000
Cc: "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <>
Subject: Re: [Cfrg] IRSG review of draft-irtf-cfrg-argon2-09
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Dec 2019 18:38:13 -0000

Thank you for reviewing!

Authors, if you can please take a look at the comments below and revise the draft as appropriate, then I’ll consider moving it on to the next stage.


> On 11 Dec 2019, at 15:40, Stephen Farrell <> wrote:
> Hiya,
> I did an IRSG review for this. I think it's basically
> ready but with one issue to address before publication.
> As an aside, I set some password-cracking student
> assignments a year or so ago, and the kids all hated
> argon2 as it was the only algorithm (from those I
> set) that they couldn't crack, despite chewing up
> loads of CPU:-) IOW, I really like the algorithm,
> the issues below are only about the documentation
> and interop.
> Cheers,
> S.
> The issue: What is a "primary variant" and what is an
> implementer supposed to do?  I don't think this has quite
> been resolved sufficiently. The interop requirement here
> is mostly (I think) that independent password hashing and
> verification implementations be able to work for the same
> data. I'm guessing it's too late to just ditch all but one
> set of parameters, but I think It'd be better to say e.g.
> that argon2id with salt-len foo, m=whatever, p=something etc.
> (fill in a currently reasonable value for *all* of the
> parameters) MUST be implemented, MUST be usable (i.e.
> exposed via command line or parameters) and SHOULD be
> the default. If we don't have that, then I figure we'll end
> up with interop problems. (See also below about test vectors.)
> If what's reasonable changes over time, then an update to
> the RFC or some new algorithm could address that but I'd hope
> it ought be possible to choose one set of parameters that
> we expect to be usable (as a default) for say 5+ years.
> I've also two non-blocking suggestions/questions that
> ought not get in the way of publication, but the authors
> might wanna consider 'em:
> - Test vectors: it'd have been nice (for me) if I could
> verify one of the test vectors using either the debian
> command line tool or python-cffi, the two implementations
> I have to hand, but I can't. The test vectors all include
> parameters that aren't exposed by those implementations
> (at least, I think so, having looked for a few minutes).
> The values used in the test vectors are also binary
> which'd make it a bit more work even if e.g. there was no
> secret or associated data. Could you add another test
> vector (or two) that can be verified with current tools
> (e.g. the debian command line tool that I got with "apt
> install argon2" on Ubuntu)?  I think it'd be great if the
> RFC and those tools were compatible, not great but fixable
> if they are not, but it's a bit of a pity that I can't
> tell;-)
> - 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.)
> Nits:
> - intro: The URL for [ARGON2ESP] gets me a 404.
> That's:
> - 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?
> - 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.)
> - 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;-(
> - 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.
> - 3.4: 'S' was already defined as the salt, so S = 4 for
> the slices is a bit unfortunate, though not a real issue.
> <0x5AB2FAF17B172BEA.asc>_______________________________________________
> Cfrg mailing list

Colin Perkins