Re: cvs commit: src/etc crontab rc src/etc/defaults rc.conf src/etc/mtree BSD.root.dist src/libexec Makefile src/libexec/save-entropy Makefile save-entropy.sh

2001-01-12 Thread Warner Losh

In message [EMAIL PROTECTED] Maxim Sobolev writes:
: I like this idea, but perhaps it would be nice to have more
: fine-grained control over when /dev/random is blocking and when
: not. Why not to add sysctl to switch between blocking/non-blocking
: behaviour (defaulting to non-blocking), so our startup scripts would
: be able to switch /dev/random to be secure at the point when it's
: safe to do (all f/s mounted) much like it copes with
: kern.securelevel.  Additionaly it would solve the problem that you
: are not able to use almost anything in single-user mode (less, vi,
: ee etc) w/o feeding /dev/random by hand first.

That's why I had the first write clause in my statement.  The act of
seeing it, which writes to /dev/random, would be enough.  No need to
make it more complex than it has to be.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: cvs commit: src/etc crontab rc src/etc/defaults rc.conf src/etc/mtree BSD.root.dist src/libexec Makefile src/libexec/save-entropy Makefile save-entropy.sh

2001-01-12 Thread Maxim Sobolev

Warner Losh wrote:

 In message [EMAIL PROTECTED] Maxim Sobolev writes:
 : I like this idea, but perhaps it would be nice to have more
 : fine-grained control over when /dev/random is blocking and when
 : not. Why not to add sysctl to switch between blocking/non-blocking
 : behaviour (defaulting to non-blocking), so our startup scripts would
 : be able to switch /dev/random to be secure at the point when it's
 : safe to do (all f/s mounted) much like it copes with
 : kern.securelevel.  Additionaly it would solve the problem that you
 : are not able to use almost anything in single-user mode (less, vi,
 : ee etc) w/o feeding /dev/random by hand first.

 That's why I had the first write clause in my statement.  The act of
 seeing it, which writes to /dev/random, would be enough.  No need to
 make it more complex than it has to be.

Seeding it with *something* (ls, vmstat, date etc) is not equial to seeding it
properly, i.e using data with high enough amount of entropy in it. Therefore,
such sysctl may be potentially used to determine that random generator is in
insecure state and should not be used for anything that require high level of
randomness (key generation for example - ssh may check such sysctl and refuse
to generate a key or at least warn a user about possible problems).

Just my UAH0.02 ;).

-Maxim



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message