The scrypt Password-Based Key Derivation Function
draft-josefsson-scrypt-kdf-05
Yes
(Kathleen Moriarty)
(Stephen Farrell)
No Objection
(Alissa Cooper)
(Alvaro Retana)
(Barry Leiba)
(Benoît Claise)
(Deborah Brungard)
(Joel Jaeggli)
(Martin Stiemerling)
Note: This ballot was opened for revision 04 and is now closed.
Kathleen Moriarty Former IESG member
Yes
Yes
(for -04)
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(for -04)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -04)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -04)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2016-01-06 for -04)
Unknown
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)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2016-04-14 for -04)
Unknown
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)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -04)
Unknown