Subject: Re: [openpgp] [PATCH] RFC4880bis: Argon2i

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 03 Nov 2015 10:20:26 +0900

Hi Nils--

On Sun 2015-10-18 23:20:05 +0900, Nils Durner wrote:

> attached is a patch against RFC 4880bis in
> git://git.gnupg.org/gnupg-doc.git to include Argon2i as an S2K method.

Thanks for this patch!  Since Argon2 is the winner of the
password-hashing competition [0], and Argon2i is the variant of Argon2
that is intended for password-based key derivation, this seems like a
good candidate.

If we introduce this as a normative dependency for OpenPGP, though, we
might also want to have an IETF RFC for Argon2.  Do you know of anyone
working on such a draft?  I don't see anythng posted at the datatracker:

 https://datatracker.ietf.org/doc/search/?name=argon&activedrafts=on&rfcs=on

If anyone else knows of efforts to document argon2, or wants to advance
such a draft, i'd be happy to hear about it.

     --dkg

[0] https://password-hashing.net/

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 3 Nov 2015 02:48:07 +0000

Daniel Kahn Gillmor <[email-masked]> writes:

>If we introduce this as a normative dependency for OpenPGP, though, we might
>also want to have an IETF RFC for Argon2.  Do you know of anyone working on
>such a draft?

Uh, yeah, started it, got distracted by other work, I'll take this as a hint
to finish it :-).  I was going to post it here first in any case to get
feedback, since it's more a proposal that needs comment on how people would
prefer certain things to be done.

Peter.

---

From: ianG <[email-masked]>
Date: Tue, 3 Nov 2015 03:52:16 +0000

On 3/11/2015 01:20 am, Daniel Kahn Gillmor wrote:
> If we introduce this as a normative dependency for OpenPGP,

I agree with all the rest, but can we also deprecate some old stuff as well?

Can we construct a plan e.g., that no existing S2K be used with new keys 
and the new form not be used with old keys?

Or *something* to avoid the monotonically increasing algorithmic bloat 
that seems so trendy.

iang

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 03 Nov 2015 12:55:04 +0900

On Tue 2015-11-03 11:48:07 +0900, Peter Gutmann wrote:
> to finish it :-).

Please do, thank you!

> I was going to post it here first in any case to get feedback, since
> it's more a proposal that needs comment on how people would prefer
> certain things to be done.

I'm happy to have it posted here for review.  If it's a description of
the algorithm on its own, we can also point the CFRG at it.

    --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 03 Nov 2015 13:43:59 +0900

> I agree with all the rest, but can we also deprecate some old stuff as well?

Ian's proposed change actually does deprecate some old stuff.  Maybe it
doesn't go far enough, though.

> Or *something* to avoid the monotonically increasing algorithmic bloat 

Yes, we'll be talking about algorithm deprecation at the meeting later
today.

        --dkg

---

From: Nils Durner <[email-masked]>
Date: Tue, 3 Nov 2015 07:45:44 +0100

Hi Daniel,

> working on such a draft?

Simon Josefsson has expressed interest in helping with that.
@Simon: are you working on this?

Regards,

Nils

---

From: Nils Durner <[email-masked]>
Date: Tue, 3 Nov 2015 07:54:48 +0100

Hi Ian,

> Can we construct a plan e.g., that no existing S2K be used with new
> keys and the new form not be used with old keys?

I have made salt-based methods mandatory in my patch:
> +Implementations MUST generate S2K specifiers that include salts
> +(either type 2, 3 or 4), as simple S2K specifiers are more vulnerable to
(type 2 should actually be "type 1")
> +dictionary attacks. Use of Argon2i is RECOMMENDED as it offers
> +protection against massive-parallel and side-channel attacks. When
> +reading S2K specifiers that do not include salts, implementations SHOULD
> +issue a warning about potentially insecure methods being used. When
> +reading S2K specifiers other than Argon2i, implementations SHOULD issue
> +a warning about outdated methods being used.

We can of course raise the bar by excluding types 1 & 3 entirely.

Regards,

Nils

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 3 Nov 2015 09:20:06 +0100

Den Tue, 3 Nov 2015 07:45:44 +0100
skrev Re: [openpgp] [PATCH] RFC4880bis: Argon2i:

> Hi Daniel,
> 
> > If we introduce this as a normative dependency for OpenPGP, though,
> > we might also want to have an IETF RFC for Argon2.  Do you know of
> > anyone working on such a draft?
> 

I started on an Argon2 draft but after talking to the Argon2 team we
decided to wait until Argon2 was finalized.  I suppose now is a good
time to resume that work.  I'll put something up on gitlab.com so
people can review and help.  If anyone wants to help, please let me
know and we'll coordinate something.

/Simon

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 3 Nov 2015 18:47:12 +0900

At IETF94 one question that came up in trying to move quickly to
support Argon2 is the potential IPR that might be in Argon2. The code
available now [1] is CC0 which, AFAICT, doesn't have any patent grant
or implication for patents, etc., meaning the authors could still
claim something, precluding it from use without a waiver (or whatever,
IANAL)

