Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Re: shred or scrub

Cross-posted to 2 groups.

Show all headers | View raw

On 04/21/2014 06:24 AM, Rainer Weikusat wrote:
> crankypuss <crankypuss@nomail.invalid> writes:
>> 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'.
>
> [...]
>
>> Given that "environmental static" occurs every
>> time an interaction with the network occurs,
>
> NIC drivers don't feed input into the entropy pool (or don't do so
> anymore) because 'interactions with the network' happen in response to
> 'interactions with the network' on some unrelated computer.

The fact that they vary in relation to some unrelated computer makes 
them more "truly random" than otherwise, any time a network interaction 
involves a measurable delay across 2 or more intermediate nodes, the 
delay value is way out there into the "really random" area, because 
variations in system-load and transmission latency are both 
indeterminate and multiplicative.

>> 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.
>
> I don't quite understand what you're up to. Obviously, the number of
> bits added to the entropy pool during any given time interval must be
> finite, hence, it is at least theoretically possible to remove bit from
> it at a higher speed and hence, exhaust the available supply sooner or
> later. Considering that 'reading data from /dev/random' essentially
> amounts to a memory-to-memory copy which can be done faster than
> 'exchanging data with some device', it doesn't seem inconceivably to
> achieve this. Practically, dd can be used to test that it actually
> happens: Executing
>
> dd if=/dev/random bs=4096 count=1 of=x
>
> on the machine I'm using to write this (3.2.9) usually results in a
> couple of 'short reads' followed by an invocation which blocks for some
> seconds.
>

If a number is "truly random" you can't make it non-random in any 
absolute sense, even adding non-random low-order bits only makes it 
non-random in a comparative sense.

This whole "truly random" business, as someone noted earlier, quickly 
shifts into the philosophical area; in one sense it is extremely easy to 
come up with a number that is "truly random" given sufficiently precise 
measurements (even line voltage and frequency are constantly varying) or 
a sufficiently large event-pool (such as any nontrivial network), and in 
another sense there is nothing that is "truly random" within a causal 
universe (the closest one can come to acausality is "undeterminable", 
which oddly enough is how we define "random").

I'm more than willing to shut up, but before doing so I'll reiterate my 
opinion that any "truly random" number generator that blocks because it 
ran out of environmental static is pretty lame.

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