Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Any plans to RFC document? #271

Open
mbroz opened this issue May 29, 2019 · 21 comments
Open

Any plans to RFC document? #271

mbroz opened this issue May 29, 2019 · 21 comments

Comments

@mbroz
Copy link
Contributor

mbroz commented May 29, 2019

Hi,
I know that this is not a code issue, but I think it would be better to track it here anyway.

The RFC draft for Argon2 just expired again, apparently without any action from CFRG https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/.

Is there anyone (authors, maintainers) who actually plan to push this RFC or it is finally abandoned?

We use Argon2 in LUKS2 disk encryption, and absence of any "normative" document basically ends any discussions with corporate security people. Also, the absence of such a document means that we are forced to bundle implementation (instead of including it in common cryptography libraries), and that is not a good practice anyway.
@khovratovich
Copy link
Member

khovratovich commented May 29, 2019 via email

@mbroz
Copy link
Contributor Author

mbroz commented May 29, 2019

Thanks!

@mbroz mbroz mentioned this issue Jul 23, 2019
Closed
1 task
@khovratovich
Copy link
Member

Some update: we have reached almost the last step, but the IRTF chair asked if the reference code in the RFC draft can be made compilable. It can not so we are now thinking how to reflect this in the doc while minimizing changes to the draft.

@mbroz
Copy link
Contributor Author

mbroz commented Aug 4, 2019

Thanks for the info!

It is interesting request. I would personally prefer code readability to copy&paste version (and reference to full-blown implementation in some public SCM). Also it seems to me much more important that RFC contains usable test vectors, so I can easily test deployed code for trivial mistakes.

@mbroz
Copy link
Contributor Author

mbroz commented Feb 7, 2020