I'll CC the Argon2 authors (on the Argon2 spec [2]) here and see if we
can clarify any potential IPR and whether that might affect using it
in the future in OpenPGP.

best, Joe

[1]: https://github.com/p-h-c/phc-winner-argon2
[2]: https://password-hashing.net/argon2-specs.pdf

On Tue, Nov 3, 2015 at 5:20 PM, Simon Josefsson <[email-masked]> wrote:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Werner Koch <[email-masked]>
Date: Tue, 03 Nov 2015 12:02:25 +0100

> +(either type 2, 3 or 4), as simple S2K specifiers are more vulnerable to

Type 2 is not defined but reserved, you probably meant type 1.

I also assume you allow type 1 (Salted S2K) to allow the use of an
entire random passphrase, right?  The salt then acts as IV for the SESK.
Should we explain this use of type 1?

Shalom-Salam,

   Werner

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

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 3 Nov 2015 20:56:43 +0900

Congratulations btw on winning the competition!

Kathleen and Stephen can confirm, but I believe you don't have to do
anything in terms of adding any language in this case (no patent
issued/sought, patent pending, etc.). When/if the document is adopted by
the working group, the chair will request any disclosures.

On Tuesday, November 3, 2015, Alex Biryukov <[email-masked]> wrote:

> Hi all,
>
> We were not intending to patent it, so we can add a sentence about it.
> Suggestions of lawyer-happy phrases are welcome.
>
> Alex
>
> On Tue, Nov 3, 2015 at 10:47 AM, Joseph Lorenzo Hall <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> On Tue, Nov 3, 2015 at 5:20 PM, Simon Josefsson <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> > [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> ---------------------------------
> Prof. Dr. Alex Biryukov,
> FSTC/CSC, University of Luxembourg,
> 6, rue Richard Coudenhove-Kalergi,
> L-1359 Luxembourg-Kirchberg
> LUXEMBOURG
> Tel:  +352 46 66 44 6793
> Fax: +352 46 66 44 5500
>

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 3 Nov 2015 12:17:58 +0000

>We can of course raise the bar by excluding types 1 & 3 entirely.

1 and 3?  I assume you mean 0 and 1, with 2 being unused anyway.  There should
really only be a 3, a straight hash or salted hash is barely better than just
using the password directly.

(They also seem to be virtually unused in practice, some time ago I
inadvertently disabled use of 0 and 1 in my code and, after zero complaints
over this, made the change permanent).

Peter.

---

From: Nils Durner <[email-masked]>
Date: Tue, 3 Nov 2015 22:06:09 +0100

Hi Werner,

> Type 2 is not defined but reserved, you probably meant type 1.

Right. Fixed in
https://gitlab.com/ndurner/rfc4880bis-s2k/blob/master/misc/id/rfc4880bis/middle.mkd

Absolutely. What do you think about:
> diff --git a/misc/id/rfc4880bis/middle.mkd b/misc/id/rfc4880bis/middle.mkd
> index 2ab0100..6987f6e 100644
> --- a/misc/id/rfc4880bis/middle.mkd
> +++ b/misc/id/rfc4880bis/middle.mkd
> @@ -379,7 +379,9 @@ time independently of the memory size.
>  
>  Implementations MUST generate S2K specifiers that include salts
>  (either type 1, 3 or 4), as simple S2K specifiers are more vulnerable to
> -dictionary attacks. Use of Argon2i is RECOMMENDED as it offers
> +dictionary attacks. Type 1 MAY only be generated if the string is
> +entirely random and the salt is used as an IV.
> +Use of Argon2i is RECOMMENDED as it offers
>  protection against massive-parallel and side-channel attacks. When
>  reading S2K specifiers that do not include salts, implementations SHOULD
>  issue a warning about potentially insecure methods being used. When

?

Regards,

Nils

---

From: Nils Durner <[email-masked]>
Date: Tue, 3 Nov 2015 22:19:17 +0100

Hi Peter,

> 1 and 3?  I assume you mean 0 and 1, with 2 being unused anyway.

I meant 0, 1, 3 - thus only allowing to generate (the new Argon2i-based)
4. Sorry for the confusion.

> There should

That is certainly one of the safest options for actual passwords, but
gets in the way of symmetric keys (cheaply) being used as passphrases.
Are you content with rather limiting the permitted use case for type 1
(and not allowing type 0) as per my previous mail in response to Werner
(and pushed to
https://gitlab.com/ndurner/rfc4880bis-s2k/blob/master/misc/id/rfc4880bis/middle.mkd)?

Regards,

Nils

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 4 Nov 2015 00:33:51 +0000

Nils Durner <[email-masked]> writes:

>That is certainly one of the safest options for actual passwords, but gets in
>the way of symmetric keys (cheaply) being used as passphrases.

Hmm, yeah, but if you've already got a raw symmetric key (which won't need any
extra processing) I'd lean towards having it identified as such rather than
overloading a password-processing mechanism for it.  In other words make the
use for symmetric key transport explicit rather than relying on the
implementer to somehow know that S2K type X is meant to be used for symkey
transport.

So perhaps have type 4 = Argon2, type 5 = symmetric key transport, with a
safety note added to say that it's meant for randomly-generated symmetric keys
that are already, in effect, in the post-S2K state.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Nov 2015 00:48:52 +0000

Hiya,

One way to handle this might be to add the winners as
co-authors on the Internet-draft. In that case, the
draft boilerplate text says that you're following the IETF
IPR rules and hence would have filed an IPR declaration
if one was needed. And if none is needed, we'd be done.

I'm sure we can figure other options but the above would
be easiest from the IETF point of view.

Cheers,
S.

---

From: Werner Koch <[email-masked]>
Date: Wed, 04 Nov 2015 09:09:17 +0100

> that are already, in effect, in the post-S2K state.

That would be fine for new code.  Nevertheless implementations need to
support reading type 1 until all backup media as worn out.  Thus I doubt
that requiring an extra code path is the way to go.

Shalom-Salam,

   Werner

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Nov 2015 09:25:02 +0100

We have now pushed out a -00 strawman on Argon2 in ID form:

https://tools.ietf.org/html/draft-josefsson-argon2-00

I'm not happy with the explanation of the H' and G functions, and the
permutation P (from BLAKE2b) and the indexing section are missing.
Reference code in a higher-level language like python would be useful.
If those things, and an ASN.1 schema is added, I believe the document
would be good to go.

We need to have an IETF discussion whether we are interested in the
Argon2d non-side-channel safe variant.  The Argon2 paper implies that
the Argon2i side-channel safe variant is for "dangerous settings" where
you need side-channel safety.  For Internet use I believe we have
already passed the point where we can ignore side-channel concerns,
since they have been used in several successful attacks already.  This
could be resolved in the security considerations, but I'm concerned
about giving people too much rope here.

/Simon

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Nov 2015 08:50:36 +0000

Process-wise, I think the thing to do with this is
to handle it as a cfrg draft. (I'll forward this
there and as if they wanna adopt it.)

Cheers,
S

On 05/11/15 08:32, Dmitry Khovratovich wrote:
> Thank you, Simon!
> 
> I will review your draft and give comments ASAP
> 
> Dmitry
> 
> Sent from my iPad
> 
>> On Nov 5, 2015, at 09:25, Simon Josefsson <[email-masked]> wrote:
>>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Nov 2015 12:31:22 +0100

There is not a lot of cryptocurrency standardisation going on in the IETF, alas. What do you think about using the term "proof of work" in the title instead? It appears to be the cryptographic property that cryptocurrencies (and other applications!) want from a primitive. I perceive that other PoW-ideas may be standardized in the IETF before currencies are.

Have you or anyone provided security reductions for Argon2 btw? Similar to the reductions that are available for Catena.  They would help to substantiate any claims in the document that Argon2 is secure for its intended uses.

/Simon

Alex Biryukov <[email-masked]> skrev: (5 november 2015 12:07:17 CET)
>We discussed it briefly, would it be possible to add "cryptocurrency"
>to
>the title to cover two main usage areas. Then it would  make sense to
>keep
>both Argon2i and Argon2d in the standard.
>
>"The memory-hard Argon2 password and cryptocurrency hash function
>draft-josefsson-argon2-00
>
>
>On Thu, Nov 5, 2015 at 9:25 AM, Simon Josefsson <[email-masked]>
>wrote:
>
>though,
><javascript:_e(%7B%7D,'cvml',[email-masked]');>

-- 
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.

---

From: Ian G <[email-masked]>
Date: Thu, 5 Nov 2015 19:21:23 +0000

> There is not a lot of cryptocurrency standardisation going on in the IETF, alas. What do you think about using the term "proof of work" in the title instead? It appears to be the cryptographic prop…

If argon is being proposed for a proof of work only then it should not 
include cryptocurrency in the title.

Also, standardisation in the cryptocurrency world works a bit different 
to how it works in IETF WG fashion - I'm not sure I can see the 
benefit.  Standardisation works best when the system is already out 
there and in use, not as sort of trial balloon - is argon in use in any 
systems as a PoW?

Colour me skeptical!

iang

---

From: ianG <[email-masked]>
Date: Sun, 8 Nov 2015 10:49:38 +0000

> We can of course raise the bar by excluding types 1 & 3 entirely.

That's what I would do.  Mode 4 is the only produced option in the new 
format.

  + Implementations MUST write in Argon2i and SHOULD read old formats.

Implementations will of course offer options to add back in 0,1,3, 
especially where the reading code is stuck on old format, and the 
writing code is new format.

But they won't be compliant.  And we can ostracise them accordingly, 
tell them they're using worse than MD5 and they're to blame for global 
warming and bad coffee.

iang