Чи можете ви пояснити оцінку ентропії, яка використовується у random.c

/dev/randomвикористовує таймінги переривань ядра для додавання до пулу ентропії. Кількість ентропії в пулі відстежується в змінній, названій entropy_count.

Ось відповідний фрагмент коду від random.c. Він відображає час (в міркуваннях, що я думаю) між останніми двома перехопленнями змінної deltaта різницею в дельтах як delta2.

delta = time - state->last_time;
state->last_time = time;

delta2 = delta - state->last_delta;
state->last_delta = delta;

if (delta < 0) delta = -delta;
if (delta2 < 0) delta2 = -delta2;
delta = MIN(delta, delta2) >> 1;
for (nbits = 0; delta; nbits++)
  delta >>= 1;

r->entropy_count += nbits;

/* Prevent overflow */
if (r->entropy_count > POOLBITS)
  r->entropy_count = POOLBITS;

Схоже, оцінка доданої ентропії по суті є підлогою (не перекриттям через початковий біт зміщення перед циклом) основи 2 логарифму дельти. Це має певний інтуїтивний сенс, хоча я не впевнений, які припущення потрібні, щоб зробити це формально правильним.

Отже, моє перше запитання - "які міркування за цією оцінкою?"

Моє друге питання - про delta = MIN(delta, delta2) .... Що це робить? Навіщо брати мінімум цієї дельти і останньої? Я не знаю, чого цього слід досягти - можливо, це робить оцінку кращою, можливо, просто більш консервативною.

Редагувати: Я знайшов документ, який визначає кошторис , але він насправді не дає аргументованого аргументу (хоча він окреслює деякі неофіційні умови, яким повинен відповідати оцінювач).

Інші ресурси, які з’явилися в коментарях:

• Вікіпедія на /dev/randomта/dev/urandom
• Документ, який намагається пояснити це (я скептично ставлюсь до цього, див коментарі)
• Публікація в блозі/dev/random з коментарями хлопця, який написав код вище.
• Відповідь secutity.SE про /dev/randomпул ентропії.

delta2- це не попереднє delta, а різниця між двома послідовними значеннями delta. Це свого роду похідна: якщо deltaвимірює швидкість, delta2це прискорення.

Інтуїтивна ідея, що стоїть за цією оцінкою, полягає в тому, що переривання відбуваються з більш-менш випадковими інтервалами, продиктованими непередбачуваними подіями з фізичного світу (наприклад, ключовими ударами або надходженням мережевих пакетів). Чим довше затримка, тим більше задіяних непередбачуваних подій. Однак є фізичні системи, які вогонь переривається з фіксованою швидкістю; delta2міра є механізм захисту , яка виявляє такі випадки (якщо переривання виникають через фіксовані проміжки часу, отже , рішуче передбачувані, все deltaматимуть таке ж значення, отже , delta2буде дорівнює нулю).

Я сказав "інтуїтивно", і сказати не багато чого. Насправді, у моделі «випадкових фізичних подій» підрахунок бітів є неправильним; якщо апаратні події трапляються з ймовірністю p для кожної одиниці часу, і ви отримуєте затримку, виражену через n біт, тоді вклад ентропії повинен обліковуватися як n / 2 біт, а не n біт. Але ми знаємо, що насправді фізичні події не відбуваються в абсолютно випадкові моменти; delta2механізм допускає стільки ж.

Тож на практиці "оцінка ентропії" саме така: оцінка . Його цінність безпеки походить не від обґрунтованого, математично точного обґрунтування, а від звичайного джерела безпеки: начебто ніхто не знайшов способу зловживати цим (поки).

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