The scrypt Password-Based Key Derivation Function
draft-josefsson-scrypt-kdf-05

[Ballot comment]
I think we are making progress, and I have released my Discuss. However, I do think the text is unnecessarily context dependent and hard to read. As a result, I have a couple of suggested edits below.

> > 1. In Section 6, scryptROMix is called with B[i] as the second parameter
> >
> >          B[i] = scryptROMix (r, B[i], N)
> >
> > Yet, per scryptROMix is supposed to take a 128*r sequence of octets as its second parameter.
> > What am I missing? Do I understand the notation correctly? I may be confused by the
> > same issue that Paul noted in his review, that same identifiers are used for different purposes.
>
> In the description of the scrypt algorithm, each of the p values B[i] is 128*r
> octets in length.  (Thus this matches the PBKDF2-HMAC-SHA256 call
> in step 1 of the algorithm, which produces p*128*r octets of output.)

Ok, but could Section 6 perhaps explain the type of the variable B that is used in the algorithm? And maybe similarly for the other variables that are used in the algorithms. The context dependency makes the algorithm hard to read. I might be dense, but I usually can read these things, but now I had trouble.

> > 2. In Section 4, the scryptBlockMix takes an input parameter which is defined as
> >
> >          B[0] || B[1] || ... || B[2 * r - 1]
> >                  Input octet string (of size 128 * r octets),
> >
> > Yet, B[0] ... B[2*r-1] would seem to be an octet string of size 2*r. What am I missing?
>
> As the line following that quote indicates
>                  "treated as 2 * r 64-octet blocks."
> B[0] .. B[2r-1] is 128*r octets, interpreted as a sequence of 64-octet blocks.

Ok, and maybe I’m being dense but this is difficult to understand :-)

Could you consider making this change to be very explicit about all this:

OLD:
                  treated as 2 * r 64-octet blocks.
NEW:
                  treated as 2 * r 64-octet blocks,
                  where each element in B is a 64-octet block.

> > The only issue I know of which is
> > outstanding is that the Integerify function is defined wrong in the
> > latest draft and needs to be reverted to its previous version.  (But I
> > don't know how to edit this.)
> >
> > What change is needed for that?
>
> Revert step 3 in the description of scryptROMix to what appeared in
> draft-josefsson-scrypt-kdf-03.

Ok for this.

[Ballot discuss]
Thank you for writing this important document.

I would like to recommend its approval, but before doing so I had some questions. These relate to issues that I had trouble understanding in the algorithm. And they have been inspired by Paul Kyzivat's Gen-ART review.

I'm probably missing something very obvious, but wanted to raise these questions just make sure there are no mistakes.

1. In Section 6, scryptROMix is called with B[i] as the second parameter

          B[i] = scryptROMix (r, B[i], N)

Yet, per scryptROMix is supposed to take a 128*r sequence of octets as its second parameter.
What am I missing? Do I understand the notation correctly? I may be confused by the
same issue that Paul noted in his review, that same identifiers are used for different purposes.

2. In Section 4, the scryptBlockMix takes an input parameter which is defined as

            B[0] || B[1] || ... || B[2 * r - 1]
                  Input octet string (of size 128 * r octets),

Yet, B[0] ... B[2*r-1] would seem to be an octet string of size 2*r. What am I missing?

[Ballot comment]
The first sentence in the abstract needs a comma before "scrypt". Or even better "... derivation function, known as scrypt".

(I spent some time working out that this was not a misspelling of "... derivation function script")

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-josefsson-scrypt-kdf-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The scrypt Password-Based Key Derivation Function) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'The scrypt Password-Based Key Derivation Function'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-09-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies the password-based key derivation function
  scrypt.  The function derives one or more secret keys from a secret
  string.  It is based on memory-hard functions which offer added
  protection against attacks using custom hardware.  The document also
  provides an ASN.1 schema.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-josefsson-scrypt-kdf/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-josefsson-scrypt-kdf/ballot/


No IPR declarations have been submitted directly on this I-D.

1. This is an informational RFC, as indicated in the page header. It is documenting an algorithm in common use; having it as an informational RFC removes a barrier to more widespread IETF adoption.

2a Technical Summary: This document specifies the password-based key derivation function scrypt.  The function derives one or more secret keys from a secret string.  It is based on memory-hard functions which offer added protection against attacks using custom hardware.
2B Working Group Summary: This was an individual effort to document an external algorithm. It was presented at the CFRG in IETF-92; there is no controversy.
2C Document Quality: It is a good, well-written document; it includes test vectors.  An interoperable implementation was written for OpenSSL based on this document.
2D Personal: Stephen Farrell is AD; Rich Salz is the shepherd

3. I did a careful reading of the document.  I examined an ran the OpenSSL code.  I did not very all the test vectors for all the crypto suites.

4. I strongly believe this document is ready to be published and doing so will be of benefit to the IETF community.

5. The algorithm is fairly well known, and no other review is needed. The primary concern is if the document is sufficient to write an implementation, and we have proof of that.

6. I am not aware of any concerns.

7. There are no outstanding IPR issues.

8. There are no IPR disclosures related to this document.

9. Those who have an opinion are in favor; no objections have been brought forth.

10. I am not aware of any discontent.

11.  idnits flagged the use of some RFC 2119 keywords, but that is mistaken
since they are part of the ASN.1  There are no other errors.

12.  There are no formal review criteria that need to be met.

13.  All references are properly identified as normative or informative.

14.  Of the normative references, two are RFC's, and two are PDF's of crypto papers, with links.  At some point, a diligent author may want to perform a similar activity to "RFC'ize the algorithm" of those papers, but this is not required.

15. There are no downward normative references.

16. No existing RFC is impacted by the publication of this document.

17. The "IANA Considerations" says "None"

18. There are no new registries.

19.  The only potential machine-readable part of the document is the ASN.1, which was carefully reviewed by hand.  I would object to the inconsistent placement of the curly braces, but that is all. :)