Розмір ентропійного пулу в системі напряму впливає на те, наскільки швидко криптоалгоритми можуть отримувати якісні випадкові числа.

Відразу наведу графік.

entropy

Це якраз і є розмір ентропійного пулу на одному з моїх фізичних серверів. Я відмітив три цікаві контрольні точки.

Перша точка — це апгрейд із ядра 3.8 на ядро 3.11. Тут особових коментарів не треба, і так відомо, що останнім часом мальчіки постаралися щодо збирання ентропії з багатьох різних джерел.

Друга точка цікавіша. Недавно зарелізили збирач ентропії, оснований на джиттері таймінгів центрального процесора. Алгоритм надзвичайно простий і надійний (я навіть його спробував зробити своїми руками, щоправда, із тестів нормалізації можу чесно сказати, що моя реалізація поки ще фіговенька), докладний опис можна прочитати тут. Так от я взяв демку з цього збирача, яка годує /dev/random ентропією, зібраною із джиттера процесора. І розмір пулу виріс.

Між другою і третьою точками я прибрав із системи rng-tools, які годували /dev/random випадковими числами, узятими з /dev/urandom. Це ніфіга не секурно (як для параноїків, звісно, бо в /dev/urandom нормальні алгоритми PRNG на хешах). Видно, що це ні на що не вплинуло.

Ну і третя точка поставлена в тому місці, де я втулив haveged у систему. Ентропійний пул виріс іще більше.

Продовжую спостереження.

Після перегляду слайдів Пітера Енвіна з лінуксової конференції в Барселоні про генератори псевдовипадкових чисел в Лінуксі поставив собі rngd. І от що можу показати:

На KVM’і нерівномірність ентропії трохи вирівнялася, але суттєвих змін не сталося.

На Xen’і згладжування скачків прослідковується більш виражено, але рівень не змінився також.

А от на реальному сервері ентропія виросла разів у сім. От де профіт. Правда, разом із цим виросло на 2% навантаження на CPU.