Re: [openpgp] The Argon2 proposal seems incomplete (Draft 6)
Ángel <angel@16bits.net> Mon, 03 October 2022 00:25 UTC
Return-Path: <angel@16bits.net>
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 07E61C14F5E1 for <openpgp@ietfa.amsl.com>; Sun, 2 Oct 2022 17:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=16bits.net header.b=EhxNSgW8; dkim=pass (2048-bit key) header.d=16bits.net header.b=jimSmL5e
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 JAl_gunMrhYX for <openpgp@ietfa.amsl.com>; Sun, 2 Oct 2022 17:25:21 -0700 (PDT)
Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD612C14F607 for <openpgp@ietf.org>; Sun, 2 Oct 2022 17:25:21 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=16bits.net; s=ec2208; t=1664756718; bh=prvs8WAQZ/FeloEGSGUms51kAHyWpFLMGVLKoaGYc8k=; h=Subject:From:To:Date:In-Reply-To:References:Content-Type: Content-Transfer-Encoding:MIME-Version; b=EhxNSgW8oKyitgiCJ+uljaEpG5I5aNRMgRyAEPncsmuCI1ukM2AIPfPIV4LrPWg7S 8eqI+Or5AOBd4zvBvAjAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=16bits.net; s=rsa2208; t=1664756718; bh=prvs8WAQZ/FeloEGSGUms51kAHyWpFLMGVLKoaGYc8k=; h=Subject:From:To:Date:In-Reply-To:References:Content-Type: Content-Transfer-Encoding:MIME-Version; b=jimSmL5e/a++YB9ke4pKWLXNRLqpM5GdHiLEcvSPxNvMUSJsNq5h6sDjGtNGUUs0g 8MUSyVajBdXWYG9F8OOS1eRpGY/U7+0s8GowEoDxW42G7e7y5Zzft9pdcVTTLRL3I+ 52zN66ckjtBfWfLKsXiFcuwhjqk7I64E1EcBP9rGvCZDBe7DRgIqvEjce97rCyDSCG UtnoowIv3TCFg0w5sGRXkNt7x2n0pD/LnUd8IyvUv+J+gY6U2FESn045cncUvmVXoM TXJwCo+450WytbjMfiWh9skS9kZFj2QsehXI3I6nV/e37yH9lsVVLMaXHTm9xQ7mmO NTTy+VqAlrFIA==
Message-ID: <c2785440c81195be09ad6c1fcb4c59ac163f220c.camel@16bits.net>
From: Ángel <angel@16bits.net>
To: openpgp@ietf.org
Date: Mon, 03 Oct 2022 02:25:18 +0200
In-Reply-To: <YuRdV/XwUAveN56B@tapette.crustytoothpaste.net>
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> <YuRdV/XwUAveN56B@tapette.crustytoothpaste.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/NamX4APgU6xhZhnVacoqbLUV0mg>
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: Mon, 03 Oct 2022 00:25:26 -0000
On 2022-07-29 at 22:21 +0000, brian m. carlson wrote: > It is also the case that the sender can send a message which exceeds > the resources of the receiving system. If the sender earnestly > wishes to communicate to the receiver, that is of course silly and > should be avoided. What if the goal of the sender is not to communicate with the receiver but to break it? I'm late to the party, but this is a point that has not been mentioned before and I think it is worth pointing out. A client SHOULD have some limit to avoid a "Zip bomb" equivalent with the Argon2 function (this is not specific to Argon, the same issue exist with any other memory hard function). Let's call it a "memory bomb". It's not acceptable that an attacker sends a symmetric encrypted email requiring orders of magnitude more memory than available and that causes: * A PGP remailer to go down * A MUA to crash * An open browser to crash * A backup server no longer accepting backups * The receiving system slows down until it swaps everything and the OOM killer is finally run even if there is some user interaction needed (like providing a passphrase) where the user is not warned beforehand of the adverse effects. As a mitigating factor, the S2K is used in two cases: * Storage of private keys (and one should not be importing untrusted private keys) * Usage with symmetric encryption (whereas most scenarios should actually be using public-key cryptography instead) However, I wouldn't be surprised if programs intended to be used with public key crypto actually attempted symmetric decryption, such as trying a private key passphrase against a Symmetric-key Encrypted Session Key or importing a private key when provided what should have been a public key. I think this deserves a security note in the document about the need of enforcing _some_ limit. Options available to implementations include setting an arbitrary limit to the memory they are willing to use for S2K (hardcoded or in config), dynamically compute an "appropriate limit", to support processing packets larger than those limits but requesting user confirmation for potentially using lots of memory… Regards
- [openpgp] The Argon2 proposal seems incomplete (D… Bruce Walzer
- Re: [openpgp] The Argon2 proposal seems incomplet… Justus Winter
- Re: [openpgp] The Argon2 proposal seems incomplet… Bruce Walzer
- Re: [openpgp] The Argon2 proposal seems incomplet… Daniel Huigens
- Re: [openpgp] The Argon2 proposal seems incomplet… Justus Winter
- Re: [openpgp] The Argon2 proposal seems incomplet… Bruce Walzer
- Re: [openpgp] The Argon2 proposal seems incomplet… Justus Winter
- Re: [openpgp] The Argon2 proposal seems incomplet… Werner Koch
- Re: [openpgp] The Argon2 proposal seems incomplet… Paul Wouters
- Re: [openpgp] The Argon2 proposal seems incomplet… Bruce Walzer
- Re: [openpgp] The Argon2 proposal seems incomplet… brian m. carlson
- Re: [openpgp] The Argon2 proposal seems incomplet… Stephen Farrell
- Re: [openpgp] The Argon2 proposal seems incomplet… Bruce Walzer
- Re: [openpgp] The Argon2 proposal seems incomplet… Daniel Huigens
- [openpgp] OpenPGP encryption block modes (Was: Th… Bruce Walzer
- Re: [openpgp] OpenPGP encryption block modes (Was… Daniel Huigens
- Re: [openpgp] OpenPGP encryption block modes (Was… Peter Gutmann
- Re: [openpgp] OpenPGP encryption block modes (Was… Stephen Farrell
- Re: [openpgp] OpenPGP encryption block modes (Was… Benjamin Kaduk
- Re: [openpgp] OpenPGP encryption block modes (Was… Bruce Walzer
- Re: [openpgp] The Argon2 proposal seems incomplet… Bruce Walzer
- Re: [openpgp] The Argon2 proposal seems incomplet… Daniel Huigens
- Re: [openpgp] OpenPGP encryption block modes (Was… Bruce Walzer
- Re: [openpgp] The Argon2 proposal seems incomplet… Bruce Walzer
- Re: [openpgp] OpenPGP encryption block modes (Was… Daniel Huigens
- Re: [openpgp] The Argon2 proposal seems incomplet… Daniel Huigens
- Re: [openpgp] OpenPGP encryption block modes Werner Koch
- Re: [openpgp] OpenPGP encryption block modes Aron Wussler
- Re: [openpgp] OpenPGP encryption block modes Bruce Walzer
- Re: [openpgp] OpenPGP encryption block modes Daniel Huigens
- Re: [openpgp] OpenPGP encryption block modes Aron Wussler
- Re: [openpgp] OpenPGP encryption block modes (Was… Phillip Hallam-Baker
- Re: [openpgp] OpenPGP encryption block modes (Was… Marcus Brinkmann
- Re: [openpgp] OpenPGP encryption block modes Bruce Walzer
- Re: [openpgp] OpenPGP encryption block modes brian m. carlson
- Re: [openpgp] OpenPGP encryption block modes Werner Koch
- Re: [openpgp] OpenPGP encryption block modes Peter Gutmann
- Re: [openpgp] OpenPGP encryption block modes Bruce Walzer
- Re: [openpgp] OpenPGP encryption block modes brian m. carlson
- Re: [openpgp] OpenPGP encryption block modes Stephen Farrell
- Re: [openpgp] OpenPGP encryption block modes Peter Gutmann
- Re: [openpgp] OpenPGP encryption block modes Bruce Walzer
- Re: [openpgp] OpenPGP encryption block modes Bruce Walzer
- Re: [openpgp] OpenPGP encryption block modes Daniel Huigens
- Re: [openpgp] OpenPGP encryption block modes Werner Koch
- Re: [openpgp] OpenPGP encryption block modes (Was… Stephen Farrell
- Re: [openpgp] OpenPGP encryption block modes (Was… Bruce Walzer
- Re: [openpgp] OpenPGP encryption block modes (Was… Marcus Brinkmann
- Re: [openpgp] OpenPGP encryption block modes (Was… Bruce Walzer
- Re: [openpgp] The Argon2 proposal seems incomplet… Ángel
- Re: [openpgp] The Argon2 proposal seems incomplet… Daniel Kahn Gillmor