Re: [openpgp] The Argon2 proposal seems incomplete (Draft 6)

Daniel Huigens <d.huigens@protonmail.com> Tue, 02 August 2022 16:59 UTC

Return-Path: <d.huigens@protonmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6BCC14CF1D for <openpgp@ietfa.amsl.com>; Tue, 2 Aug 2022 09:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZUcUiANO3In for <openpgp@ietfa.amsl.com>; Tue, 2 Aug 2022 09:59:06 -0700 (PDT)
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8A4C14F74E for <openpgp@ietf.org>; Tue, 2 Aug 2022 09:59:06 -0700 (PDT)
Date: Tue, 02 Aug 2022 16:58:59 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1659459544; x=1659718744; bh=chEIeSBSjAsn4XxkVZeUejogobNN8oVKZdyLOQnSovQ=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=qXmIGgFlVKLl0Pz8hvPGPiinBW5Nwe6KXQOLANMzhUlmIEm7zemkc+P/Zvpmjc3Ot eKmtCDQnnGllVy55sC+vSeLnskou6N2/+xvnrIk1e8VUGn+CUe9g7hcU90wo68L88p IJGYokhO1HrwvAkTo8XpMdkvRX7UW3Kr4Z3CETpDI6k/qIoOVYch7fk6YQEEKC5M4X ZWZftqD+pWsIw1aUEZ4HA+Zp07cCAfdb4iFDhN76//yS7wme1t925Gk89/UMk1cv1R KVZ92Sun4IxK4I0rpYsVhOcdQhnOemspdQnTdyj/67iizM3UDSB2uUAF5rew8uAGCE RkkQAQO5pCRuw==
To: Bruce Walzer <bwalzer@59.ca>
From: Daniel Huigens <d.huigens@protonmail.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Justus Winter <justus@sequoia-pgp.org>, openpgp@ietf.org
Reply-To: Daniel Huigens <d.huigens@protonmail.com>
Message-ID: <Omn5mCBFz0ccFYcDgRjHCKseR_9ixmz1CTG55SDrNRysaY5Ni0i3I8ICzpPNOW0nWKcOnxIuWhUwIugXOdN-zcDil_ftWVALPXWPpSsjWnc=@protonmail.com>
In-Reply-To: <YulNyD1gnC0U+1pN@ohm.59.ca>
References: <YuAErZRsF/KbOw1s@watt.59.ca> <87edy7keb6.fsf@thinkbox> <YuFc+w02FiRQmHcg@watt.59.ca> <87bktajjvq.fsf@thinkbox> <YuKpxp0/Dy1DfC19@watt.59.ca> <875yjhjg2c.fsf@thinkbox> <YuP093G0UKhAJF4U@watt.59.ca> <152ab077-e4c9-7aed-8b44-4e999ed19e89@cs.tcd.ie> <YulNyD1gnC0U+1pN@ohm.59.ca>
Feedback-ID: 2934448:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/31CQGE2UD8S9Gva98SgW-Bg0p7g>
Subject: Re: [openpgp] The Argon2 proposal seems incomplete (Draft 6)
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2022 16:59:10 -0000

On Tuesday, August 2nd, 2022 at 12:16, Bruce Walzer wrote:

> I don't see this as a parameter problem. When Argon2 is used in
> a normal way the parameters (CPU, threads, memory) are deliberately
> set to, as much as is possible, prevent the hash from being done on
> any other system.

This is not true at all. The first recommended parameter set is
explicitly given as a "uniformly safe option that is not tailored to
your application or hardware".

Then, the further steps are only there in case you want an option
that *is* tailored to your hardware, however, even then you can still
build in some safety margin, for example by setting the maximum
affordable time to some percentage of the time you can actually afford,
in case you have to do the computation on a slower device, etc.

> This is true even to the extent that it is designed
> to run badly on any other platform than x86.

Citation needed? Being optimized for the x86 architecture is not the
same as being "designed to run badly on any other platform than x86".

Best,
Daniel