Re: HTTPD asking for password after power failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 12, 2016 at 9:31 PM, Christopher Schultz
<chris@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On 8/11/16 11:10 PM, Marat Khalili wrote:
>> From what I saw, this behavior of /dev/random is totally normal on
>> an idle Linux system.
>
> There seems to be some confusion about /dev/random on Linux systems.
> Yes, the behavior described here is normal: when the system comes up,
> there is very little entropy available on /dev/random. /dev/random
> needs random events to occur in order to provide that entropy, and
> those events are things like I/O interrupt timings, etc.

There is quickly not enough entropy when using /dev/random, and very
few (if any) interest in using it.

>
> IIRC, Linux relies on the keyboard to generate lots of those events
> and, on a server, the keyboard by definition doesn't get used. So
> other events are required to fill that entropy pool. So, after a
> reboot, the entropy pool is "shallow".

This is true after booting, but also each time /dev/random is (ab)used.

On the other hand, there is /dev/urandom, requiring 128bits of entropy
to be initialized (which are always there after the boot, except maybe
for specific embedded devices with no disk, hardly servers), plus a
few more entroy from time to (long) time, and is just as secure as
/dev/random (often the same implementation, certainly on Linux), while
never waiting/blocking for entropy...

>
> /dev/random is supposed to be a source of high-quality randomness
> /dev/urandom is supposed to be a source of low-quality randomness

This isn't true.

>
>> Just do not ever use /dev/random.

+1

>
> The choice of which to use is up to you, but remember that low-quality
> randomness gets you low-quality crypto keys. But to say that one
> should "not ever use /dev/random" is really bad advice.

If you really want to block and exhaust all entropy for the (few)
needs of /dev/urandom users, well you can use it, otherwise don't.


Regards,
Yann.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx




[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux