Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.development.system > #618 > unrolled thread
| Started by | "Bill Cunningham" <nospam@nspam.invalid> |
|---|---|
| First post | 2014-04-16 18:17 -0400 |
| Last post | 2014-04-17 16:41 +0200 |
| Articles | 20 on this page of 72 — 10 participants |
Back to article view | Back to comp.os.linux.development.system
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 Kristof Provost <kristof@codepro.be> - 2014-04-17 13:15 +0000
Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-17 09:40 -0500
Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-18 14:40 +0000
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 02:12 -0600
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-18 11:49 +0200
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 09:59 -0600
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-21 16:14 +0200
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-22 04:22 -0600
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-23 00:06 +0200
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-23 05:50 -0600
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-24 22:46 +0200
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-25 03:57 -0600
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-25 19:14 +0100
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-26 04:02 -0600
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-27 21:26 +0100
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 03:27 -0600
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 12:17 +0100
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 13:01 +0100
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-29 02:50 -0600
UNIX(*)/ Linux history & system design (was: shred or scrub) Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-05 21:31 +0100
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-05 16:02 -0600
Re: UNIX(*)/ Linux history & system design David Brown <david.brown@hesbynett.no> - 2014-05-06 01:17 +0200
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-06 01:46 -0600
Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-06 15:09 +0100
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-06 23:47 -0600
Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-07 16:23 +0100
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 10:51 -0600
Re: UNIX(*)/ Linux history & system design Jerry Peters <jerry@example.invalid> - 2014-05-07 20:25 +0000
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-08 03:50 -0600
Re: UNIX(*)/ Linux history & system design Jerry Peters <jerry@example.invalid> - 2014-05-08 20:24 +0000
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:23 -0600
Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 18:36 +0100
Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 21:24 +0100
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 crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:56 -0600
Re: UNIX(*)/ Linux history & system design David Brown <david.brown@hesbynett.no> - 2014-05-07 00:15 +0200
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 00:32 -0600
Re: UNIX(*)/ Linux history & system design Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-05-07 08:47 +0000
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 10:59 -0600
Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-06 14:35 +0100
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-26 16:30 +0200
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-27 05:59 -0600
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-27 20:15 +0100
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 03:29 -0600
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 12:06 +0100
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-27 21:41 +0200
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 04:03 -0600
Re: shred or scrub Richard Kettlewell <rjk@greenend.org.uk> - 2014-04-28 16:44 +0100
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-28 23:39 +0200
Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-18 07:37 -0500
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 10:16 -0600
Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-18 12:01 -0500
Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-18 14:42 +0000
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-17 16:41 +0200
Page 1 of 4 [1] 2 3 4 Next page →
| From | "Bill Cunningham" <nospam@nspam.invalid> |
|---|---|
| Date | 2014-04-16 18:17 -0400 |
| Subject | shred or scrub |
| Message-ID | <limvgj$tse$1@dont-email.me> |
I am using ext4 on my linux. I'm not quite sure of the difference in it and ext3 but anyway; the shred man page says with the ext3 filesystem shred cannot be guaranteed to work. What about scrub? What's the best way to eliminate a file? Bill
[toc] | [next] | [standalone]
| From | crankypuss <crankypuss@nomail.invalid> |
|---|---|
| Date | 2014-04-17 04:19 -0600 |
| Message-ID | <lio9r0$3jl$1@dont-email.me> |
| In reply to | #618 |
On 04/16/2014 04:17 PM, Bill Cunningham wrote: > I am using ext4 on my linux. I'm not quite sure of the difference in it > and ext3 but anyway; the shred man page says with the ext3 filesystem shred > cannot be guaranteed to work. What about scrub? What's the best way to > eliminate a file? > > Bill > > There exist pseudo-devices 'zero', 'random', and 'urandom': http://en.wikipedia.org/wiki/Device_file#Pseudo-devices
[toc] | [prev] | [next] | [standalone]
| From | "Bill Cunningham" <nospam@nspam.invalid> |
|---|---|
| Date | 2014-04-18 22:30 -0400 |
| Message-ID | <lisn3i$elq$1@dont-email.me> |
| In reply to | #619 |
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? I have used the
uuid command to generate a random key of about 20 of these 128 bit uuids and
usesd mcrypt with it. But I will definately use your technique too.
Bill
[toc] | [prev] | [next] | [standalone]
| From | Jasen Betts <jasen@xnet.co.nz> |
|---|---|
| Date | 2014-04-19 07:42 +0000 |
| Message-ID | <lit9dm$vif$1@gonzo.reversiblemaps.ath.cx> |
| In reply to | #631 |
On 2014-04-19, Bill Cunningham <nospam@nspam.invalid> wrote: > 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? Urandom us much faster, but less random. -- umop apisdn --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2014-04-19 10:04 +0100 |
| Message-ID | <wwvmwfhoflj.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf87AxnpFoA.invalid> |
| In reply to | #632 |
Jasen Betts <jasen@xnet.co.nz> writes: > Bill Cunningham <nospam@nspam.invalid> wrote: >> 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? > > Urandom us much faster, but less random. I would recommend this article: http://www.2uo.de/myths-about-urandom/ -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | crankypuss <crankypuss@nomail.invalid> |
|---|---|
| Date | 2014-04-19 02:15 -0600 |
| Message-ID | <litbb0$b0e$1@dont-email.me> |
| In reply to | #631 |
On 04/18/2014 08:30 PM, Bill Cunningham wrote: > 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? I have used the > uuid command to generate a random key of about 20 of these 128 bit uuids and > usesd mcrypt with it. But I will definately use your technique too. > > Bill I haven't studied the code, but the difference is explained-at in "man urandom". The "random" flavor can block waiting on more data in the "entropy pool", the "urandom" flavor doesn't block, according to my reading of it. For shredding a file I'd want the urandom version since waiting for more environmental static isn't productive in that case. The main value of using random numbers to shred the file is that you're not using all-zeros, which for some devices would only "dim" the existing file contents rather than obscuring them into uselessness. Of course this still begs the question that arises when the blocks used by the previously-written file are laying around somewhere indeterminate.
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mobileactivedefense.com> |
|---|---|
| Date | 2014-04-19 23:05 +0100 |
| Message-ID | <87ppkd2cx5.fsf@sable.mobileactivedefense.com> |
| In reply to | #631 |
"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'. In theory, someone who knows what the PRNG returned in the past could be able to predict what it will return in future. In practice no "method for doing so" has been published and this is considered to be 'a very difficult problem which might be impossible to solve'.
[toc] | [prev] | [next] | [standalone]
| From | crankypuss <crankypuss@nomail.invalid> |
|---|---|
| Date | 2014-04-20 02:47 -0600 |
| Message-ID | <lj01j8$18f$1@dont-email.me> |
| In reply to | #635 |
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?
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2014-04-20 07:56 -0500 |
| Message-ID | <87ioq45fch.fsf@thumper.dhh.gt.org> |
| In reply to | #636 |
crankypuss writes: > 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. If there is so much entropy available then it will never block, will it? On the other hand, if it does block, there wasn't as much entropy available *on that particular system* as you thought. You'd be surprised how easy it is to run a low-activity machine out of entropy. In practice one uses random for paranoid activities such as generating important keys and urandom for everything else. You are, of course, free to use urandom to generate your new GPG key. -- John Hasler jhasler@newsguy.com Dancing Horse Hill Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | crankypuss <crankypuss@nomail.invalid> |
|---|---|
| Date | 2014-04-21 03:51 -0600 |
| Message-ID | <lj2pnm$dqv$1@dont-email.me> |
| In reply to | #637 |
On 04/20/2014 06:56 AM, John Hasler wrote: > crankypuss writes: >> 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. > > If there is so much entropy available then it will never block, will it? Depends on the way entropy is collected; it's there, but whether it's collected is another question. To find out if it ever blocks it should be easy enough to write a test that hammers it and see. > On the other hand, if it does block, there wasn't as much entropy > available *on that particular system* as you thought. You'd be > surprised how easy it is to run a low-activity machine out of entropy. There's a lot of "random" activity in even the tiniest world, but if it's ignored there might as well not be any at all.
[toc] | [prev] | [next] | [standalone]
| From | Jasen Betts <jasen@xnet.co.nz> |
|---|---|
| Date | 2014-04-21 11:50 +0000 |
| Message-ID | <lj30lk$d75$1@gonzo.reversiblemaps.ath.cx> |
| In reply to | #638 |
On 2014-04-21, crankypuss <crankypuss@nomail.invalid> wrote: > On 04/20/2014 06:56 AM, John Hasler wrote: >> crankypuss writes: >>> 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. >> >> If there is so much entropy available then it will never block, will it? > > Depends on the way entropy is collected; it's there, but whether it's > collected is another question. To find out if it ever blocks it should > be easy enough to write a test that hammers it and see. eg: to hammer it run this in a terminal od -Ax -tx1 -w1 < /dev/random To "make entropy" shake the mouse. -- umop apisdn --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | crankypuss <crankypuss@nomail.invalid> |
|---|---|
| Date | 2014-04-21 06:14 -0600 |
| Message-ID | <lj3231$22i$1@dont-email.me> |
| In reply to | #639 |
On 04/21/2014 05:50 AM, Jasen Betts wrote: > On 2014-04-21, crankypuss <crankypuss@nomail.invalid> wrote: >> On 04/20/2014 06:56 AM, John Hasler wrote: >>> crankypuss writes: >>>> 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. >>> >>> If there is so much entropy available then it will never block, will it? >> >> Depends on the way entropy is collected; it's there, but whether it's >> collected is another question. To find out if it ever blocks it should >> be easy enough to write a test that hammers it and see. > > eg: to hammer it run this in a terminal > > od -Ax -tx1 -w1 < /dev/random > > To "make entropy" shake the mouse. > > I see my wireless modem carrying on doing this and that but nothing contributes to the entropy-pool, which makes it pretty clear that a lot of sources of environmental static are being ignored.
[toc] | [prev] | [next] | [standalone]
| From | "Bill Cunningham" <nospam@nspam.invalid> |
|---|---|
| Date | 2014-04-21 18:44 -0400 |
| Message-ID | <lj4702$ivc$1@dont-email.me> |
| In reply to | #637 |
"John Hasler" <jhasler@newsguy.com> wrote in message news:87ioq45fch.fsf@thumper.dhh.gt.org... > If there is so much entropy available then it will never block, will it? > On the other hand, if it does block, there wasn't as much entropy > available *on that particular system* as you thought. You'd be > surprised how easy it is to run a low-activity machine out of entropy. > > In practice one uses random for paranoid activities such as generating > important keys and urandom for everything else. You are, of course, > free to use urandom to generate your new GPG key. I have used uuid -v4 -n 20 to generate a random key. Of course this may be not "truly" random. And then used mcrypt to crypt a file. Seems to work pretty cool.
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mobileactivedefense.com> |
|---|---|
| Date | 2014-04-21 13:24 +0100 |
| Message-ID | <87r44qoopn.fsf@sable.mobileactivedefense.com> |
| In reply to | #636 |
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. > 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.
[toc] | [prev] | [next] | [standalone]
| From | crankypuss <crankypuss@nomail.invalid> |
|---|---|
| Date | 2014-04-22 04:10 -0600 |
| Message-ID | <lj5f5u$vol$1@dont-email.me> |
| In reply to | #641 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mobileactivedefense.com> |
|---|---|
| Date | 2014-04-22 14:39 +0100 |
| Message-ID | <8738h51o11.fsf@sable.mobileactivedefense.com> |
| In reply to | #644 |
crankypuss <crankypuss@nomail.invalid> writes: > 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: [...] >>>> The kernel is supposed to collect 'bits with unpredictable values' from >>>> 'suitable sources' [...] >>> 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. There's a "cause and effect" relation here which means "it is not necessarily unpredictable" (by an external observer). But that was actually a 'discussion in the past' were someone argued that the point of /dev/random would be 'to provide paranoid guarantees' and most other people disagreed with that. At least the kernel I examined (3.2.54) seemed to use/ used 'interrupt timing information' as entropy source regardless of the 'kind' of interrupt (almost). [...] >> 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. There is no such thing as 'a random number', there are only 'randomly chosen numbers' aka 'unpredictable numbers'. > 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. Your second-to-last paragraph is really tangential (term?) to your last one, ie "a non sequitur". Unpredictable numbers can be collected by observing repeated processes which yield them as a side effect, say, for a totally contrived example, someone rolling a dice and putting the results into the kernel entropy people by entering them via terminal. Each repetition of the process needs some time for execution, hence, unpredictable numbers are produced at some finite rate/ with some finite speed. Because of this, it is theoretically possible to extract these numbers faster than they can be generated, because extraction is a very fast process (block memory copy), that's not only possible but also probable, and, as can be trivially determined by experimentation, it is not only probable but actually existent: At some point in time, the extraction process has to wait for the next dice roll. There's a qualitative difference between "doing X is [considered to be] impossible" and "it is conjectured that nobody knows how to do X".
[toc] | [prev] | [next] | [standalone]
| From | Kristof Provost <kristof@codepro.be> |
|---|---|
| Date | 2014-04-17 13:15 +0000 |
| Message-ID | <slrnlkvkrl.2p2.kristof@vega.codepro.be> |
| In reply to | #618 |
On 2014-04-16, Bill Cunningham <nospam@nspam.invalid> wrote: > I am using ext4 on my linux. I'm not quite sure of the difference in it > and ext3 but anyway; the shred man page says with the ext3 filesystem shred > cannot be guaranteed to work. > That's because there's no way to guarantee that the file system will write the new data over the same block as the old data. In fact, in log-structured file systems (like ZFS, but not ext3/4) the file system will deliberately not do this. Let's not even get into what the drive's firmware might do w.r.t. remapping sectors. > What about scrub? What's the best way to eliminate a file? > Physically destroy the drive. Use thermite[1]. Lots of it. Regards, Kristof [1] Never waste an opportunity to use thermite.
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2014-04-17 09:40 -0500 |
| Message-ID | <87ioq881el.fsf@thumper.dhh.gt.org> |
| In reply to | #620 |
Kristof Provost writes: > Physically destroy the drive. Use thermite[1]. Lots of it. Or. if you actually want to be practical, use sandpaper. Then you salvage all those nice parts. -- John Hasler jhasler@newsguy.com Dancing Horse Hill Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | Kristof Provost <kristof@codepro.be> |
|---|---|
| Date | 2014-04-18 14:40 +0000 |
| Message-ID | <slrnll2e6t.2p2.kristof@vega.codepro.be> |
| In reply to | #622 |
On 2014-04-17, John Hasler <jhasler@newsguy.com> wrote: > Kristof Provost writes: >> Physically destroy the drive. Use thermite[1]. Lots of it. > > Or. if you actually want to be practical, use sandpaper. Then you > salvage all those nice parts. Bah. You're no fun. Kristof
[toc] | [prev] | [next] | [standalone]
| From | crankypuss <crankypuss@nomail.invalid> |
|---|---|
| Date | 2014-04-18 02:12 -0600 |
| Message-ID | <liqmp7$4md$1@dont-email.me> |
| In reply to | #620 |
On 04/17/2014 07:15 AM, Kristof Provost wrote: > On 2014-04-16, Bill Cunningham <nospam@nspam.invalid> wrote: >> I am using ext4 on my linux. I'm not quite sure of the difference in it >> and ext3 but anyway; the shred man page says with the ext3 filesystem shred >> cannot be guaranteed to work. >> > That's because there's no way to guarantee that the file system will > write the new data over the same block as the old data. In fact, in > log-structured file systems (like ZFS, but not ext3/4) the file system > will deliberately not do this. That seems very messed up.
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.os.linux.development.system
csiph-web