Bouncy Castle scrypt implementation

Question

I'm currently implementing password hashing using scrypt. I have already found a nice scrypt implementation on GitHub. To my surprise I have also discovered a scrypt implementation in the Bouncy Castle library. The class is not documented, Wikipedia didn't mention Bouncy Castle as scrypt implementation provider and I had real trouble finding any code examples of someone using Bouncy Castles scrypt, so this looks somehow suspicious to me.

On the other hand if I had to choose between a GitHubs crypto implementation and Bouncy Castle, I would prefer Bouncy Castle.

So is the Bouncy Castles scrypt the 'real thing'? And can I use Bouncy Castles scrypt over the JCA provider API (or do I need to call it directly like here: AES-256 encryption workflow in scala with bouncy castle: salt and IV usage and transfer/storage)?

---

EDIT: Best answer I could get by now: https://www.bouncycastle.org/devmailarchive/msg13653.html

Answer 1

So that people don't have to go to an external site for an answer:

1. Make sure bouncy castle jars are on your build path

2. Import SCrypt like so:

   import org.bouncycastle.crypto.generators.SCrypt;
   

3. Use SCrypt like so:

   byte[] sCryptHash = SCrypt.generate(plaintext.getBytes(), salt.getBytes(), cpuDifficultyFactor, memoryDifficultyFactor, parallelismDifficultyFactor, outputLength);
   

Answer 2

You can use the SCrypt class with its static method generate like this:

SCrypt.generate(passwordBytes, salt, costParam, blockSize, parallelization, passwordLength);

I can't really say what values you should use for costParam, blockSize or parallelization, the documentation doesn't say much to it. In our studies we used 8 for every of those.

Link to their docus: BCrypt - https://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/generators/BCrypt.html SCrypt - https://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/generators/SCrypt.html

Answer 3

Best answer I could get from the bouncycastle.org mailbox:

Yes the scrypt implementation is a real thing - that is to say the code is there, and it passes the official test vectors.

A couple of caveats: the implementation doesn’t exploit all parallelism/optimisations that password crackers will, so there’s a bit of defender/attacker asymmetry. Scrypt is also based on the Salsa20 code function, and Salsa20 performs relatively poorly in Java (on par with AES) while performing awesomely (maybe 4-5x quicker) on platforms with SIMD capabilities.

Scrypt isn’t exposed by the BC JCE provider - perhaps I’d say because the JCE only has very primitive expressions of a cost function for PBE (in the form of an interation count). Scrypt has two cost parameters, so it can’t be trivially forced into that API.

If there’s enough demand I guess it could be exposed through JCE with a hard-coded parallelisation parameter or a BC specific parameter spec.