* Cory Nelson <phrosty at gmail.com> [2008-07-18 07:57:39]: > On Fri, Jul 18, 2008 at 7:47 AM, Florent Daigni?re > <nextgens at freenetproject.org> wrote: > > * Cory Nelson <phrosty at gmail.com> [2008-07-18 07:27:42]: > > > >> On Fri, Jul 18, 2008 at 7:02 AM, Florent Daigni?re > >> <nextgens at freenetproject.org> wrote: > >> > * Jano <alejandro at mosteo.com> [2008-07-18 15:59:38]: > >> > > >> >> Florent Daigni?re wrote: > >> >> > >> >> > * Jano <alejandro at mosteo.com> [2008-07-18 > >> >> > 13:21:33]: > >> >> > > >> >> >> Since the last version #1153, my node takes a very long time to > >> >> >> start (half > >> >> >> an hour or more). Trying to load the homepage gives a page saying > >> >> >> that > >> >> >> "Freenet is starting up", and below: > >> >> >> > >> >> >> Not enough entropy is available! > >> >> >> There isn't enough entropy available on your system... Freenet won't > >> >> >> start > >> >> >> until it can gather enough. > >> >> >> > >> >> >> This node runs in an unattended box, so any entropy sources will be > >> >> >> non-human. I have read somewhere that /dev/random is slow to refill > >> >> >> and can > >> >> >> be exhausted easily if used too much. Could this be part of the > >> >> >> problem? > >> >> >> > >> >> > > >> >> > This is the problem. > >> >> > > >> >> > Launch a "find / >/dev/null" from a different shell and that should > >> >> > help > >> >> > the OS to refill the entropy pool. > >> >> > >> >> I'm going to try this, it's been two hours now with the node stuck > >> >> waiting. > >> >> > >> >> *** > >> >> > >> >> It worked. I know /dev/urandom is less secure, is there a likely > >> >> possibility of > >> >> attacks if urandom is used instead? > >> > > >> > Before #1153 we were using urandom... and yes that was insecure. > >> > > >> > I might introduce some code to generate hard-drive accesses in 1154. > >> > >> You might want to check out HAVEGE: > >> http://www.irisa.fr/caps/projects/hipsor/ > >> > >> It takes advantage of branch mispredictions to give high quality > >> randomness. The algorithm is quite simple. > > > > Are you aware that freenet is written in java? :) We can't rely on > > architecture-specific problems to generate the entropy we need. > > > > We are already using a cryptographically secure PRNG (Yarrow); The > > node stalls because it can't gather the entropy needed to seed it. > > > > If Java has some way to read the hardware timestamp, that's all that > is needed. Even if not - you guys already have some 3rd party native > library for bignum, right? HAVEGE is better than Yarrow or any PRNG > could hope to be - what's wrong with another lib if it means > randomness that can't run out? >
Native libraries are a PITA to maintain. That alone is a good reason why not to use HAVEGE... Freenet's prng doesn't run out of entropy... the OS' does when freenet tries to seed its PRNG. If the user is concerned about that he can install HAVEGE's kernel module so that he won't have any problem. In the mean time, I am going to implement something which will do some disk accesses in order to help the OS's PRNG to refill its entropy pool. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080718/0591b3c2/attachment.pgp>
