Hi,

I found many times that people use unpredictableSeed in combination with normal PRNG for cryptographic purpose. Some even go as far as reseeding at each call to try making it more secure.

It is a dangerous practice, most PRNG are not designed with security (and unpredictability) in mind, and unpredictableSeed was definitely not designed with security in mind (or it failed heavily at it). It's a good tool when one needs randomness, not security.

I wrote a blog post to present exactly why this is a bad idea and how it could be exploited [1].

The best would be to add a standard CSPRNG interface to Phobos but we aren't there yet.

[1]: https://cym13.github.io/article/unpredictableSeed.html

cym13 wrote:

> Hi,
>
> I found many times that people use unpredictableSeed in combination with normal PRNG for cryptographic purpose. Some even go as far as reseeding at each call to try making it more secure.
>
> It is a dangerous practice, most PRNG are not designed with security (and unpredictability) in mind, and unpredictableSeed was definitely not designed with security in mind (or it failed heavily at it). It's a good tool when one needs randomness, not security.
>
> I wrote a blog post to present exactly why this is a bad idea and how it could be exploited [1].
>
> The best would be to add a standard CSPRNG interface to Phobos but we aren't there yet.
>
> [1]: https://cym13.github.io/article/unpredictableSeed.html

"like /dev/random on Linux"
(sighs) it was so good until this...

On Sunday, 26 February 2017 at 18:33:08 UTC, ketmar wrote:
> cym13 wrote:
>
>> Hi,
>>
>> I found many times that people use unpredictableSeed in combination with normal PRNG for cryptographic purpose. Some even go as far as reseeding at each call to try making it more secure.
>>
>> It is a dangerous practice, most PRNG are not designed with security (and unpredictability) in mind, and unpredictableSeed was definitely not designed with security in mind (or it failed heavily at it). It's a good tool when one needs randomness, not security.
>>
>> I wrote a blog post to present exactly why this is a bad idea and how it could be exploited [1].
>>
>> The best would be to add a standard CSPRNG interface to Phobos but we aren't there yet.
>>
>> [1]: https://cym13.github.io/article/unpredictableSeed.html
>
> "like /dev/random on Linux"
> (sighs) it was so good until this...

That's a typo actually, I meant urandom, I'll correct it.
Actually it would be better not to use urandom directly but use it as source to regularly reseed another PRNG in order to avoid some warts but meh. As a first step it's good enough as it is.

cym13 wrote:

>> "like /dev/random on Linux"
>> (sighs) it was so good until this...
> That's a typo actually, I meant urandom, I'll correct it.

thank you. sorry for me being rough: i was trying to make a joke, and i was pretty sure that it was a typo. but now i reread my post and found that the joke mysteriously turned into something i didn't meant to say.


> Actually it would be better not to use urandom directly but use it as source to regularly reseed another PRNG in order to avoid some warts but meh. As a first step it's good enough as it is.

yeah. yet, urandom is using cryptoprng (salsa now, afair), so it may be used as-is too. ah, even good old arc4 is not that bad -- as urandom is almost never have a "scratch start" case. and one can throw away 2k-3k of values just to be sure anyway. ;-)


ah, i *meant* to say: "good article". so: good article! ;-)

On 02/26/2017 01:23 PM, cym13 wrote:
> Hi,
>
> I found many times that people use unpredictableSeed in combination with
> normal PRNG for cryptographic purpose. Some even go as far as reseeding
> at each call to try making it more secure.
>
> It is a dangerous practice, most PRNG are not designed with security
> (and unpredictability) in mind, and unpredictableSeed was definitely not
> designed with security in mind (or it failed heavily at it). It's a good
> tool when one needs randomness, not security.
>
> I wrote a blog post to present exactly why this is a bad idea and how it
> could be exploited [1].
>
> The best would be to add a standard CSPRNG interface to Phobos but we
> aren't there yet.
>
> [1]: https://cym13.github.io/article/unpredictableSeed.html

FWIW, DAuth[1] uses, and offers, an implementation of Hash_DRBG, a well-known and established CSPRNG algorithm. It's entropy source (not exactly the same as a seed, but basically the CSPRNG equivalent) is customizable, but by default, it uses _RtlGenRandom on Windows (the same source used by the CryptGenRandom algorithms) and '/dev/urandom' on Posix:

https://github.com/Abscissa/DAuth/blob/master/src/dauth/hashdrbg.d

[1] Ugh, still haven't gotten around to finishing DAuth's new version, renamed "InstaUser".

Speaking of, another good source of more "how to not mess up security" info is here:

https://crackstation.net/hashing-security.htm

DAuth/InstaUser is based on the points in there.

On Sunday, 26 February 2017 at 22:56:14 UTC, Nick Sabalausky (Abscissa) wrote:
> On 02/26/2017 01:23 PM, cym13 wrote:
>> Hi,
>>
>> I found many times that people use unpredictableSeed in combination with
>> normal PRNG for cryptographic purpose. Some even go as far as reseeding
>> at each call to try making it more secure.
>>
>> It is a dangerous practice, most PRNG are not designed with security
>> (and unpredictability) in mind, and unpredictableSeed was definitely not
>> designed with security in mind (or it failed heavily at it). It's a good
>> tool when one needs randomness, not security.
>>
>> I wrote a blog post to present exactly why this is a bad idea and how it
>> could be exploited [1].
>>
>> The best would be to add a standard CSPRNG interface to Phobos but we
>> aren't there yet.
>>
>> [1]: https://cym13.github.io/article/unpredictableSeed.html
>
> FWIW, DAuth[1] uses, and offers, an implementation of Hash_DRBG, a well-known and established CSPRNG algorithm. It's entropy source (not exactly the same as a seed, but basically the CSPRNG equivalent) is customizable, but by default, it uses _RtlGenRandom on Windows (the same source used by the CryptGenRandom algorithms) and '/dev/urandom' on Posix:
>
> https://github.com/Abscissa/DAuth/blob/master/src/dauth/hashdrbg.d
>
> [1] Ugh, still haven't gotten around to finishing DAuth's new version, renamed "InstaUser".

And it is very interesting to note that you fall into the very exact problem I am describing in my post if it weren't that your default PRNG isn't seedable. Use any other PRNG and you are vulnerable (if I read it correctly, I haven't spent much time on that).

From random.d, the function randomToken calls randomBytes which inits a new PRNG which is seeded with unpredictableSeed which becomes the actual PRNG used:

string randomToken(Rand = DefaultCryptoRand)(size_t strength = defaultTokenStrength)
	if(isDAuthRandom!Rand)
{
	return TokenBase64.encode( randomBytes!Rand(strength) );
}

ubyte[] randomBytes(Rand = DefaultCryptoRand)(size_t numBytes)
	if(isDAuthRandom!Rand)
{
	Rand rand;
	rand.initRand();
	return randomBytes(numBytes, rand);
}

private void initRand(Rand)(ref Rand rand)
	if(isDAuthRandom!Rand)
{
	static if(isSeedable!Rand)
		rand.seed(unpredictableSeed);
}

The only thing that saves you here is that your DefaultCryptoRand isn't seedable. Note that I'm not saying that to bash you or anything, it just happens to show well why I think my article was necessary.

On Monday, 27 February 2017 at 00:10:31 UTC, cym13 wrote:
>
> The only thing that saves you here is that your DefaultCryptoRand isn't seedable. Note that I'm not saying that to bash you or anything, it just happens to show well why I think my article was necessary.

Oh, don't get me wrong, I'm very much in favor of your article, ESPECIALLY if people are using the phobos rng in security contexts.

Keep in mind though, if my Hash_DRBG implementation were seedable, it wouldn't be a valid implementation of Hash_DRBG anyway. (A good example, I think, of why we coders shouldn't be inventing crypto algorithms, only implementing establised ones created and well-studied by the math/crypto experts.)

On 02/26/2017 01:23 PM, cym13 wrote:
>
> [1]: https://cym13.github.io/article/unpredictableSeed.html

Good enlightening article. And Veles looks cool, never heard of it before.

One detail:

auto copyState(uint origin) {
    for (uint i=1; i>0; i++) {
        if (origin == Random(i).front)
            return origin;
    }
    return 0;
}

Shouldn't "return origin;" be "return i;"?

On Monday, 27 February 2017 at 04:51:37 UTC, Nick Sabalausky (Abscissa) wrote:
> On 02/26/2017 01:23 PM, cym13 wrote:
>>
>> [1]: https://cym13.github.io/article/unpredictableSeed.html
>
> Good enlightening article. And Veles looks cool, never heard of it before.
>
> One detail:
>
> auto copyState(uint origin) {
>     for (uint i=1; i>0; i++) {
>         if (origin == Random(i).front)
>             return origin;
>     }
>     return 0;
> }
>
> Shouldn't "return origin;" be "return i;"?

Yes, it should completely be "return i;", thanks for noticing I'll correct it.