Sponsored Content
Special Forums Hardware Filesystems, Disks and Memory Destroying data down to the 13th level??? Post 18845 by Kelam_Magnus on Wednesday 3rd of April 2002 03:54:47 PM
Old 04-03-2002
Something my instructor had us do in HPUX class a few years ago works too.

Create a tar file and write the output to a disk device. This should destroy any data that was there. Also, if you system has a /dev/zero file. You can write zeroes to the disk as well.

Like PxT said, as long as the disk is in a "secure" site you shouldn't have to worry too much.

BTW, that reference to 13th level is referring to the 13th level of hell, reserved for the most deserving of all evil creatures and persons!Smilie


Smilie
 

4 More Discussions You Might Find Interesting

1. AIX

destroying the OS

Hi Guys I have a cool job to do and that's to destroy aix5.1 on two of my servers. I need to get rid of all information. I have thought of a way of doing this and wondered if any of you had any ideas!! Get the machine into maint mode and run the dd cmd! (7 Replies)
Discussion started by: animata
7 Replies

2. Solaris

Difference between run level & init level

what are the major Difference Between run level & init level (2 Replies)
Discussion started by: rajaramrnb
2 Replies

3. Shell Programming and Scripting

Replace a value after 13th comma in a string

Suppose b=50,0,0,40,1,0,5000,gold,0,0,0,0,32,9,2,0,10000,0,0,0,0,0,0,0,0,0,BSNL_SMS_Bundle ,null,null,null,null,null,null,null,null,null,0,0,0,0,0,0,0,0,0,0,50,0,0,0,0,0,0,0,0,0,null,null,0,0,405564245,0 c=11 After 13th comma, the value of 9 needs to be changed and to be filled by another... (4 Replies)
Discussion started by: karan23kohli
4 Replies

4. Red Hat

SSL certificate generation on OS level or application level

We have a RHEL 5.8 server at the production level and we have a Java application on this server. I know of the SSL certificate generation at the OS (RHEL) level but it is implemented on the Java application by our development team using the Java keytool. My doubt is that is the SSL generation can... (3 Replies)
Discussion started by: RHCE
3 Replies
random(7D)							      Devices								random(7D)

NAME
random, urandom - Strong random number generator device SYNOPSIS
/dev/random /dev/urandom DESCRIPTION
The /dev/random and /dev/urandom files are special files that are a source for random bytes generated by the kernel random number generator device. The /dev/random and /dev/urandom files are suitable for applications requiring high quality random numbers for cryptographic pur- poses. The generator device produces random numbers from data and devices available to the kernel and estimates the amount of randomness (or "entropy") collected from these sources. The entropy level determines the amount of high quality random numbers that are produced at a given time. Applications retrieve random bytes by reading /dev/random or /dev/urandom. The /dev/random interface returns random bytes only when suffi- cient amount of entropy has been collected. If there is no entropy to produce the requested number of bytes, /dev/random blocks until more entropy can be obtained. Non-blocking I/O mode can be used to disable the blocking behavior. The /dev/random interface also supports poll(2). Note that using poll(2) will not increase the speed at which random numbers can be read. Bytes retrieved from /dev/random provide the highest quality random numbers produced by the generator, and can be used to generate long term keys and other high value keying material. The /dev/urandom interface returns bytes regardless of the amount of entropy available. It does not block on a read request due to lack of entropy. While bytes produced by the /dev/urandom interface are of lower quality than bytes produced by /dev/random, they are nonetheless suitable for less demanding and shorter term cryptographic uses such as short term session keys, paddings, and challenge strings. Data can be written to /dev/random and /dev/urandom. Data written to either special file is added to the generator's internal state. Data that is difficult to predict by other users may contribute randomness to the generator state and help improve the quality of future gener- ated random numbers. By default, write access is restricted to the super-user. An administrator may change the default read/write restriction by changing the permissions on the appropriate special files. /dev/random collects entropy from providers that are registered with the kernel-level cryptographic framework and implement random number generation routines. The cryptoadm(1M) utility allows an administrator to configure which providers will be used with /dev/random. ERRORS
EAGAIN O_NDELAY or O_NONBLOCK was set and no random bytes are available for reading from /dev/random. EINTR A signal was caught while reading and no data was transferred. ENOXIO open(2) request failed on /dev/random because no entropy provider is available. FILES
/dev/random /dev/urandom ATTRIBUTES
See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Availability | SUNWcsr | +-----------------------------+-----------------------------+ |Interface Stability |Evolving | +-----------------------------+-----------------------------+ SEE ALSO
cryptoadm(1M), open(2), poll(2), attributes(5) NOTES
/dev/random can be configured to use only the hardware-based providers registered with the kernel-level cryptographic framework by dis- abling the software-based provider using cryptoadm(1M). You can also use cryptoadm(1M) to obtain the name of the software-based provider. Because no entropy is available, disabling all randomness providers causes read(2) and poll(2) on /dev/random to block indefinitely and results in a warning message being logged and displayed on the system console. However, read(2) and poll(2) on /dev/random continue to work in this case. An implementation of the /dev/random and /dev/urandom kernel-based random number generator first appeared in Linux 1.3.30. A /dev/random interface for Solaris first appeared as part of the CryptoRand implementation. SunOS 5.10 21 June 2004 random(7D)
All times are GMT -4. The time now is 10:01 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy