Improved description of Memorized Secret Verifiers

[sebastien-rosset]

In 800-63b section "5.1.1.2 Memorized Secret Verifiers", BALLOON and PBKDF2 are provided as "examples" of suitable key derivation functions, without mentioning whether they are memory-hard functions or not. The use of the word "example" in this context means one can expect there would be other suitable functions.

The next sentence states that a "memory-hard function SHOULD be used", without providing a list of suitable key derivation functions that are memory-hard. Isn’t it a contradiction to state that 1) PBKDF2 is suitable and 2) a “memory-hard function SHOULD be used”? Sure, the spec does not state "memory-hard function SHALL be used", so technically one can argue this is not a contradiction, but still, it is perplexing.

The next sentence ("The key derivation function SHALL use an approved one-way function...") gives an explicit list of approved hash algorithms. Was it intentional to provide an explicit list of approved hash algorithms, and an open-ended recommendation for the key derivation function? This leaves the spec open to interpretation.

[jimfenton]

Hello Sebastien, Thank you for your inquiry regarding NIST SP 800-63B section 5.1.1.2 Memorized Secret Verifiers. As noted in your inquiry, the use of PBKDF2 as a suitable key derivation function is not contradictory to the recommendation that "a memory-hard function SHOULD be used" . This text recommends, but does not require, the use of a memory-hard function. NIST considers the security of the hash (one-way) function used in key derivation to be of primary importance, and therefore requires the use of an approved (thoroughly vetted) one-way function in key derivation. BALLOON is a memory-hard and time-hard algorithm that allows the use of an approved underlying one-way function, but unfortunately it has not been widely deployed. Other algorithms such as ARGON2 are memory- and time-hard, but do not use an underlying one-way function that has been thoroughly analyzed. While PBKDF2 is time-hard but not memory-hard, it is so widely deployed that it is not practical (at this time, anyway) to introduce a requirement for a memory-hard key derivation function, so we have presented this as a recommendation (i.e. "SHOULD"). The key derivation function is considered less critical than the one-way function that underlies it, so the specification is less prescriptive in this area and does not specify particular algorithms for key derivation. Please feel free to contact me if you have further questions or would like additional information. David Temoshok Senior Policy Advisor Applied Cybersecurity NIST IT Laboratory 202-482-5475 202-494-3758 (m)

…

-------- Forwarded Message -------- Subject: [usnistgov/800-63-3] Improved description of Memorized Secret Verifiers (#1954) Date: Wed, 20 Nov 2019 10:27:44 -0800 From: Sebastien Rosset <notifications@github.com><mailto:notifications@github.com> Reply-To: usnistgov/800-63-3 <reply@reply.github.com><mailto:reply@reply.github.com> To: usnistgov/800-63-3 <800-63-3@noreply.github.com><mailto:800-63-3@noreply.github.com> CC: Subscribed <subscribed@noreply.github.com><mailto:subscribed@noreply.github.com> In 800-63b section "5.1.1.2 Memorized Secret Verifiers", BALLOON and PBKDF2 are provided as "examples" of suitable key derivation functions, without mentioning whether they are memory-hard functions or not. The use of the word "example" in this context means one can expect there would be other suitable functions. The next sentence states that a "memory-hard function SHOULD be used", without providing a list of suitable key derivation functions that are memory-hard. Isn't it a contradiction to state that 1) PBKDF2 is suitable and 2) a "memory-hard function SHOULD be used"? Sure, the spec does not state "memory-hard function SHALL be used", so technically one can argue this is not a contradiction, but still, it is perplexing. The next sentence ("The key derivation function SHALL use an approved one-way function...") gives an explicit list of approved hash algorithms. Was it intentional to provide an explicit list of approved hash algorithms, and an open-ended recommendation for the key derivation function? This leaves the spec open to interpretation. - You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#1954?email_source=notifications&email_token=AAHZCNBIWWASRMPWDD2RLNLQUV6SBA5CNFSM4JPXPXBKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H22AHJA>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHZCNERK2LK6EW7BHNQHTLQUV6SBANCNFSM4JPXPXBA>.