Как я могу попробовать старые версии UNIX?

tl;drПул энтропии используется только во время начальной загрузки. У вас есть только одно ядро, которое предоставляет случайные числа. Имея только один пул энтропии, вы обеспечиваете более высокую степень не -детерминированного поведения из-за шаблонов использования из тюрем.

Если доверять алгоритмам, использованным в /dev/random, то наличие нескольких пулов энтропии не дает никаких преимуществ. Лучше быстрее исчерпать общий пул, а затем сгенерировать новый (reseed ).

Пользовательские программы не должны напрямую использовать пул энтропии. Они должны всегда использовать случайное (4)и друзей.

Длинная версия с кавычками:

Устройство /dev/random было реализовано с использованием реализации Yarrow между версиями 5.0 и 10.0. Во FreeBSD 10 он был изменен на Fortuna . Основное обновление было сделано в 2014 году с ревизией 273872 . Примерно в то же время на HackerNews идет небольшая дискуссия.

rc.d/initrandomудалено с комментариями:

Refactor of /dev/random device. Main points include:

• Userland seeding is no longer used. This auto-seeds at boot time on PC/Desktop setups; this may need some tweeking and intelligence from those folks setting up embedded boxes, but the work is believed to be minimal.

• An entropy cache is written to /entropy (even during installation) and the kernel uses this at next boot.

• An entropy file written to /boot/entropy can be loaded by loader(8)

Помните, что джейлхост запускает только одно ядро ​​для системы, а затем пользовательские бинарные файлы по вашему выбору в джейлах. Когда одно и то же ядро ​​​​обслуживает одни и те же тюрьмы, нам нужно спросить, является ли преимуществом изменение энтропии для каждой тюрьмы?

Это описано Xin LI в обсуждении , когда изменение было внесено в:

The way a PRNG works is that it uses one or many entropy sources to "feed" its internal state, and generate a series of pseudo-random numbers from the internal state via a PRF.

FreeBSD collects entropy from several sources: Ethernet, interrupts, software interrupts, etc., as well as hardware RNG that is available to the system, and use all these entropy to derive the internal state of its PRNG.

When reading from /dev/random, one essentially consumes entropy that is fed into the random device, and eventually it would cause a reseed. In an ideal world, we would want this to be less predicable and controllable from a potential attacker.

Normal applications tends to read /dev/random in small bites, and do so in a discrete and nearly random manner, assuming we have a lot of processes running. Saving entropy, on the other hand, happen in larger chunks at a determined time. With multiple jails running, one would have a lot of big chunk reads from the /dev/random device, making its behavior more deterministic, which could have bad consequences.