8

The scenario is single-use passphrase-based non-interactive message authentication.

The obvious try to do this is to chose a random salt of the appropriate length and send:

concat(workfactor, salt, message,
       mac(scrypt(workfactor, salt, passphrase), message)).

That protocol is as secure as scrypt is a non-malleable key derivation function (with regards of changing of workfactor and salt).

  1. Is there any publicly known malleability of scrypt?
  2. Are there any better protocols for this scenario?
Paŭlo Ebermann
  • 22,946
  • 7
  • 82
  • 119

1 Answers1

3

Non-malleability of Scrypt w.r.t. to salt (as well as passphrase) follows from the definition of Scrypt (which simply pass that salt to that input of PBKDF2); the definition of PBKDF2 (which uses the salt followed by a non-malleable encoding of an integer as a massage passed to HMAC_SHA256); the non-malleability of HMAC_SHA256 w.r.t. the message; and perhaps some reasonable assumptions also critical to Scrypt's soundness. Non-malleability w.r.t. to salt and passphrase should be a design goal of any good PBKDF.

Non-malleability of Scrypt w.r.t. workfactor is more difficult to argument, and hard (if possible) to prove, depending on how rigorous the argument needs to be, and how one maps the term workfactor to the three security parameters of Scrypt (number of iterations, amount of RAM used, and allowance for parallelization). In my opinion, no attack better than brute force is feasible: this is an issue of provable security only, and entering the workfactor(s) in the salt would restore that.

Beware that in some protocols, independently of any weakness in Scrypt (or whatever PBKDF is used), it could be necessary that a legitimate party holding the passphrase enforce a minimum workfactor, for fear of being abused into a fast passphrase-checking oracle.

I do not know any established PBKDF improving on Scrypt.

Community
  • 1
fgrieu
  • 149,326
  • 13
  • 324
  • 622