On 18/07/14 16:33, Justin Cormack wrote: > Looking at what is being used, it is reading 512 byte chunks, several > of them, so maybe trying to get 8k > > Thats actually rather too much to use /dev/random at all. Linux says > > While some safety margin above that minimum is reasonable, > as a guard against flaws in the CPRNG algorithm, no crypto‐graphic > primitive available today can hope to promise more than 256 bits of > security, so if any program reads more than 256 bits (32 bytes) > from the kernel random pool per invocation, or per reasonable reseed > interval (not less than one minute), that should be taken as a sign > that its cryptography is not skillfully implemented.
In that case, either the manual page or NetBSD is not skillfully implemented ;) As for the points in your other mail, the more I thought about this, the more convinced I was that before fixing anything, cprng and rndsink should be looked at critically to see what their requirements really are and if they really need to slurp in 8k. As a mid-term hack, might just make the implementation always read from /dev/urandom and return some sensible amount of data. ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
