Displaying 7 results from an estimated 7 matches for "unseeded".
Did you mean:
unneeded
2005 Feb 16
11
[Bug 968] OpenSSH 3.8p1 PRNG seed extraction failed error
http://bugzilla.mindrot.org/show_bug.cgi?id=968
djm at mindrot.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #760| |ok?
Flag| |
------- Additional Comments From djm at mindrot.org 2005-02-16 11:24 -------
2016 Jul 29
2
getrandom waits for a long time when /dev/random is insufficiently read from
...input_pool to the blocking_pool based on the caller at the /dev/
random device. This implies that the reader for getrandom will NOT be able to
obtain data from the input_pool and the nonblocking_pool because the transfer
operation will not succeed. This implies that the nonblocking_pool remains
unseeded and yet getrandom returns data to the caller.
>
> That, however, is not the behavior I observed, which is that reading
> any amount from /dev/random will never block (since it is fed
> from /dev/urandom on the host side) whereas calling getrandom will
> always block unless /dev/rand...
2016 Jul 29
2
getrandom waits for a long time when /dev/random is insufficiently read from
...input_pool to the blocking_pool based on the caller at the /dev/
random device. This implies that the reader for getrandom will NOT be able to
obtain data from the input_pool and the nonblocking_pool because the transfer
operation will not succeed. This implies that the nonblocking_pool remains
unseeded and yet getrandom returns data to the caller.
>
> That, however, is not the behavior I observed, which is that reading
> any amount from /dev/random will never block (since it is fed
> from /dev/urandom on the host side) whereas calling getrandom will
> always block unless /dev/rand...
2016 Jul 29
0
getrandom waits for a long time when /dev/random is insufficiently read from
...; blocking_pool based on the caller at the /dev/ random device. This
> implies that the reader for getrandom will NOT be able to obtain data
> from the input_pool and the nonblocking_pool because the transfer
> operation will not succeed. This implies that the nonblocking_pool
> remains unseeded and yet getrandom returns data to the caller.
I don't understand what this means. For my use case, hwrng is fed from
the host's urandom, so none of /dev/random, /dev/hwrng, /dev/urandom,
or getrandom with any flags in the guest should ever block except
possibly for very large amounts reque...
2006 Feb 22
2
[librsync-users] MD4 second-preimage attack
On Tue, 2006-02-21 at 14:58 -0800, rsync2eran@tromer.org wrote:
> A year ago we discussed the strength of the MD4 hash used by rsync and
> librsync, and one of the points mentioned was that only collision
> attacks are known on MD4.
Could you please forward this into the bug tracker so it's not lost?
--
Martin
-------------- next part --------------
A non-text attachment was
2016 Jul 29
2
getrandom waits for a long time when /dev/random is insufficiently read from
Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu:
Hi Alex,
> On Fri, 29 Jul 2016 12:24:27 +0200
>
> Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> > On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller
> >
> > <smueller at chronox.de> wrote:
> > > And finally, you have a coding error that is very very common but
> > > fatal
2016 Jul 29
2
getrandom waits for a long time when /dev/random is insufficiently read from
Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu:
Hi Alex,
> On Fri, 29 Jul 2016 12:24:27 +0200
>
> Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> > On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller
> >
> > <smueller at chronox.de> wrote:
> > > And finally, you have a coding error that is very very common but
> > > fatal