Select scrypt parameter based on computing power and memory

[scoddy]

Users with strong computing power will automatically get higher key derivation standards.

[fd0]

Maybe implement an aproach similar to the ruby scrypt gem https://github.com/pbhogan/scrypt or termchalk https://github.com/pquerna/termchalk

[fw42]

could use https://github.com/steakknife/scrypt

[fd0]

I'd like to not have any C components, if possible. Maybe we can have a look at how the calibration is done, and implement that part ourselves.

FYI: I've also implemented the chunking algorithm in C (see https://github.com/fd0/rabin-cdc), so if performance is limited by the chunker in the future, we'll be able to switch to this implementation.

[andrewchambers]

I think compression and encryption has more overhead than chunking. But little can be done without allocating all buffers with malloc.

[fd0]

Maybe we can collaborate with @elithrar, he also needs this function for the simple-scrypt library at https://github.com/elithrar/simple-scrypt.

[cfcs]

There's currently an ongoing standardization project with the intended goal of selecting the "next generation" scrypt replacement.

It should be finished soon (2015 Q2 is now, right?)

https://password-hashing.net/index.html

https://en.wikipedia.org/wiki/Password_Hashing_Competition

Might be worth looking into / waiting for - it seems that libsodium is waiting for the results, too:
http://doc.libsodium.org/password_hashing/index.html

A high-level crypto_pwhash_*() API is intentionally not defined until the Password Hashing Competition is over.

(see also dsheets/ocaml-sodium#16 )

[elithrar]

Keep in mind that you may not want to jump on the latest algorithm
immediately. Even with people like Colin Percival & Matthew Green on the
project, allowing some time for the algo and its implementations to be
battle tested.

Anyway, as for scrypt auto-tuning: doing it cross-platform is tricky. The
Ruby stuff does a bogoMIPS based estimation. I haven't invested much of my
free time into it as it's very much a "nice to have".
On Fri, 3 Jul 2015 at 7:13 pm cfcs notifications@github.com wrote:

There's currently an ongoing standardization project with the intended
goal of selecting the "next generation" scrypt replacement.

It should be finished soon (2015 Q2 is now, right?)
https://password-hashing.net/index.html

Might be worth looking into / waiting for.

—
Reply to this email directly or view it on GitHub
#17 (comment).

[fd0]

We'll stick with scrypt() for now, but it'd be nice to do some auto-tuning. It may also be non cross-platform, as we could easily have one implementation per platform. And that could also be used in the simple-scrypt library.

[tgulacsi]

I have time-limited scrypt hardness autotuner: https://github.com/tgulacsi/go/blob/master/crypthlp/scrypthlp.go

It starts with 14, and increments till the twice of the current run won't finish in the time limit.

Not perfect (first I calculated the optimum based on the time of 14 and that each increment doubles the time, but swapping strikes earlier...), but better than a hard-coded parameter.

[fd0]

Oh, thanks for the hint! You've licensed the code as Apache 2.0, do you know whether that's compatible with the BSD license from restic?

[fd0]

Ah, wrong button. :/

[tgulacsi]

As I'm the author, I can (and will) relicense that part with the same license as restic is under, for restic.

That's not too much code, just copy the relevant parts and mention the source and me.

[fd0]

Great, I'll have a look!