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

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

Alvaro Retana No Objection

(Kathleen Moriarty; former steering group member) Yes

Yes ( for -04)
No email
send info

(Stephen Farrell; former steering group member) Yes

Yes ( for -04)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Ben Campbell; former steering group member) No Objection

No Objection (2016-01-06 for -04)
No email
send info
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 steering group member) No Objection

No Objection ( for -04)
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection (2016-04-14 for -04)
No email
send info
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 steering group member) No Objection

No Objection ( for -04)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -04)
No email
send info