Groups > comp.os.linux.development.apps > #704

Re: shred or scrub

From	crankypuss <crankypuss@nomail.invalid>
Newsgroups	comp.os.linux.development.system, comp.os.linux.development.apps
Subject	Re: shred or scrub
Date	2014-04-20 02:47 -0600
Organization	A noiseless patient Spider
Message-ID	<lj01j8$18f$1@dont-email.me> (permalink)
References	<limvgj$tse$1@dont-email.me> <lio9r0$3jl$1@dont-email.me> <lisn3i$elq$1@dont-email.me> <87ppkd2cx5.fsf@sable.mobileactivedefense.com>

Cross-posted to 2 groups.

Show all headers | View raw

On 04/19/2014 04:05 PM, Rainer Weikusat wrote:
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>> crankypuss wrote:
>>
>>> There exist pseudo-devices 'zero', 'random', and 'urandom':
>>> http://en.wikipedia.org/wiki/Device_file#Pseudo-devices
>>
>>      What's the difference in urandom and random devices?
>
> The kernel is supposed to collect 'bits with unpredictable values' from
> 'suitable sources' and the random-device will only return such bits,
> blocking a reader in case the already collected ones have all been
> handed out. /dev/urandom is a hash-based PRNG which generates bits as
> required by performing a set of calculations on the existing
> 'unpredictable value bit pool'.

If the "entropy pool" is dynamically/asynchronously updated whenever new 
"environmental static" appears, its updating is "truly random", and its 
contents at any time comprise a "truly random" seed.  The only issue 
would be when it is imperative that the same seed not be reused within a 
certain timeframe (which is itself essentially a denial of "true 
randomness"), and that can be compensated for by including the 
fractional parts of the realtime clock in the computation of the seed 
actually dispensed.  Given that "environmental static" occurs every time 
an interaction with the network occurs, every time some devices are 
heard from, in the elapsed time since the last request for a random 
number was received on a multi-thread system, the whole idea of having 
/dev/random block seems pretty silly.  Reducing any multi-thread 
operating system in which device events occur asynchronously to a state 
of complete cyclic stability is so insanely difficult as to approach 
impossible.

imo of course, do I really need to say "imo" on this kind of thing, 
since that seems obvious?

Back to comp.os.linux.development.apps | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-16 18:17 -0400
  Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-17 04:19 -0600
    Re: shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-18 22:30 -0400
      Re: shred or scrub Jasen Betts <jasen@xnet.co.nz> - 2014-04-19 07:42 +0000
        Re: shred or scrub Richard Kettlewell <rjk@greenend.org.uk> - 2014-04-19 10:04 +0100
      Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-19 02:15 -0600
      Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-19 23:05 +0100
        Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-20 02:47 -0600
          Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-20 07:56 -0500
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-21 03:51 -0600
              Re: shred or scrub Jasen Betts <jasen@xnet.co.nz> - 2014-04-21 11:50 +0000
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-21 06:14 -0600
            Re: shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-21 18:44 -0400
          Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-21 13:24 +0100
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-22 04:10 -0600
              Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-22 14:39 +0100
  Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-17 16:41 +0200
  Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-07 22:01 +0100
    Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-08 03:37 -0600
      Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-08 14:02 +0100
        Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-08 15:43 +0100
        Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:56 -0600
          Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 17:57 +0100

csiph-web