Bouncy Castle scrypt implementation
Asked Answered
T

3

12

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

Terrance answered 6/3, 2014 at 14:6 Comment(0)
T
0

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.

Terrance answered 17/6, 2020 at 8:28 Comment(0)
M
5

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);
    
Millrace answered 2/2, 2017 at 0:56 Comment(1)
generate method is static, you can't use it by instantiating a Scrypt object,Unrealizable
V
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

Vanillic answered 16/7, 2017 at 14:54 Comment(2)
There are some good information at #11126815 , not sure how it would suit current hardware as the answers are bit old.Unrealizable
Since the BC implementation uses Java, how does it compare to the native code (C++) implementations (see github.com/wg/scrypt and its forks)? Note that for Scrypt (or any key stretching) to be effective against attackers, it needs to run as fast as possible.Supplejack
T
0

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.

Terrance answered 17/6, 2020 at 8:28 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.