/dev/urandom is suitable and strong enough for DH keys (and long term DH
Disagree. LibOTR uses explicitely GCRY_STRONG_RANDOM that feeds on
/dev/random. Libgcrypt also explicitely mention that for long term keys
you need strong crypo. values that are not guaranteed by urandom.
ps that's also what openssl uses by default and that's what most of the
internet runs on (with DH keys generated from /dev/urandom...)...
Openssl does that indeed from their command line tool but the API can
let you seed back the pool with /dev/random. I wouldn't cite the
Internet security state as a good example to be honest, it's quite
horrible all around the place.
I can't find any details on why they switched to urandom other then this
commit message back in 2001 (and to be honest this leaves me a bit in a
My guess is that speed is more important for them considering that the
"usual workload" is session key. Probably don't want to block https
request for 2 minutes while gathering entropy :).
The kernel documentation states clearly that long term keys should use
true randomness (guaranteed with /dev/random), libgcrypt also mention
that, and every other documentation. I can't think of a cryptographer
that will compromise for "not really sure strong values" ...
I feel like we are going to disagree for a while here so I guess the
Jitsi/otr4j folks can decide here what to do considering the amount of
information they have on the subject.
On 21 Nov (18:10:45), Ralf Skyper Kaiser wrote:
On Thu, Nov 21, 2013 at 4:13 PM, David Goulet <email@example.com> wrote:
> On 21 Nov (15:53:38), Ralf Skyper Kaiser wrote:
> > On Thu, Nov 21, 2013 at 3:41 PM, David Goulet <firstname.lastname@example.org> wrote:
> > > Sorry, I wasn't on the list but saw this message and had to reply so
> > > here it is inline and my response just after.
> > >
> > > [...]
> > > The /dev/urandom device does not have this limit, and will return as
> > > many bytes as are requested. As more and more random bytes are
> > > requested without giving time for the entropy pool to recharge, this
> > > will result in random numbers that are merely cryptographically strong.
> > > For many applications, however, this is acceptable.
> > > --
> > >
> > > Now, we can argue that it is very difficult for an attacker to know the
> > > state of the entropy pool at the exact time you generate your key and
> > > use that as some pratical attack. It is very unlikely but still that
> > > does not mean you shouldn't use the best strongest random values
> > > available for long term keys especially when it generated once.
> > >
> > yes, that's exactly what it means ("for many [crypto] application,
> > this [urandom] is acceptable"). Jitsi falls right into that statement.
> I'll have to strongly disagree with you here. For long term OTR key
> generation, this is plain wrong. OTR uses Diffie-Hellman which
> *absolutely* needs the strongest random generator available meaning
> strong cryptographic values. Its security is based on that premise.
> There is *no* reason to compromise with urandom since you are not sure
> that you'll get that guarantee of strong random values.
> I just think that when you can get the best random values for a use case
> like OTR keys, it should be done since it is available.
> > Assuming bug-free /dev/urandom (and /dev/random):
> > The attack that would break urandom would mean an attack on the hashing
> > algorithm. If this happens then you have bigger worries than your OTR
> > (for example you would have to redevelop some other parts of the security
> > protocol as this would no longer be secure as well).
> Agreed, if SHA1 breaks, there is bigger problem :).
> > Jitsi shall use urandom as described in the kernel docs.
> > Cheers!
> > > David
> > >
> > > _______________________________________________
> > > dev mailing list
> > > email@example.com
> > > Unsubscribe instructions and other list options:
> > > http://lists.jitsi.org/mailman/listinfo/dev
> > >
> > _______________________________________________
> > dev mailing list
> > firstname.lastname@example.org
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
> dev mailing list
> Unsubscribe instructions and other list options:
dev mailing list
Unsubscribe instructions and other list options: