[erlang-questions] Password generator in Erlang
Fri Aug 17 21:33:08 CEST 2012
One thing to keep in mind with crypto is that it depends on OpenSSL
which means that if you want to create a binary version of your
application you need to make sure that the execution platform has OpenSSL.
If you are developing a server for your own use - no problem.
If you want to break the dependency you can - on Un*x-like platforms -
resort to getting a seed from /dev/urandom - there is an example of this
in https://github.com/lehoff/cryptographic, it is ages since I worked on
that and I cannot remember the state of that, but the general principle
should be sound.
There is a way to do this in Windows too, but we never got around to
implementing that back then.
On 2012-08-17 17:04, Zabrane Mickael wrote:
> Thanks guys. I'll give "crypto:strong_rand_bytes" a try ;-)
> On Aug 17, 2012, at 5:00 PM, Jeremey Barrett wrote:
>> Hi all... if you want pseudo-random bytes, use crypto:rand_bytes() or crypto:strong_rand_bytes(), depending on your security requirements. rand_bytes() calls OpenSSL's RAND_pseudo_bytes(), and strong_rand_bytes() calls OpenSSL's RAND_bytes(). Read up on them for more info.
>> strong_rand_bytes() will return an error if insufficient entropy is present. rand_bytes() will "just do it", which may not be what you want.
>> OpenSSL is widely deployed, trusted, etc. The built-in wrappers in Erlang are very convenient, just use them. The crypto community has been over and over this for two decades. I cannot stress enough the value of just using a trusted, open implementation vs. fretting over details that may or may not be relevant. There are so many factors you cannot account for otherwise.
>> On Aug 17, 2012, at 5:53 AM, Samuel <> wrote:
>>>> The second implementation is more secure in that sense, but still the
>>>> original seed is guessable. An attacker can generate possible password
>>>> sequences by bruteforce just tying possible now tuples around the time
>>>> he thinks the real seed was created.
>>>> So, how one can generate a secure un-predicatable seeds?
>>> That's the tricky part :) At least you have to avoid generating
>>> clearly predictable seeds as the seed is your private key in this
>>> case. With the seed anyone can reproduce the sequence.
>>> crypto:strong_rand_bytes strives for better security properties, and I
>>> understand it abstracts how to generate a good key for you, trying to
>>> suck entropy from your system (so you may need to sit there banging
>>> the keys and moving the mouse around for that ;) )
>>> I am not a security expert by far, I just know some things that do not
>>> work :). For things that work, the common approach is relying in
>>> popular libraries not known to be broken. and trying not to use them
>>> in a fancy way as the history is full of famous broken cryptographic
>>> uses (you can read about flaws CSS, WEP, etc).
>>> Of course, whether that approach is advisable or not is more a
>>> philosophical question, not knowing they are not broken doesn't mean
>>> that no one knows how to break them and has the key access information
>>> is thought to be safely encrypted :)
>>>> We also moved to "Tiny Mersenne Twister"
>>>> (https://github.com/jj1bdx/tinymt-erlang) instead of using
>>>> the standard random:uniform since the last Yaws security alert
>>>> Is this sufficient or should we also find a way to generate a unpredicatble
>>>> seed for it?
>>> As said, I am not a security expert, but as far as I can read, the
>>> goals of that algorithm are to keep a small state with good
>>> statistical properties, it says nothing about security (which doesn't
>>> necessarily mean it is insecure, of course). A PRG can have good
>>> statistical properties and still be insecure, being a secure PRG is a
>>> stronger assumption. That is why erlang:random is fine for non
>>> cryptographic uses, but for security you need something more complex.
>>> Anyway, you always need a seed no one can guess. Same seed, same
>>> sequence, so if someone guesses your seed it basically gets all your
>>> passwords in return.
>>> erlang-questions mailing list
> erlang-questions mailing list
More information about the erlang-questions