IETF Logo Mail Archive

Re: [openpgp] Sec. Considerations MUST about S2K [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt]

Ángel <angel@16bits.net> Sun, 28 February 2021 22:09 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 61AF73A086E for <openpgp@ietfa.amsl.com>; Sun, 28 Feb 2021 14:09:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 H5iUot8zed9c for <openpgp@ietfa.amsl.com>; Sun, 28 Feb 2021 14:09:07 -0800 (PST)
Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (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 ADD093A085E for <openpgp@ietf.org>; Sun, 28 Feb 2021 14:09:07 -0800 (PST)
Message-ID: <4a4f4ca9aa11c850bfcd5ebde7e3d57f51fdf38a.camel@16bits.net>
From: Ángel <angel@16bits.net>
To: openpgp@ietf.org
Date: Sun, 28 Feb 2021 23:09:03 +0100
In-Reply-To: <1614483966879.85613@cs.auckland.ac.nz>
References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <87h7lzavvc.wl-neal@walfield.org>,<87mtvqcdtk.fsf@fifthhorseman.net> <1614483966879.85613@cs.auckland.ac.nz>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/xjY4uPGvHwRHkmOubgzLPW1JYGY>
Subject: Re: [openpgp] Sec. Considerations MUST about S2K [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt]
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 28 Feb 2021 22:09:09 -0000

On 2021-02-28 at 03:46 +0000, Peter Gutmann wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
> 
> > I'm not sure about this at all.  For example, consider a system
> > that knows
> > that the string is high-entropy ("good key equivalent") -- should
> > they be
> > prohibited from using Simple or Salted S2K?  Is this MUST really an
> > interoperability concern as §6 of RFC 2119 suggests?
> 
> Agreed, but it's a pretty simple fix:
> 
>   Where it's likely that a low-entropy secret is being employed, a
> compliant
>   application SHOULD use [...]
> 
> Peter.


I would suggest a didactic approach, something like
> Simple S2K and Salted S2K specifiers are not particularly secure 
> when used with a low-entropy secret, such as those typically provided
> by users, and implementations SHOULD avoid using these methods on
> encryption of both keys and messages.


Best regards

v2.23.0 | Report a Bug | By Email