Аппаратные ГСЧ в ЦПУ от Intel

Так киньте ссылку на статьи, где это обсуждается, а мы почитаем, спасибо скажем.

P.S. И при чём тут период? В варианте с шифрованным счётчиком он тоже не обязан быть. Такое впечатление, что некоторые рассуждают так: нет периода ⇒ ГСЧ безопасен. Другие идут ещё дальше: нет периода в генерации гаммы для одноразового блокнота ⇒ шифр безопасен. У последовательности, не имеющей периода, всё равно могут быть легко детектируемые отклонения от случайного распределения, здесь же пытались придумать такую закладку, чтобы она была незаметной по статистике (а наличие периода — это совсем провал и предельный случай).

FreeBSD abandoning hardware randomness.

Вроде бы, решение команды FreeBSD не соответствует тому, что описано в статье по ссылке. Они просто решили не подавать выход с аппаратных генераторов энтропии напрямую в /dev/random, а прокручивать через сборщик системной энтропии в качестве одного из источников. Опять же, Линус Торвальдс принял такое же решение, для Linux соответственно.

А что, раньше они так делали?! Хардварный пул не смешивался с той энтропией, что набирается софтварно? В Linux вроде всегда смешивалась.

«Hardware randomness» — не очень удачный термин, думаю. Есть ли чисто программная рандомность? BBS какой-нибудь если только? Остальное всё равно сводится к чему-то хардварному, просто в «TRNG» случайность черпается с самого нижнего уровня, а в программных RNG та же случайность собирается из её влияния на программные вещи более высокого уровня.

Возможно, в BSD так и не делали, но просто собирались рассмотреть такой вариант.

Торвальдс жаловался, что инженеры Intel предлагали ему замещать энтропию в пуле при определении их ГСЧ, а не подмешивать в качестве одного из входов.

В принципе, если отбросить вероятность злого умысла, в этом есть и рациональное зерно: на примере HAVEGE, если снимать с него энтропию напрямую, то скорость будет 200 MB/s; если собирать её и пропускать через /dev/random и снимать уже оттуда (как делает демон haveged), то скорость на этой же системе будет 4 MB/s. Вопрос об оценках качества этой энтропии пока не рассматриваем, но то, что /dev/random сильно тормозной за счёт постобработки — очевидно.

Если бы HW-TRNG можно было считать идеальным и доверяемым, то постобработка ему была бы не нужна — она и так в него встроена, вместе с тестами и проверками на сбои. А внешняя софтварная постобаботка, реализованная в /dev/random, сильно тормозит его работу (почти на два порядка).

Нельзя доверять одному источнику энтропии, каким бы он ни был. Просто нужно придумать быструю и программную постобработку.

Совершенно верно.

Но, помимо всех своих прочих недостатков, существующие реализации /dev/random не были рассчитаны на сбор больших количеств энтропии с быстрых источников, поэтому скорость работы на такой случай в них никак не была оптимизирована.

/comment70439


Вспомнилось, что разработчики QRNG на это тоже жаловались (на скорость /dev/random):

у них такая возможность не поддерживается из-за того, что есть какое-то узкое место, не позволяющее увеличить скорость на одного клиента (то ли системная программная фича, то ли хардварные особенности, так до конца и не понял).

А жёлтая пресса уже пишет: "В FreeBSD 10 аппаратные ГСЧ RDRAND и Padlock использоваться не будут".

Да, заголовок откровенно жёлтый, хотя внутри всё же правильно расписано:

Мы намерены использовать их в генераторе псевдослучайных чисел Yarrow, вместо того, чтобы направлять сгенерированные ими числа непосредственно в /dev/random.

В новостях и рассылке недавно было, но тут прошло незамеченым:

Tor 0.2.4.20 is out

The first update to the new stable branch of Tor has been released on December 23rd. It fixes an issue that would create more preemptive circuits than actually need, and a security issue related to poor random number generation.

The latter affects “users who

1. use OpenSSL 1.0.0 or later
2. set ‘HardwareAccel 1’ in their torrc file
3. have ‘Sandy Bridge’ or ‘Ivy Bridge’ Intel processors, and
4. have no state file in their DataDirectory (as would happen on first start).

Users who generated relay or hidden service identity keys in such a situation should discard them and generate new ones.”

Всё настолько серьёзно? Непонятно, это касается всех, у кого выполнен хотя бы один из перечисленных пунктов, или требуется выполнение всех из них вместе? Звучит так, как будто у всех с означенными Intel-процессорами можно постфактум расшифровать трафик из-за слабого RNG.

Do not allow OpenSSL engines to replace the PRNG, even when HardwareAccel is set. The only default builtin PRNG engine uses the Intel RDRAND instruction to replace the entire PRNG, and ignores all attempts to seed it with more entropy. That's cryptographically stupid: the right response to a new alleged entropy source is never to discard all previously used entropy sources.

OpenSSL целиком полагался на интеловский RDRAND и блокировал подмешивание свежей энтропии? Tor целиком черпал энтропию только из одного АНБ-источника под названием «Intel ГСЧ»?!

В последних downloads стоит версия 3.5 для TBB, в ней в Docs/ChangeLog.txt написано, что

Tor Browser Bundle 3.5 — Dec 17 2013

• All Platforms
  • Update Tor to 0.2.4.19

Это что получается, текущая версия stable-связки не имеет защиты от вышеуказанной дыры с RNG?

Непонятно, это касается всех, у кого выполнен хотя бы один из перечисленных пунктов, или требуется выполнение всех из них вместе?

Второе.

OpenSSL целиком полагался на интеловский RDRAND и блокировал подмешивание свежей энтропии?

Могу ошибаться, но проблема вроде бы не в OpenSSL, а конкретно в Tor и в том, как он использовал RDRAND при его наличии.

Опция

set ‘HardwareAccel 1’ in their torrc file

вроде бы не включена в стандартном TBB по умолчанию, поэтому, получается, всех, кто сидел на стандартных сборках, это не касается безотносительно выполнения всех остальных условий.

Для клиентов эта опция бессмысленна, вычислительная нагрузка от криптоопераций по сравнению с релеями у них ничтожна.

Ну, вдруг кто-то держит высоконагруженный HS у себя дома, будучи всего лишь Tor-клиентом. :)