Аппаратные ГСЧ в ЦПУ от Intel
Судя по white papers (веб и pdf, 457Kb) в 3-ем поколении ЦПУ i5 и i7 реализованы аппаратные ГСЧ/ГПСЧ соответствующие криптографическим критериям, расширенно множество инструкций – Intel Secure Key(codenamed Bull Mountain).
Так же приведен пример про простоту и легкость прикручивания их к OpenSSL с последующими кое-какими тестами производительности.
Есть уже у кого-нибудь опыт практического использования?
Так киньте ссылку на статьи, где это обсуждается, а мы почитаем, спасибо скажем.
комментариев: 9796 документов: 488 редакций: 5664
Вроде бы, решение команды FreeBSD не соответствует тому, что описано в статье по ссылке. Они просто решили не подавать выход с аппаратных генераторов энтропии напрямую в /dev/random, а прокручивать через сборщик системной энтропии в качестве одного из источников. Опять же, Линус Торвальдс принял такое же решение, для Linux соответственно.
А что, раньше они так делали?! Хардварный пул не смешивался с той энтропией, что набирается софтварно? В Linux вроде всегда смешивалась.
«Hardware randomness» — не очень удачный термин, думаю. Есть ли чисто программная рандомность? BBS какой-нибудь если только? Остальное всё равно сводится к чему-то хардварному, просто в «TRNG» случайность черпается с самого нижнего уровня, а в программных RNG та же случайность собирается из её влияния на программные вещи более высокого уровня.
комментариев: 9796 документов: 488 редакций: 5664
Возможно, в BSD так и не делали, но просто собирались рассмотреть такой вариант.
Торвальдс жаловался, что инженеры Intel предлагали ему замещать энтропию в пуле при определении их ГСЧ, а не подмешивать в качестве одного из входов.
В принципе, если отбросить вероятность злого умысла, в этом есть и рациональное зерно: на примере HAVEGE, если снимать с него энтропию напрямую, то скорость будет 200 MB/s; если собирать её и пропускать через /dev/random и снимать уже оттуда (как делает демон haveged), то скорость на этой же системе будет 4 MB/s. Вопрос об оценках качества этой энтропии пока не рассматриваем, но то, что /dev/random сильно тормозной за счёт постобработки — очевидно.
Если бы HW-TRNG можно было считать идеальным и доверяемым, то постобработка ему была бы не нужна — она и так в него встроена, вместе с тестами и проверками на сбои. А внешняя софтварная постобаботка, реализованная в /dev/random, сильно тормозит его работу (почти на два порядка).
комментариев: 9796 документов: 488 редакций: 5664
Совершенно верно.
Но, помимо всех своих прочих недостатков, существующие реализации /dev/random не были рассчитаны на сбор больших количеств энтропии с быстрых источников, поэтому скорость работы на такой случай в них никак не была оптимизирована.
/comment70439
Вспомнилось, что разработчики QRNG на это тоже жаловались (на скорость /dev/random):
комментариев: 11558 документов: 1036 редакций: 4118
Всё настолько серьёзно? Непонятно, это касается всех, у кого выполнен хотя бы один из перечисленных пунктов, или требуется выполнение всех из них вместе? Звучит так, как будто у всех с означенными Intel-процессорами можно постфактум расшифровать трафик из-за слабого RNG.
OpenSSL целиком полагался на интеловский RDRAND и блокировал подмешивание свежей энтропии? Tor целиком черпал энтропию только из одного АНБ-источника под названием «Intel ГСЧ»?!
В последних downloads стоит версия 3.5 для TBB, в ней в Docs/ChangeLog.txt написано, что
Это что получается, текущая версия stable-связки не имеет защиты от вышеуказанной дыры с RNG?
комментариев: 11558 документов: 1036 редакций: 4118
Второе.
Могу ошибаться, но проблема вроде бы не в OpenSSL, а конкретно в Tor и в том, как он использовал RDRAND при его наличии.
Опция
вроде бы не включена в стандартном TBB по умолчанию, поэтому, получается, всех, кто сидел на стандартных сборках, это не касается безотносительно выполнения всех остальных условий.
комментариев: 11558 документов: 1036 редакций: 4118
Ну, вдруг кто-то держит высоконагруженный HS у себя дома, будучи всего лишь Tor-клиентом. :)