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

Colin Perkins <csp@csperkins.org> Thu, 12 December 2019 18:38 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D2212016E; Thu, 12 Dec 2019 10:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iHO97QZzojp; Thu, 12 Dec 2019 10:38:10 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [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 ietfa.amsl.com (Postfix) with ESMTPS id 5558B1200E5; Thu, 12 Dec 2019 10:38:10 -0800 (PST)
Received: from [82.152.40.192] (port=52957 helo=[192.168.1.114]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) 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 <csp@csperkins.org>
In-Reply-To: <5f2c217a-60d2-83a9-f7d4-99997d5d5e65@cs.tcd.ie>
Date: Thu, 12 Dec 2019 18:37:56 +0000
Cc: "cfrg@irtf.org" <Cfrg@irtf.org>, "irsg@irtf.org" <irsg@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <75AF5F69-F44A-473A-A35E-9DE1561495B2@csperkins.org>
References: <5f2c217a-60d2-83a9-f7d4-99997d5d5e65@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/5JvKGs91HEO3kXqbck5W6Itz1SQ>
Subject: Re: [Cfrg] IRSG review of draft-irtf-cfrg-argon2-09
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=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.

Thanks,
Colin



> On 11 Dec 2019, at 15:40, Stephen Farrell <stephen.farrell@cs.tcd.ie> 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: https://www.cryptolux.org/images/0/0d/Argon2ESP.pdf
> 
> - 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
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg



-- 
Colin Perkins
https://csperkins.org/