From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003)
Date: Wed, 14 Mar 2012 10:23:21 +0100 [thread overview]
Message-ID: <4F606389.5090203@inria.fr> (raw)
In-Reply-To: <E51C5B015DBD1348A1D85763337FB6D9C28B1218@Remus.metastack.local>
Gerd Stolpmann writes:
> The Random module is definitely not good enough (e.g. if you
> know when the program was started like for a cgi, and the cgi reveals
> information it should better not like the pid, the Random seed is made
> from less than 10 unpredictable bits, and on some systems even 0 bits).
Dario Teixeira adds:
> I think the problem may be in finding a good source of randomness
> that is common across all OSes. In Unixland this problem has
> largely been solved: pretty much everyone supports /dev/random and
> /dev/urandom. Windows does things differently, however.
David Allsopp adds:
> Does the source of randomness have to be common? The decision to use
> a random seed doesn't need to be limited by a problem getting a good
> cryptographically secure generator on a given OS - you'd simply
> document that the implementation on that particular OS doesn't seed
> with a good PRNG and await a patch from someone who may care in the
> future, but at least the philosophy behind the decision is correct!
We are also thinking of strengthening Random.self_init, for instance
by using /dev/urandom when available. This said, for randomizing
hashtables or other data structures, we do *not* need a
cryptographically-strong PRNG: we're not generating an RSA key pair or
some other situation where cryptographic quality is required; we're
just making a mild DOS attack impractical.
(Obligatory advertisement: if you're in need of
cryptographically-strong random data,
http://forge.ocamlcore.org/projects/cryptokit/
is what you need.)
- Xavier Leroy
next prev parent reply other threads:[~2012-03-14 9:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4F3078F1.8070105@redhat.com>
2012-02-07 1:10 ` Kurt Seifried
2012-02-07 8:34 ` Richard W.M. Jones
2012-03-10 7:31 ` Richard W.M. Jones
2012-03-10 12:31 ` Gerd Stolpmann
2012-03-12 18:03 ` Xavier Leroy
2012-03-13 9:54 ` Romain Bardou
2012-03-13 11:58 ` Paolo Donadeo
2012-03-13 12:31 ` Philippe Veber
2012-03-13 13:23 ` Gerd Stolpmann
2012-03-13 15:39 ` Romain Bardou
2012-03-13 18:27 ` David Allsopp
2012-03-13 18:58 ` Alain Frisch
2012-03-13 18:08 ` Dario Teixeira
2012-03-13 18:28 ` David Allsopp
2012-03-14 9:23 ` Xavier Leroy [this message]
2012-03-13 16:52 ` Richard W.M. Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F606389.5090203@inria.fr \
--to=xavier.leroy@inria.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox