>> We're gather samples from the audio device (I don't know about the
>> merits of that entropy source) at the start of the application in
>> order to seed a random generator used by ZRTP and SDES. We're not
>> using that for DTLS-SRTP. Now you're talking about OTR. I guess
>> we'd better introduce an OSGi service in libjitsi and use that
Instead of an OSGi service we could implement SecureRandomSpi - and we
wouldn't need to care about libraries using SecureRandom anymore.
> I assume you mean samples from the microphone?
> I'm far from an expert, but one possible problem is obvious: What if
> the microphone is disabled when jitsi is started? Nothing but Zeros.
> Chances are that I use this zero-seed, so I have to throw away my
> jitsi config again.
Hmm. Good point.
> I'm not sure how random the result is in the case of the enabled
> microphone, but my guess is that it could be better.
It gets worse: in my dev-env it's zero, even with the microphone
enabled! We definitely need to fix this. And if reading from the
sound device fails, it is just silently ignored...
Now not all is lost for previous ZRTP/SDES calls because Fortuna is
still seeded with the defaults of java.util.Random(), but this is
even worse than /dev/urandom.
I did not look at the code at all, but can it be that some
processing like noise cancellation causes this?
But it's better to just fix it properly than to figure out what is
> At least in Linux a whole bunch of entropy sources get mixed
> into the pool that can be accessed through /dev/random
> and /dev/urandom. The only difference between those two devices is
> to my knowledge that /dev/random has an entropy estimator which
> blocks access until it thinks that sufficient entropy has been
> gathered. That's the thing that should be used to have some
> confidence in the randomness
The problem is that /dev/random is just too slow to be usable. It
might be feasible for an OTR key generation to wait a minute, but not
for seeding the crypto engines to start a call. And we're not talking
about a lot of data here - more like 44 bytes for SDES.
I think tests are in order here, for 44 bytes it might even be fast
> I have no idea what the equivalents on other platforms are or what
> convenient way there is to get good random numbers across the
SecureRandom on Windows uses the CryptoAPI which should be reasonably
secure (and please no politics about closed source now).
I only wonder whether CryptoAPI and its Apple-equivalent use RDRAND
exclusively. There has been some discussion about this in Linux-land.
It comes down to people not trusting a hardware PRNG. For this
reason /dev/random uses the hardware PRNG but uses other entropy
sources as well.
Apparently CryptoAPI does support the infamous Dual_EC_DRBG, I
wonder whether there's some good crypto library that avoids such
On Wed, 20 Nov 2013 23:19:30 +0100 "Ingo Bauersachs" <email@example.com> wrote: