Re: [Caml-list] Hashtbl and security

2012-01-01 Thread oliver
On Mon, Jan 02, 2012 at 12:58:03AM +0100, Gerd Stolpmann wrote: [...] > > > What I could imagine is a module Sys.Security where all security > > > features are accessible and configurable, e.g. > > > > I doubt that this makes sense. > > Nearly anything that can be programmed can become a security

Re: [Caml-list] Hashtbl and security

2012-01-01 Thread Shawn Wagner
On Fri, 30 Dec 2011 17:44:06 +0100 Gerd Stolpmann wrote: > > What are possible fixes? > > 1) Avoid hash tables in contexts where security is relevant. The > alternative is Set (actually a balanced binary tree), which does not > show this problem. > > 2) Use cryptographically secure hash functio

Re: [Caml-list] Hashtbl and security

2012-01-01 Thread Gerd Stolpmann
Am Montag, den 02.01.2012, 00:24 +0100 schrieb oliver: > > I understand it very well that adding support for cryptographically > > secure random numbers to core Ocaml is a challenge. There is no POSIX > > API, and /dev/random is, although widely available, still non-standard. > [...] > > And also

Re: [Caml-list] Hashtbl and security

2012-01-01 Thread oliver
On Sun, Jan 01, 2012 at 10:04:03PM +0100, Gerd Stolpmann wrote: > Am Sonntag, den 01.01.2012, 18:29 +0100 schrieb Xavier Leroy: > > On 01/01/2012 01:52 PM, Richard W.M. Jones wrote: > > > On Fri, Dec 30, 2011 at 06:06:26PM +0100, Xavier Leroy wrote: > > >> Indeed. The optional "seed" parameter to

Re: [Caml-list] Hashtbl and security

2012-01-01 Thread Gerd Stolpmann
Am Sonntag, den 01.01.2012, 18:29 +0100 schrieb Xavier Leroy: > On 01/01/2012 01:52 PM, Richard W.M. Jones wrote: > > On Fri, Dec 30, 2011 at 06:06:26PM +0100, Xavier Leroy wrote: > >> Indeed. The optional "seed" parameter to Hashtbl.create does exactly > >> this in the new implementation of Hasht

Re: [Caml-list] Hashtbl and security

2012-01-01 Thread Xavier Leroy
On 01/01/2012 01:52 PM, Richard W.M. Jones wrote: > On Fri, Dec 30, 2011 at 06:06:26PM +0100, Xavier Leroy wrote: >> Indeed. The optional "seed" parameter to Hashtbl.create does exactly >> this in the new implementation of Hashtbl (the one based on Murmur3). > > It may be worth noting that Perl s

[Caml-list] Will the data allocated by caml_alloc be automatically freed by g arbage collector?

2012-01-01 Thread syshen
Dear All: I am writing a program that include a main loop written in Ocaml and a sub-module written in C. The main loop called the sub-module a lot, and a huge array is returned from each call. So I use the standard C-Caml interface to return these huge data as shown below: extern "C" val

Re: [Caml-list] Hashtbl and security

2012-01-01 Thread Richard W.M. Jones
On Fri, Dec 30, 2011 at 06:06:26PM +0100, Xavier Leroy wrote: > Indeed. The optional "seed" parameter to Hashtbl.create does exactly > this in the new implementation of Hashtbl (the one based on Murmur3). It may be worth noting that Perl solved this problem (back in 2003) by unconditionally using

Re: [Caml-list] Understanding usage by the runtime

2012-01-01 Thread Richard W.M. Jones
On Sat, Dec 31, 2011 at 10:33:19AM -0500, orb...@ezabel.com wrote: > Being on the C side is not even something I had considered. In this > case, I think the only piece of code not part of the Ocaml RTS that is > talking to C is Lwt. It is possible that there is a memory leak in > there somewhere.