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
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.