Closed ircmaxell closed 10 years ago
So, you're basically suggesting to add a key store? :)
See #8
And yes :-)
Taylor: what about the point of discouraging online keygeneration in most cases...?
There are lots of applications where you need to generate temporary keys online such as storing encrypted things in cookies (or forms, to make them "stateless"), or generating a new master key for a user, etc. Saying something like "don't ever generate keys online" is not something a encryption library should do, since there are valid applications. (Crypto in web apps is more useful for enforcing appsec than anything else, e.g. password reset tokens, things that assume the server is secure (as you always must)).
If you do want to discourage online key generation, using /dev/random
is not the way to do it. It will just make requests take a lot longer, and the administrator will install a hardware random number generator (if they're smart), or install a daemon that just increases the /dev/random
entropy count without actually adding entropy (if they're not so smart). Or, they'll just change the source code to use /dev/urandom
. In other words, nothing about "This page is taking a long time to load" screams "You're not using the cryptography library right", so it's not an effective way to get the message across.
Fair enough, closing.
Just a note: I will consider this if I do add a key store to the library, since that would allow pre-generation of keys and therefore, taking away performance considerations out of the online process. Would be really hard to make that user-friendly though.
The current implementation of
getKey()
proxies to/dev/urandom
without any derivation. Consider improving this to generate keys from/dev/random
offline (and discourage online generation of keys if possible).