Коли використовувати / dev / random vs / dev / urandom

Чи варто використовувати /dev/randomабо /dev/urandom?

У яких ситуаціях я віддав би перевагу одній над іншою?

TL; DR

Використовуйте /dev/urandomдля більшості практичних цілей.

Більш довга відповідь залежить від аромату Unix, який ви працюєте.

Linux

Історично /dev/randomі /dev/urandomобидва були введені одночасно.

Як @DavidSchwartz зазначив в коментарі , використовуючи /dev/urandomпереважно , в переважній більшості випадків. Він та інші також надали посилання на чудові міфи про/dev/urandom статтю, яку я рекомендую для подальшого читання.

Підсумовуючи:

• Сторінка керівництва є недостовірним
• Обидва живляться одним і тим же CSPRNG для створення випадковості ( діаграми 2 і 3 )
• /dev/random блокує, коли у нього закінчується ентропія
• Кількість ентропії оцінюється консервативно, але не враховується
• /dev/urandomніколи не заблокує, читання з /dev/randomможе зупинити виконання процесів.
• У рідкісних випадках, дуже скоро після завантаження, у CSPRNG, можливо, не було достатньої ентропії для належного висіву і, можливо, не було випущено/dev/urandom високоякісних випадковостей.
• Ентропія, що працює на низькому рівні, не є проблемою, якщо CSPRNG спочатку було засіяно належним чином
• CSPRNG постійно відновлюється
• В Linux 4.8 і далі /dev/urandomне /dev/randomвичерпує пул ентропії (використовуваний ), але використовує вихід CSPRNG з висхідного потоку.
• Використовуйте /dev/urandom.

Винятки з правила

У Cryptography Stack біржі Коли використовувати /dev/randomбільш /dev/urandomв Linux @otus дає два варіанти використання :

1. Незабаром після завантаження на пристрій низької ентропії, якщо достатньо ентропії ще не був сформований правильно насіння /dev/urandom.

2. Створення одноразового майданчика з інформаційно-теоретичною безпекою

Якщо ви переживаєте (1), ви можете перевірити наявну в ньому ентропію/dev/random .

Якщо ви робите (2), ви це вже будете знати :)

Примітка: Ви можете перевірити, чи не блокується читання з / dev / random , але остерігайтеся можливих умов гонки.

Альтернатива: не використовуйте жодного!

@otus також зазначив, що getrandom()система буде читати /dev/urandomі блокуватиме лише, якщо початкова ентропія насіння не доступна.

Існують проблеми із зміною /dev/urandomвикористанняgetrandom() , але можливо, що новий /dev/xrandomпристрій буде створений на основі getrandom().

macOS

Це не має значення, як говорить Вікіпедія :

macOS використовує 160-бітний Yarrow на основі SHA1. Немає різниці між / dev / random та / dev / urandom; обидва поводяться однаково. Apple iOS також використовує Yarrow.

FreeBSD

Це не має значення, як говорить Вікіпедія :

/dev/urandomє лише посиланням на /dev/randomта блокує лише до належного засіву.

Це означає, що після завантаження FreeBSD розумно чекати, поки не буде зібрано достатньо ентропії насіння, перш ніж доставити нескінченний потік випадкової користі.

NetBSD

Використовуйте /dev/urandom, якщо припустити, що ваша система хоча б раз прочитала інформацію, /dev/randomщоб забезпечити належне початкове посів.

Сторінка rnd (4) говорить :

/dev/urandom Ніколи не блокує.

/dev/randomІноді блоки. Заблокується рано під час завантаження, якщо відомо, що стан системи передбачуваний.

Програми повинні читати з / dev / urandom, коли їм потрібні випадково генеровані дані, наприклад, криптографічні ключі або насіння для моделювання.

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

Традиційно, єдина відмінність між /dev/urandomі /dev/randomто , що відбувається , коли ядро думає , що немає ніякої ентропії в системі - /dev/randomНЕ може закрито, /dev/urandomНЕ може відкрито. Обидва водії були ентропії пошук з add_disk_randomness(), add_interrupt_randomness()і add_input_randomness(). Дивіться /drivers/char/random.cдеталі.