Hi, I think that discussion related to merging Argon2 to OpenSSL code (see openssl/openssl#9444) is very near to some consensus. Acoording to some discussions I see the main blocker now becomes the unfinished RFC document.
It seems that there are only some small changes requested now by IRSG (https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/history/), is there any chance that it becomes formal standard in next few weeks?

@khovratovich
Copy link
Member

khovratovich commented Feb 7, 2020 via email

@ranisalt ranisalt mentioned this issue Mar 20, 2020
Closed
@ranisalt
Copy link
Contributor

In the issue mentioned above we are discussing the recommended default version. The specs.pdf on this repo recommends Argon2i, and it's the default CLI version, but the draft recommends Argon2id, which one is a sensible, recommended default?

@SparkDustJoe
Copy link

the draft recommends Argon2id

To best protect against weak operations in "i" (if using only a few iterations), and side-channel attacks possible with "d", mine would be "id", full stop, with at least 20 iterations regardless of the other parameters. Tuning would be needed per application, and heavy use of the "AD" and "Secret" inputs is also a smart move to introduce more information an attacker has to consider, and to isolate systems from attacks against other systems that use only the "recommended/OOTB" defaults of whatever standard is adopted in the RFC. Unfortunately, and all too often, implementers of hashing standards like these abuse the salt by not making it random (such as by deriving it from the username when hashing passwords) or long enough, so having system/user/purpose specific parameters fed into the AD and Secret go a long way to protecting the system as a whole.

@ranisalt
Copy link
Contributor

@SparkDustJoe thanks for the long explanation, but my question is much simpler: as a library developer, what should I use as defaults, when the user just wants to run hash(password) and forget about the details?

@SparkDustJoe
Copy link

SparkDustJoe commented Mar 20, 2020 •
edited

the user just wants to run hash(password) and forget about the details

Yikes... I would hope in your output that the Salt is somehow included with a matching verify(password) that expects to find it and actually uses it. Without that, it's still inviting disaster.

I would still stick to about 15 iterations in "id", and tune the memory and parallelism so that you're sticking to under 2s processing time (no less than 200ms for safety). Consider your machine may not be typical and test on older hardware if you have it.

@ghost
Copy link

ghost commented Apr 17, 2020

the user just wants to run hash(password) and forget about the details

Yikes... I would hope in your output that the Salt is somehow included with a matching verify(password) that expects to find it and actually uses it. Without that, it's still inviting disaster.

I would still stick to about 15 iterations in "id", and tune the memory and parallelism so that you're sticking to under 2s processing time (no less than 200ms for safety). Consider your machine may not be typical and test on older hardware if you have it.

Hi,

I'm confused, in your first reply you recommend for "at least 20 iterations", now you recommend "about 15 iterations" while the latest draft for argon2id clearly recommends 1 iteration, if I understand this section correct?:
https://tools.ietf.org/html/draft-irtf-cfrg-argon2-10#section-8.4

Can anyone clarify which setting for the iteration count t is recommended and why?

I must admit that I would wish for clearer recommendations for end users.
I'm currently having a hard time advising my dev team, regarding this.
Currently for most parameters it says: test for yourself on your hardware.

I appreciate all the hard work going into this and I know it's not easy to recommend sensible and sane defaults, but maybe someone can make this more clear for mere mortals like me?

@khovratovich
Copy link
Member

khovratovich commented Apr 17, 2020 via email

@ghost
Copy link

ghost commented Apr 17, 2020 •
edited by ghost

For t>2 the security level scales linearly with t. That's why our advice is to select the maximum possible t "depending on your hardware". Mere recommending certain t like 2 or 20 will result in too low security on fast servers or too low performance on slow servers.
…
On Fri, Apr 17, 2020 at 10:25 AM Sven Kieske @.***> wrote: the user just wants to run hash(password) and forget about the details Yikes... I would hope in your output that the Salt is somehow included with a matching verify(password) that expects to find it and actually uses it. Without that, it's still inviting disaster. I would still stick to about 15 iterations in "id", and tune the memory and parallelism so that you're sticking to under 2s processing time (no less than 200ms for safety). Consider your machine may not be typical and test on older hardware if you have it. Hi, I'm confused, in your first reply you recommend for "at least 20 iterations", now you recommend "about 15 iterations" while the latest draft for argon2id clearly recommends 1 iteration, if I understand this section correct?: https://tools.ietf.org/html/draft-irtf-cfrg-argon2-10#section-8.4 Can anyone clarify which setting for the iteration count t is recommended and why? I must admit that I would wish for clearer recommendations for end users. I'm currently having a hard time advising my dev team, regarding this. Currently for most parameters it says: test for yourself on your hardware. I appreciate all the hard work going into this and I know it's not easy to recommend sensible and sane defaults, but maybe someone can make this more clear for mere mortals like me? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#271 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA767MR455P3FEFUQRVOXD3RNAG7DANCNFSM4HQJYA3A .
-- Best regards, Dmitry Khovratovich

I don't want to hijack this thread, but I'm very sorry.
I find this statement very confusing in context to your recommendation?

8.4. Recommendations
The Argon2id variant with t=1 and maximum available memory is
RECOMMENDED as a default setting for all environments. This setting
is secure against side-channel attacks and maximizes adversarial
costs on dedicated bruteforce hardware.

Will this section be updated then?
https://tools.ietf.org/html/draft-irtf-cfrg-argon2-10#section-8.4

It clearly recommends t=1 and "maximum available memory"

I find this information very misleading and contradicting to what you said and what is noted here:
https://tools.ietf.org/html/draft-irtf-cfrg-argon2-10#section-4

  1. Figure out the maximum amount x of time (in seconds) that each call can afford.

Also this mixes up the variable names, across the document time is always displayed as "t", only here as "x"?

I'm a little worried about the current state of this.
Because I guess many developers will just go by the defaults implemented by whichever library
they use.
e.g. the nodejs argon2 lib has currently the default "t" at "3" and not higher.

Would it not be reasonable to suggest higher defaults for concrete hardware or cloud instances?
I know this is quite some additional work.

Thanks for your answers so far!

@ghost ghost mentioned this issue Apr 17, 2020
Closed
@khovratovich
Copy link
Member

khovratovich commented Apr 17, 2020 via email

@ranisalt
Copy link
Contributor

e.g. the nodejs argon2 lib has currently the default "t" at "3" and not higher.

And this happens because those are the defaults for the CLI tool. It is insecure as most machines could achieve >100 hashes/second and ideally it should take much longer than that.

@ranisalt
Copy link
Contributor

We will fix this ASAP

We are still waiting

@SparkDustJoe
Copy link

I see #243 is still open as well. I haven't combed through the literature, but was this issue mitigated in recent revisions? If so does that warrant closing that ticket?

@khovratovich
Copy link
Member

khovratovich commented Mar 11, 2021 via email

@mbroz
Copy link
Contributor Author

mbroz commented Sep 8, 2021

RFC is released (finally)
https://www.rfc-editor.org/rfc/rfc9106.txt

Thanks @khovratovich and everyone involved! :)

@ranisalt
Copy link
Contributor

ranisalt commented Sep 8, 2021

Great job! On to updating the libraries with the latest recommendations :)

@calestyo
Copy link

calestyo commented Jul 1, 2022

Shouldn't this issue be closed then?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@calestyo @mbroz @ranisalt @khovratovich @SparkDustJoe