Чому запис у / dev / random не робить паралельне читання з / dev / random швидшим?

Зазвичай при зчитуванні /dev/randomвиробляється 100-500 байт і блоків, очікуючи збирання ентропії.

Чому записування інформації /dev/randomіншими процесами не прискорює читання? Чи не повинна вона забезпечити необхідну ентропію?

Це може бути корисним для розблокування gpgчи подібного програмного забезпечення без його перезавантаження та повторного введення всього, для створення не надто-надто секретних ключів тощо.

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

Мені потрібен той самий функціонал для тестування моєї програми налаштування смарт-карт , оскільки я не хотів чекати, коли моя миша / клавіатура генерує достатньо для кількох дзвінків, gpgякі були зроблені для кожного тестового запуску. Що я зробив, це запустити програму Python, яка випливає, паралельно з моїми тестами. Звичайно, його взагалі не слід використовувати для створення справжнього gpgключа, оскільки випадкова рядок взагалі не є випадковою (система, генерована випадковою інформацією, все ще буде переплетена). Якщо у вас є зовнішнє джерело, для якого слід встановити рядок random, ви повинні мати високу ентропію. Ви можете перевірити ентропію за допомогою:

cat /proc/sys/kernel/random/entropy_avail

Програма:

#!/usr/bin/env python
# For testing purposes only 
# DO NOT USE THIS, THIS DOES NOT PROVIDE ENTROPY TO /dev/random, JUST BYTES

import fcntl
import time
import struct

RNDADDENTROPY=0x40085203

while True:
    random = "3420348024823049823-984230942049832423l4j2l42j"
    t = struct.pack("ii32s", 8, 32, random)
    with open("/dev/random", mode='wb') as fp:
        # as fp has a method fileno(), you can pass it to ioctl
        res = fcntl.ioctl(fp, RNDADDENTROPY, t)
    time.sleep(0.001)

(Не забудьте вбити програму після того, як ви закінчите.)

Як правило, він розроблений розробниками ядра та задокументований у man 4 random:

Writing to /dev/random or /dev/urandom will update the entropy pool
with the data written, but this will not result in a higher entropy
count.  This means that it will impact the contents read from both
files, but it will not make reads from /dev/random faster.

Ентоні вже пояснив, що написання /dev/randomне збільшує кількість ентропії та показав, як йоктл RNDADDENTROPY (див. Випадковий (4) ) може бути використаний для кредитування ентропії. Це, очевидно, не дуже безпечно, тому тут є альтернатива, коли є апаратний генератор випадкових чисел.

Наступні реалізації беруть 512 байт (4096 біт) випадковості /dev/hwrngі пересилають її в пул ентропії (зараховуючи 4 біти ентропії на байт, це від мене довільний вибір). Після цього він викличе системний виклик select (2) для блокування, коли пул ентропії заповнений (задокументовано у випадковій (4) сторінці ).

Версія Python:

import fcntl, select, struct
with open('/dev/hwrng', 'rb') as hw, open('/dev/random') as rnd:
    while True:
        d = hw.read(512)
        fcntl.ioctl(rnd, 0x40085203, struct.pack('ii', 4 * len(d), len(d)) + d)
        select.select([], [rnd], [])

Оскільки в Arch Linux iso не встановлено Python, ось і версія Perl:

open my $hw, "</dev/hwrng" and open my $rnd, "</dev/random" or die;
for (;;) {
    my $l = read $hw, my $d, 512;
    ioctl $rnd, 0x40085203, pack("ii", 4 * $l, $l) . $d or die;
    vec(my $w, fileno $rnd, 1) = 1;
    select undef, $w, undef, undef
}

Мабуть, це робить програма rngd (частина rng-інструментів ) (неперевірена), за винятком того, що вона використовує інструменти (Python або Perl), які вже є загальнодоступними.