Skip to main content

The scrypt Password-Based Key Derivation Function
RFC 7914

Yes

(Kathleen Moriarty)
(Stephen Farrell)

No Objection

Alvaro Retana
(Alissa Cooper)
(Barry Leiba)
(Benoît Claise)
(Deborah Brungard)
(Joel Jaeggli)
(Martin Stiemerling)

Note: This ballot was opened for revision 04 and is now closed.

Alvaro Retana
No Objection
Kathleen Moriarty Former IESG member
Yes
Yes (for -04)

                            
Stephen Farrell Former IESG member
Yes
Yes (for -04)

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -04)

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -04)

                            
Ben Campbell Former IESG member
No Objection
No Objection (2016-01-06 for -04)
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")
Benoît Claise Former IESG member
No Objection
No Objection (for -04)

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -04)

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (2016-04-14 for -04)
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.
Joel Jaeggli Former IESG member
No Objection
No Objection (for -04)

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -04)