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/
- [Cfrg] IRSG review of draft-irtf-cfrg-argon2-09 Stephen Farrell
- Re: [Cfrg] IRSG review of draft-irtf-cfrg-argon2-… Colin Perkins
- Re: [Cfrg] IRSG review of draft-irtf-cfrg-argon2-… Dmitry Khovratovich