Re: [cryptography] Designing a key stretching crypto that maximize use of WebCrypto?
I'm curious how PBKDF2 compares. On Sun, May 3, 2015 at 11:10 PM Fabio Pietrosanti (naif) - lists < li...@infosecurity.ch> wrote: > Hi all, > > testing the lovely slowness of a pure scrypt implementation in > javascript running into the browser, i was wondering anyone ever tried > to think/design an cryptosystem for key stretching purposes that > leverage only existing webcrypto API > (https://www.chromium.org/blink/webcrypto) with the goal to use let's > say 80% of cpu time on native-crypto-code rather than JS code? > > In the browser native crypto code trough WebCrypto API works obviously > much faster than JS crypto code (how much?)! > > Fabio > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
There's an implementation of Fortuna, which is a computationally secure PRNG, in PyCrypto: https://github.com/dlitz/pycrypto/tree/master/lib/Crypto/Random/Fortuna Unfortunately, gathering entropy is rather non-generic; otherwise decentish operating systems get this wrong. The various BSDs' source is probably the best place to start poking around, if you really want. -dlg On Wed, Nov 19, 2014 at 3:59 AM Givon Zirkind wrote: > Plz excuse if inappropriate. Does anyone know of a decent (as in really > random) open source random generator? Preferably in PHP or C/C++? > > Thanks. > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] caring harder requires solving once for the most demanding threat model, to the benefit of all lesser models
On Wed, Oct 15, 2014 at 7:13 AM, ianG wrote: > :) em, close, I advocate direct and sole use of your platform's RNG. > Rule #1: > > http://iang.org/ssl/hard_truths_hard_random_numbers.html > > 1. Use what your platform provides. Random numbers are hard, which is > the first thing you have to remember, and always come back to. Random > numbers are so hard, that you have to care a lot before you get > involved. A hell of a lot. Which leads us to the following rules of > thumb for RNG production. Don't just use your platform RNG. There is a simple method which works well, even if your platform RNG is backdoored. Generate, independently of your platform's RNG, a secret "personalization string" containing (say) 32 bytes of entropy. Then, when you need a random number, do: personalization_secret = [roll dice or something] def randomkey(): seed = urandom(32) return kdf(personalization_string, seed) Even if your platform uses Dual-EC DRBG, an adversary still needs to get the secret (and invert the kdf), to get any useful information. This is better than broadcasting your platform RNG state out to the internet. (Of course, this does absolutely nothing to help you if your platform random always outputs 0 -- or very low-entropy randomness -- but nothing does.) Reasonable choices for "kdf" here: kdf(k, s) = SHAKE256(k || s, 32) kdf(k, s) = Blake2b(mackey=k, s)[0:32] An okay choice: kdf(k, s) = HMAC-SHA512(k=k, m=s)[0:32] (The KDF should be indifferentiable from a random oracle; SHAKE256 and Blake2b were designed to be.) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
