use crypto.getRandomValues when available
fbender opened this issue · comments
Some browsers implement a cryptographic random number generator you can use, see: https://developer.mozilla.org/en-US/docs/Web/API/window.crypto.getRandomValues
Thanks, Florian. Is this seedable? Right now I seed the RNG with the password in order to reproducibly generate the key pair. Also, we'd want to be sure that if it is seedable, that different browsers (and same browsers on different machines?) produce the same key pair.
I'm a bit confused now – a RNG is supposed to generate random numbers, not something with a result you can predict, isn't it? I'm in no way a cryptography expert, but either you want something random (where you use the above mentioned cryptographically secure RNG, which you don't need to and cannot seed, like /dev/urandom) or a password derived key algorithm (like PBKDF2).
I assumed by the naming (and loading of PRNGs) that you indeed want to produce something random (which makes sense in the case you want to generate the key). If you want to be able to encrypt your message with the same key from different devices, you need to synchronize the key between these devices. This is of course not the case if you want to use a password derived key algorithm, however then you don't need any RNG.
Your intuition here is correct! Nevertheless, I built Cryptico by cobbling together the work of experts, and using a seedable RNG was more straightforward for me than other options. If you find a straightforward way to use something like PBKDF2 with Cryptico, I'd be very interested.
May I suggest then (as initially intended) to use crypto.getRandomValues and forget about seeding when the former is available (fallback is current implementation with seed)? This will increase the cryptographic strength of Cryptico, however not maintaining platform parity (which, in this particular case, is a good thing, because on supporting platforms, Cryptico is more secure). If you want something random, let it be random, if you want something predictable, make it fully predictable :) (currently, the code may not produce the same results in different browsers / on different platforms, too).
I would argue for your position in most cases, but one of the design goals of Cryptico was to provide password-generated keys, not random ones. If someone were to submit a pull request that gracefully allowed for both options without sacrificing the ease-of-use as it stands now, I would accept it and make them a contributor. cough cough wink wink
I'll put onto my never ending TODO list ;-)
Though I'm not very thrilled to write some cryptography code because I definitley don't have the necessary knowledge to foresee technological and mathematical loopholes. I'd rather see someone with the necessary knowledge do that. However, I'll look at it and see what I can do, but it will be some months before I can get to it.
getRandomValues() is definitely not reproducible. It's not seedable and the algorithm depends on browser.
You could use getRandomValues() only as source of entropy, to seed your own reproducible RNG.
So, using getRandomValues() to generate a random password and use it as Cryptico password is not a good idea? :-(
I don't see anything wrong with this. It would, in theory, provide a good password. You'd want to store it somehow, as it's not going to be memorable.
Yeah, my intention was to store it on localStorage and not make it publicly visible to the user. Storing and using this password will generate always the same public/private keys, or it's added some ramdom salt to their generation so each time they would be different? There's anyway to store permanently the generated public/private keys or this use case is not intended and instead I should re-generate them each time using the stored password? (Just to know how to use the library, this point is not specified on the documentation...)
The key generation from the password is deterministic, yes. There's not currently a way to store the keys provided by the library.
Cool then :-)