A little memo from/dev/random and/dev/urandom

1. Basic Introduction

/dev/random and/dev/urandom are random pseudo-devices provided in Linux systems, and the task of both devices is to provide a random byte stream that is never empty. Many decryption programs and security applications (such as SSH Keys,ssl Keys, etc.) require the random data streams they provide.

The difference between the two devices is that/dev/random's random pool relies on system outages, so when the system has a low number of interrupts, the/dev/random device is blocked, and the attempt to read the process goes into a wait state until the system has enough interrupts,/dev/ Random devices can guarantee the randomness of the data. /dev/urandom does not rely on system interrupts, it does not cause the process to wait, but the randomness of the data is not high.

Use the cat command to read/dev/random and/dev/urandom data streams (binary data streams, which are difficult to read) and can be viewed with the OD command converted to 16 binary:

In the cat process, it was found that the/dev/random produced slow, sometimes there will be a large pause, and/dev/urandom production speed , almost no pause.

By using the DD command to copy data streams from these devices, you find that the speed difference is significant:

Read the 1KB byte stream from the/dev/random:

Read the 1KB byte stream from the/dev/urandom:

The program tests also found that the more/dev/random a device is read, the slower its response.

When using PHP's encryption to extend MCrypt, the Mcrypt_create_iv () function is used to create an initial vector from a random source (initialization vector), which is signed as:

String Mcrypt_create_iv (int $size [, int $source = Mcrypt_dev_urandom])

Note the second parameter of the function $source, in PHP 5.6.0, the parameter is mcrypt_dev_random by default, that is, Mcrypt_create_iv gets the random data source from the/dev/random device by default. When the system concurrency is high, the system fails to provide sufficient number of interrupts, causing the access process to hang (lock) and thus not respond properly.

A simple test script is as follows:

1 <?php2 define ("Mcrypt_key", "X90!-=zo2s"); 3 $src = "Test"; 4 5 $size = Mcrypt_get_iv_size (mcrypt_blowfish,mcrypt_ MODE_ECB); 6 $iv = Mcrypt_create_iv ($size); 7 $encrypted = MCRYPT_ECB (Mcrypt_blowfish, Mcrypt_key, $SRC, Mcrypt_decrypt, $ iv);//5.5+ is deprecated, use the latest API test

We had previously found in the output of the cat/dev/random that there would be a large pause in the output of the random data stream. When the number of concurrent numbers is large, it can cause the read process to wait or even be unresponsive.

Fortunately, we can specify that the second parameter is mcrypt_dev_urandom to force it to use a random stream of/dev/urandom devices (in PHP 5.6.0+ version,/dev/urandom is already used by default as a random data source).

2. Other uses of/dev/random and/dev/random

1. These pseudo-devices can be used instead of mktemp to generate random temporary filenames:

Cat/dev/urandom |od–x | Tr–d  ' | head–n 1

can produce a 128-bit (bit) temporary file name, with high randomness and security.

2. You can simulate the generation of Ssh-keygen generated footprint, the script is as follows:

1 #/bin/sh-2 cat/dev/urandom | 3 Od-x | 4 Head-n 1| 5 cut-d '-F 2-| 6 awk-v ors= ":"  7 ' {8 for     (I=1; i<=nf; i++) {9         if (i = = NF) {             ORS = "\ n";         }12         print substr ($i) ":" Substr ($i, 3,2);     }14} '

A simple explanation of the script:

(1). Cat/dev/urandom | Od-x | The Head-n 1 is used to read a row of data from a random device and convert it to 16 binary. The output of this segment is similar to the following:

(2). Because the first column is actually the offset of the data, not the random data stream, again using cut to remove the following fields: Cut-d '-f2-

(3). Use the awk program output. ORS is the built-in variable for awk, which refers to the output record delimiter, which defaults to \ n.

The output of the script:

Compared with the footprint generated by Ssh-keygen, is not quite like? :D

http://blog.csdn.net/ohmygirl/article/details/40385083

A little memo from/dev/random and/dev/urandom