## Randomness in GNU/Linux

| |
[ 所属分类 系统（linux） | 发布者 店小二05 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

end of TL;DR so now go and read…

Sources of randomness

Randomness is the lack of pattern or predictability in events. - Wikipedia

There are three generally accepted sources of randomness: * environment the system is working in * initial conditions of the system * things generated by the system itself

Randomness generated by the system itself is called pseudo -randomness. There is no mathematical source of true randomness.

The power of random things is that those things are really unpredictable. In truly random events no one is able to predict the nature of next event. These events can be random in time, intensity, but often called as being stochastic .

Randomness in computer systems

Some of you might know this meme from xkcd :

int getRandomNumber() { return 4 // chosen by fair dice roll // guaranteed to be random }

While its output being truly random above function is still quite unusable when unpredictability is needed and in context of randomness unpredictability is always needed.

In computer system high enough unpredictability is often as useful as full unpredictability. It is only a matter of energy (or value \$\$\$) needed to predict next event. As long as energy needed for predicting things is higher than the value of the achievement of successful prediction we can say system is unpredictable enough.

Also time should be taken into account because calculating power comes cheaper day by day. Things that are too expensive to predict today can be cheap enough tomorrow. Thus unpredictable system must stay unpredictable enough also in the future, not forever but long enough in relation to value.

This is pure analogy to information security as data has always a value and if it is encrypted using algorithms that are relaying randomness (and most often are) it is only a matter of time and energy when the random event behind this encryption will be predicted and data to become public.

Randomness in operating systems

Instead of starting to create your own pseudo-random generator nearly all operating systems provide the source of pseudo-randomness.

Randomness in GNU/linux

Linux kernel maintains an entropy pool . From where data to this pool is obtained, you can start reading:

/drivers/char/random.c

There is that push_to_pool() function which is called from various locations in the kernel. I’m not going into details on this but will say that at least mouse movements and keyboard presses are used when pushing environment related true random bits into pool.

To check how much bits are available in this pool:

# This read-only file gives the available entropy. # Normally, this will be 4096 (bits), a full entropy pool. \$ cat /proc/sys/kernel/random/entropy_avail 859

Every time when the content of this entropy pool is used to derive pseudo-random data that content is removed from the pool and more content needs to be pushed back with push_to_pool() to maintain decent pool size.

External random sources

Using different software utilities Linux kernel can become aware of external hardware random bit sources and use these as a source of the entropy pool itself. This provides even better entropy in the pool and thus to create better (more unpredictable) pseudo-random data.

The case of /dev/random

Linux kernel provides you pseudo-random data derived from the content of this entropy pool. There is file called /dev/random which is not a static file but a file provided by the kernel itself. Every time you read from this file kernel will give you pseudo-random data derived from the content of its entropy pool.

# Read first 32 bytes and present as base64 encoded \$ head -c 32 /dev/random | base64 UN8ENY95SVz2rBr0KmmhuP3yffm2qd8zqbX8MQSDnYQ=

There is one nasty behavior of /dev/random ; every time entropy pool drains itself empty all read operations to /dev/random will block (io-wait) until enough data is pushed and becoming available from the entropy pool to derive more random data.

The quality (unpredictability) of pseudo-randomness is better when blocking until enough data is pushed and becoming available from the entropy pool.

The case of /dev/urandom

When lower quality (more predictable) pseudo-random data can be used there is /dev/urandom available for that purpose. Data is again derived from the content of this entropy pool but read operations to this file will not block (io-wait) when entropy pool drains itself empty. Instead kernel will create lower quality pseudo-random data to substitute better quality data derived from the content of its entropy pool. This is achieved by re-using already used bits obtained from entropy pool.

Which one to use?

Majority of web pages and blog posts I’ve read suggests to use /dev/urandom . I would say this generalization should never be made.

When the best available quality is needed /dev/random should be used always even with the cost of blocking. One example is when generating keys to be used in cryptographic algorithms .

When there is the absolute need to be non-blocking (in cryptography) even with the cost of lower quality randomness /dev/urandom can be used. But still be very careful when making the decision.

For whatever else from temporary filename creation to generating “almost unique” data blobs you can use /dev/urandom as a source but note that you should neither waste the valuable bits inside Linux’s entropy pool for tasks that doesn’t require randomness but only uniqueness.

Some versions of man page random(4) states usage limitations while some other versions effectively does not. Be on the watch of what version/from what source you are reading.

tags: random,pool,entropy,data,dev,randomness

1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责；
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性，不作出任何保证或承若；
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。