From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2E9NPos000554 for ; Wed, 14 Mar 2012 10:23:25 +0100 X-IronPort-AV: E=Sophos;i="4.73,583,1325458800"; d="scan'208";a="149274886" Received: from estephe.inria.fr (HELO [128.93.11.95]) ([128.93.11.95]) by mail1-relais-roc.national.inria.fr with ESMTP; 14 Mar 2012 10:23:21 +0100 Message-ID: <4F606389.5090203@inria.fr> Date: Wed, 14 Mar 2012 10:23:21 +0100 From: Xavier Leroy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: caml-list@inria.fr References: <4F3078F1.8070105@redhat.com> <4F3079F7.4040606@redhat.com> <20120207083412.GA30350@annexia.org> <20120310073113.GA16716@annexia.org> <4F5E3A6E.4010406@inria.fr> <4F5F1968.20600@lsv.ens-cachan.fr> <4ec32a156daa6211ca4d465c9a7b8745.squirrel@gps.dynxs.de> <1331662124.86804.YahooMailNeo@web111509.mail.gq1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Re: [oss-security] CVE request: Hash DoS vulnerability (ocert-2011-003) 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