On 2018-11-05 22:46:37 +0300, Andrey Savchenko wrote:

 > Дальше, по поводу тестов, которые havaged проходит, в статье
 > по ссылке выше это тоже написано: не существует тестов на
 > случайность чисел, существуют тесты на неслучайность. И
 > обмануть конкретный набор тестов не сложно. Авторы Intel RNG это
 > успешно сделали. Если кто не в теме, в более-менее современных
 > процессорах Intel есть аппаратный генератор случайных чисел,
 > который успешно проходил все тесты (на неслучайность, т.е. тесты
 > не выявляли наличия закономерностей), тем не менее, генератор
 > оказался уязвимым и, судя по всему, намеренно, как нам поведал
 > тов. Сноуден.

Намеренно - очень дорого и в 99.(9)% случаев бесполезно. Намного
вероятнее ситуация, когда попросту сделали "на отцепись", лишь бы
тесты проходил.

Я уже упоминал ChaosKey (CONFIG_USB_CHAOSKEY) и то, что пользуюсь
самопайным аналогом на AVR, но у меня практически никто особо не
интересовался, что же мне помешало банально повторить полностью
открытое решение (оно вполне кошерное: COSHER == Completely Open
Source, Hardware, Engineering and Research). Причина этого - вот:
https://altusmetrum.org/ChaosKey/v1.0/noise-source.svg (точнее,
https://assets.nexperia.com/documents/data-sheet/PMBT3904VS.pdf)
- ну не шумят транзисторы так, как стабилитроны. И пофигу, что
стабилитрону нужен LM393 или аналог (сдвоенный ОУ; половину его
пользуем как собственно усилитель, половину как компаратор): мне
нужен надежный источник энтропии.

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

К нашему большому счастью, add_device_randomness() в ядре писали
умные люди, и написали грамотно: все полученные биты энтропии
примешиваются в пул с использованием криптографически устойчивой
хеш-функции. Сейчас это SHA2-256, но drivers/char/random.c можно
поправить в любой момент, и при этом гарантированно ничего не
сломается.

Поэтому проблемы с процессорным CONFIG_HW_RANDOM_* могут вылезти
только когда это единственный источник энтропии в системе - что
очевидным образом не соответствует действительности.

 >>> Реальная проблема в том, что на обсуждаемом этапе загрузки
 >>> random ещё не нужен, но используется. Очередная глупость от
 >>> systemd.

И сам по себе systemd не нужен (вообще), но используется. Да,
очередная глупость от RH, но, как некогда сказал незабвенный
Б. Титомир, "быдло хавает".

 >> Вот с этим кто бы спорил! Только боюсь, масштаб проблемы
 >> неизвестен, он может не ограничиваться systemd.

Известен. Не ограничивается. Активно эксплуатируется (SSH оно
накрывает в полный рост). Но всем ээээ... как обычно.

 >> И главное, требуется время на ловлю блох, хотя если быстрее
 >> и проще вкорячить haveged, то "не будет у нас ничего более
 >> постоянного, чем временное"!
 > Вкорячим. А потом через пару-тройку лет будет разгромный
 > позор по наличию в Альте и только Альте уязвимости из-за
 > ненадёжного источника энтропии для криптозадач.

Будет. Причем и разгромный позор, и позорный разгром.

Это только RH может отказываться от надежной криптозащиты по
"рекомендациям" одного из давних "спонсоров" и при этом почти
не рисковать репутацией.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net