Відредаговано, щоб додати: Станом на Linux 4.8 /dev/urandomбуло перероблено для використання CSPRNG.

Тож коли вам не вдасться закритись? Для будь-якого виду криптографічного використання, зокрема для посіву DRBG. Існує дуже хороший документ, що пояснює наслідки використання /dev/urandomпід час генерації ключів RSA та недостатньої ентропії. Читайте майнінг ваших психологічних питань .

Це дещо відповідь "я теж", але це посилює рекомендацію Тома Хейла. Це прямо стосується Linux.

• Використовуйте /dev/urandom
• Не використовуйте /dev/random

За словами Теодора Цьо у списку розсилки криптовалют Linux Kernel, /dev/randomйого застаріли протягом десятиліття. Від Re: [RFC PATCH v12 3/4] Генератор випадкових чисел Linux :

Практично ніхто не використовує / dev / random. Це по суті застарілий інтерфейс; первинними інтерфейсами, які рекомендувались більше десятиліття, є / dev / urandom, а тепер, getrandom (2).

Ми регулярно тестуємо, /dev/randomі це зазнає частих збоїв. Тест виконує три етапи: (1) злив /dev/random, запитуючи 10 К байт у режимі, що не блокує; (2) запит 16 байт у режимі блокування (3) спроба стиснути блок, щоб перевірити, чи є його випадковістю (тест бідолахи). Тест займає хвилин.

Проблема настільки погана в системах Debain (i686, x86_64, ARM та MIPS), що ми попросили GCC Compile Farm встановити rng-toolsпакет для своїх тестових машин. З Інсталювати rng-інструменти на gcc67 та gcc68 :

Я хотів би попросити встановити rng-інструменти на gcc67 та gcc68. Вони є системами Debian, і / dev / random зазнає збіднення ентропії без rng-інструментів при тестуванні бібліотек, які використовують пристрій.

BSD і OS X здаються нормально. Проблема, безумовно, Linux.

Можливо також варто згадати, що Linux не реєструє збої генератора. Вони не хотіли, щоб записи заповнювали системний журнал. На сьогоднішній день більшість збоїв замовчуються і залишаються невизначеними більшістю користувачів.

Ситуація повинна змінитися незабаром, оскільки ядро ​​збирається надрукувати принаймні одне повідомлення про помилку. З [PATCH] випадково: попередження компілятора тиші та виправлення гонки у списку розсилки криптовалют ядра:

Зокрема, я додав depends on DEBUG_KERNEL. Це означає, що ці корисні попередження підкажуть лише інших розробників ядра. Це, мабуть, саме те, що ми хочемо. Якщо різні асоційовані розробники побачать попередження, що надходить від конкретної їх підсистеми, вони будуть більш вмотивованими виправити це. Звичайні користувачі в ядрах дистрибуції взагалі не повинні бачити попередження або спам, оскільки зазвичай користувачі не використовують DEBUG_KERNEL.

Я думаю, що погана ідея придушувати всі повідомлення з точки зору інженерії безпеки.

Багато людей не мають ядер налагодження. Більшість користувачів, які хочуть або потребують знати про проблеми, не усвідомлюють, що це відбувається. Подумайте, причина, про яку ми дізналися про проблеми systemd, була пов’язана з dmesg.

Придушення всіх повідомлень для всіх конфігурацій надає більш широку мережу, ніж потрібно. Конфігурації, які потенційно можуть бути виявлені та виправлені, залишаться непоміченими. Якщо проблема не з'ясується, вона не буде виправлена.

Я відчуваю, що ядро ​​приймає політичні рішення для деяких організацій. Для тих, хто має апаратне забезпечення, яке фактично не можна виправити, організація повинна вирішити, що робити, виходячи зі своєї небезпеки. Вони можуть вирішити жити з ризиком або вирішити оновити обладнання. Однак, не маючи інформації про це питання, вони можуть навіть не усвідомити, що вони є предметом, який підлягає дії.

Компроміс, зрештою досягнутий пізніше в потоці, був принаймні одним dmesg на викликовий модуль.