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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 11 December 2019 15:41 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 EB6F7120B58; Wed, 11 Dec 2019 07:41:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 Gk8kQ2JxOuQw; Wed, 11 Dec 2019 07:41:00 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E192120B56; Wed, 11 Dec 2019 07:41:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 00529BE47; Wed, 11 Dec 2019 15:40:56 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_698OUozHr3; Wed, 11 Dec 2019 15:40:56 +0000 (GMT)
Received: from [134.226.36.133] (unknown [134.226.36.133]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AB7BCBE39; Wed, 11 Dec 2019 15:40:56 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1576078856; bh=xbJau8SvvKJivhGeBzwAZt3Z59fBBWkb+wz6Q54LXbY=; h=To:Cc:From:Subject:Date:From; b=koVz5kC6FZupjuhJ7jruYLIQmPf8HxouBfD70LClHStuGy8DU1+N9UQhz65VCCbJ0 PdxchueGpOGhpfY86WdTBkg4DDIFd3+n0uETwAmQ5I4N/p/c5opwzw+ZC6ltG1WaKb WbejqDYRj82h7/ji2uNhfRBbeAg/ewkNoYzcMSns=
To: "cfrg@irtf.org" <Cfrg@irtf.org>
Cc: "irsg@irtf.org" <irsg@irtf.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <5f2c217a-60d2-83a9-f7d4-99997d5d5e65@cs.tcd.ie>
Date: Wed, 11 Dec 2019 15:40:55 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MRIwSJrJeJuliVIc6BMdVJTY2CCEs58I7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/i1ammnFqVxGydbSOTB37St0Pgoo>
Subject: [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: Wed, 11 Dec 2019 15:41:03 -0000

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.