Talk:/dev/random
From Wikipedia, the free encyclopedia
Contents |
[edit] Typical?
The article says:
- It is typically used for providing a character stream for encryption, incompressible data, or securely overwriting files.
No. These are not typical uses but rather they are just some of the typical uses. But it is no more secure to overwrite a file with random data than it is do to do will nulls, so that is a poor and inefficient way of overwriting files!
Paul Beardsell 23:27, 27 Sep 2004 (UTC)
Actually, I (and apparently the U.S. gov't) disagree.
The DoD regulation for deleting files securely states that overwriting with random material (maybe up to 5 times) will ensure that any orderly data is gone. If you only use 0s and 1s, the possibility is there that a clever recovery could analyze the HD and determine if parts are not totally zeroed out. Theoretically, this would permit an attacker/recovery expert to locate segments of files. Random overwrite makes this impossible: the underlying structure is now totally random. nneonneo 18:48, 30 January 2006 (UTC)
- This is wrong. First, the DoD would rather you melt or grind the media. Second, it's silly to go to extreme measures defeating an exotic threat without also addressing the problem of bad block replacement relocating your data. Your data may be all over the drive, never overwritten, because the hard drive decided that a sector was about to fail. It is better to be fast, just in case you get interrupted by the enemy, and so that you are not tempted to skip the operation. 24.110.60.225 03:08, 5 July 2006 (UTC)
-
- Using a journaling file system carries a similar risk. IMHO, the most reliable way to ensure that deleted data is unreadable is to never write unencrypted data to the platter in the first place. Failing that, overwriting with several passes of random data is best, precisely because it decreases the signal-to-noise ratio for any attacker trying to read the old bits. See Peter Gutmann's 1996 paper Secure Deletion of Data from Magnetic and Solid-State Memory for a thorough discussion of the issues.
-
- That said, /dev/random is unsuitable for wiping disks simply because it's slow, even if you use urandom. I use it to seed a fast CSPRNG and use that for the overwriting. Unless you expect a major corporation or intelligence agency to try to read your disk, and have data they would find interesting, it works well enough. Tualha (Talk) 17:46, 24 November 2006 (UTC)
[edit] How do we know...
How do we know that stuff that comes from /dev/random isn't actually XOR'd with what goes into /dev/null? That /dev/null info has to go back into the machine somehow, or else it might collect inside the CPU fan and hinder that source of information.
This /dev/random seems like it could be hazardous if overused--it could overflow into /dev/zero and junk up the whole system. There should be a /dev/monitor that puts information back into the entropy pool and junks the pool when it gets close to overflowing. Though where this junk goes to could be a problem. There should probably be some type of information bottle that the user could change when necessary.
This bottle of potentially valuable information could then be sold to an InfoDump, which would distill the sticky black stuff into clear, pure inert information and sell the excess junk to some bigger InfoDump... --Ihope127 23:58, 11 July 2005 (UTC)
- Sounds to me as if it's already overflowed into your brain. Wiseguy ;) Tualha (Talk) 17:46, 24 November 2006 (UTC)
[edit] Confusion
I am confused. urandom takes the output of random, and applies additional transformations? In which case, why is it called a "pseudo-random" number generator? I associate psuedo-random with purely numerical algorithms that produce predictable, but hopefully acceptable output given a seed. Sdedeo 22:24, 2 September 2005 (UTC)
- /dev/urandom is the non-blocking form of /dev/random. It outputs exactly what /dev/random does up until the entropy pool runs out, at which point it uses a different PRNG to generate values. Thus, it is non-blocking, but output isn't guaranteed to be of high quality. nneonneo 18:35, 30 January 2006 (UTC)
[edit] Python Code
f=open('/dev/random', 'r')
print repr(f.read(10))
'\xb6.\x06\xd4\x93\x8d\r\x86\x19W'
I am not sure how to parse this. Looks like there are Unicode characters (prefixed with \) and Ascii characters with the forward slash...
- /dev/[u]random generate bytes in the entire possible range (0x00 - 0xFF). Thus, there isn't any particular pattern, the bytes are meant to be used in a crypto ky, for example.
To get random letters from /dev/random, you would likely try code like this:
# Run me using sudo on most systems!
f=open('/dev/random', 'rb')
charset='abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890'
print ''.join([charset[ord(i)%len(charset)] for i in f.read(100)])
f.close()
This generates 10 random characters in [a-zA-Z0-9]. There is a slight bias that must be noted: due to the limited range of a byte, the letters appearing earlier in the string will appear slightly more frequently than those appearing last. nneonneo 19:07, 30 January 2006 (UTC)
[edit] Others uses of /devv/random and /dev/urandom
- /dev/urandom can be used to test a sound card,headphones...
cat /dev/urandom > /dev/dsp
[edit] Other operating systems
Maybe there are others, but for certain there's NoiseSYS - a device driver which runs under DOS and provides RANDOM and URANDOM (RANDOM$ and URANDOM$ in later versions) which do the same. As DOS allows device names to be preceeded by /DEV the /DEV/RANDOM is a fully possible solution under DOS. maybe that should be mentioned?
[edit] UNIX systems?
Is /dev/random a typical device of a UNIX system? I thought that this was introduced with the Linux kernel and adopted by OpenBSD/FreeBSD a bit later and by Solaris a lot later. Anybody has knowledge on that?
- Sure. Theodore Ts'o <tytso@mit.edu> (pronounced "Cho", with a long O sound) wrote it for Linux. FreeBSD cloned it, badly, failing to do the entropy accounting that is so critical to preventing undiscovered hash/cipher weaknesses from affecting the randomness quality. Solaris is indeed recent. MacOS X has a /dev/random too. 24.110.60.225 03:17, 5 July 2006 (UTC)
Wait, I thought it was part of AT&T UNIX? 71.81.37.151 05:47, 21 November 2006 (UTC)
