Subject: [openpgp] [PATCH] Updated S2K

From: Nils Durner <[email-masked]>
Date: Mon, 8 Apr 2019 22:14:47 +0200

Hi,

please find the patch for updated S2K attached. It's essentially the content of
    https://gitlab.com/ndurner/rfc4880bis-s2k/tree/master/misc/id/rfc4880bis
plus the Normative Reference updated and now being diff'ed against
    git://git.gnupg.org/people/wk/rfc4880bis.git

Comments? What else is needed to get it into the official draft?

Best regards,

Nils

---

From: Werner Koch <[email-masked]>
Date: Tue, 09 Apr 2019 08:07:17 +0200

On Mon,  8 Apr 2019 22:14, ndurner=[email-masked] said:
>             3  Iterated and Salted S2K
> +           4  Argon2i

I do not think that adding a new S2K algorithm is useful:

The major use cases for OpenPGP are public key operations.  Here we do
not require an S2K algorithm at all.  The S2K is used for the
Transferable Secret Keys which should be a operations performed with
all due diligence: It is better to use a secure channel and best a
symmetric encryption based on a full entropy key.  Without a pairing
algorithm it is often better to write down the key and employ a courier
instead of relying on a weak passphrase and resource intensive KDF.  The
KDF would anyway be needed to be parametrized in a way that it can be
used for export or import on a low end machine.  This is a case by case
decision and we would be better off to not extend the Transferable
Secret Keys format with new methods but use the existing OpenPGP
symmetric key formats.

The other use for an S2K is symmetric encryption.  OpenPGP has only
basic support for this and does not provide any key management functions
for this.  Eventual we will need to add such functions to OpenPGP to
make symmetric encryption a first class citizen of OpenPGP.  Right now
the secure choice you have is to use a full-entropy passphrase and store
it in a separate symmetric key database.  In fact this is a real world
use case of gpg.  I doubt that a Argon2i is in any way helpful here
because it convoys the message that a low-entropy passphrase along with
a resource hungry KDF is an alternative for a secure passphrase.

> -Implementations SHOULD use salted or iterated-and-salted S2K
> -specifiers, as simple S2K specifiers are more vulnerable to dictionary
> -attacks.
> +Implementations MUST generate S2K specifiers that include salts
> +(either type 1, 3 or 4), as simple S2K specifiers are more vulnerable to

The SHOULD is there for a reason: Taking a full-entropy passphrase out
of a database does not require any salt.  It even demands the fastest
KDF we can provide.  This has been discussed in the past.

> +      <reference anchor='Argon2i'
> +     target='https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-argon2-04'>

This is not a useful reference:

   It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 9 Apr 2019 08:23:34 +0000

Werner Koch <[email-masked]> writes:

>The major use cases for OpenPGP are public key operations. 

Are you sure?  PGP is pretty much the universal/default standard for password-
based file encryption.  I have as little data for that as I assume you do for
public-key use, but I'd say there's a lot more password-based encryption done
with it than public-key encryption.

Peter.

---

From: Nils Durner <[email-masked]>
Date: Tue, 9 Apr 2019 21:27:41 +0200

Werner Koch <[email-masked]> writes:

> Right now
> it in a separate symmetric key database.

I agree that this may be the most secure option if it suits your use cases, bank account and exists.

Anecdotally, I personally like to keep keys in my head - and distribute them orally face-to-face, if I need. My use cases include backups (kept on other people’s servers (aka Cloud) and in other people’s homes), proof of prior art (drafts passed on to a lawyer, non-digitally timestamped) and ad-hoc data exchange (data stored on other people’s servers or removable media, key passed on orally and most of the time without even spelling it out). Far more often than I like, this is accomplished with encrypted ZIP files, something I would like to see improved as I believe the ZIP key derivation function is not remotely up to par with the craft & science practiced at PHC. I do not see how storing a full-entropy passphrase in a database for use with an OpenPGP implementation would help with this in a way that would justify its operational and monetary cost.

> I doubt that a Argon2i is in any way helpful here

I’ll be happy to extend my patch in way to make this clear(er), recommending that the UI/UX reinforces the notion of strong passwords/-phrases, best to be chosen completely at random.

> KDF we can provide.  This has been discussed in the past.

Right, my mistake then. But what’s the sense in hashing it prior to using it as per Type 0 either? I’m currently more inclined to establish another type „5“ to make raw key use explicit, as Peter Gutmann suggested in 2015.

Any other considerations/opinions/… from others?

>   material or to cite them other than as "work in progress.

What do you suggest? Revert back to:
      <reference anchor='Argon2i'
     target='https://www.cryptolux.org/images/0/0d/Argon2.pdf'>
        <front>
        <title>Argon2: the memory-hard function for password hashing and other applications</title>
        <author surname="Biryukov" initials="A." />
        <author surname="Dinu" initials="D." />
        <author surname="Khovratovich" initials="D." />
        <date year='2015' month='October'/>
        </front>
      </reference>
?

Best regards,

Nils

---

From: Marcus Brinkmann <[email-masked]>
Date: Tue, 9 Apr 2019 23:54:36 +0200

Hi,

please see the attached graph of SKS keyserver uploads per month and
daily enigmail users (a plugin for thunderbird).  It's pretty obvious
that Snowden created at least some use of PGP email (although there are
signs that post-Snowden activity has peaked and is already stagnating or
in decline).

>From a standardization point of view, I think Email is a much more
important use case than plain file encryption, given interoperability
concerns and lack of alternatives.  From my experience, PGP is basically
synonymous with Email security for people who are familiar with the term
at all.

Thanks,
Marcus

On 4/9/19 10:23 AM, Peter Gutmann wrote:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
> 

-- 
Dipl.-Math. Marcus Brinkmann

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
Universitätsstr. 150, Geb. ID 2/461
D-44780 Bochum

Telefon: +49 (0) 234 / 32-25030
http://www.nds.rub.de/chair/people/mbrinkmann

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 12 Apr 2019 11:13:45 -0500

>    material or to cite them other than as "work in progress.

With all due respect, that CFRG document is likely to get published well
before 4880bis, and it is entirely normal for I-Ds to cite other related
I-Ds.  Dependency chains and avoidance of referring normatively to "works
in progress" is handled as part of the normal operation of the RFC Editor
function.

So I must disagree with the statement that this is "not a useful
reference".

-Ben