Кстати, так называемые «TRNG» — тоже на самом деле PRNG. Так что можешь просто выкинуть свой компьютер =).

Поправка: в лабораторных условиях можно построить генератор именно случайных чисел, с определённой погрешностью, и со скоростью больной улитки. Но, учитывая технологические ограничения, я бы доверял PRNG больше.

Это зависит от куда ты берёшь случайные числа для /dev/random в своей системе!

rng-tools video_entropyd

Веришь, нет, код для /dev/(u)random не зависит от того, где ты берёшь энтропию. И он является CS PRNG.

Кстати, так называемые «TRNG» — тоже на самом деле PRNG. Так что можешь просто выкинуть свой компьютер =).

Поправка: в лабораторных условиях можно построить генератор именно случайных чисел, с определённой погрешностью, и со скоростью больной улитки. Но, учитывая технологические ограничения, я бы доверял PRNG больше.

Выкинь свои методички и не верь больше людям которые тебе их дали!

Сегодня каждый может дома получить с доступного USB устройства десятки мегабит в секунду КРИПТОГРАФИЧЕСКИ НАДЁЖНОЙ энтропии с квантовых источников, гарантирующих её качество!!! Можешь тестить её качество...

Ты думаешь, что внутри этого устройства нет PRNG?

О каком коде идёт речь?

Пойми в /dev/random могут писать кучу разных сервисов!!! Ядро Linux может писать свои псевдо случайные числа, сервисы clrng и timer_entropyd свои из тех же источников - системных таймеров.

Но в /dev/random может также писать сервис rng-tools который запишет TRNG с аппаратных ГСЧ которые их берут с АБСОЛЮТНО случайных физических квантовых процессов.

Пойми в /dev/random могут писать кучу разных сервисов

Ты думаешь, что то, что ты туда запишешь, ты оттуда и прочитаешь? Всё, что ты запишешь в /dev/random проходит через PRNG, и читаешь ты в любом случае именно из него.

аппаратных ГСЧ которые их берут с АБСОЛЮТНО случайных физических квантовых процессов.

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

Подсказка 2: Нет никакого надёжного способа посчитать энтропию — её можно только прикинуть.

Тут-то нас и спасает то, что мы все источники энтропии прогоняем через PRNG.

Внутри аппаратного ГСЧ есть АЦП которое преобразует в числовое выражение некую характеристику АБСОЛЮТНО СЛУЧАЙНОГО физического квантового процесса: интервала времени между распадами ядер, амплитуды некого импульса, ... Драйвер тупо пишет результат с АЦП в /dev/random. Никаких PRNG и преобразований не производится, полученное случайное число не используется в качестве сидов для PRNG, а записывается НАПРЯМУЮ.

Ты думаешь так: http://www.2uo.de/myths-about-urandom/structure-no.png

На самом деле так: http://www.2uo.de/myths-about-urandom/structure-yes.png

Нет, это так не работает. Тогда у тебя сигнал бы не проходил даже тривиальные проверки, он бы был сдвинут, и его характеристики бы менялись, допустим, в зависимости от температуры окружающей среды или уровня э/м шума.

Ещё раз: когда ты читаешь из /dev/(u)random, ты читаешь из PRNG. Всегда. Независимо от того, как перед этим ты накормил его энтропией, из каких источников ты взял числа которые отдавал в /dev/(u)random и т.д.

Не уважение к Ъ?

Ты сказал PRNG, /dev/urandom являются криптографически надёжными!

Я не согласен!!! И утверждаю что ты умышленно или по незнанию вводишь людей в заблуждение.

Там картинки со схемами. Посмотри на неправильную (то, как думаешь ты) и правильную (то, как всё на самом деле).

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

И да, вопрос на засыпку.

Ты правда думаешь, что эти два утверждения одновременно верны:

1. Фиксированного количества энтропии недостаточно, чтобы давать нам криптостойкую последовательность чисел неограниченного размера (твоё утверждение).
2. Ключа размером 256 бит достаточно, чтобы подписывать и шифровать последовательность данных неограниченного размера.

[ссылка на презентацию, подготовленную инвалидами умственного труда]

Спасибо, поржал.

CONFIG_PAX_LATENT_ENTROPY - Note that entropy extracted this way is not cryptographically secure!

Мимо.

Смени дилера! У нормальных в /dev/random та энтропия на выходе что дал на входе.

Мимо.

В точку:

Практично у меня /dev/random стандартный с ядра Linux + clrng + timer_entropyd + CONFIG_PAX_LATENT_ENTROPY — при отсутствии нагрузки на компьютер не проходят тестов, иногда даже самых простых рекомендованных АНБ!

Ситуацию справляет вебкамера с video_entropyd.

Именно по этому и поднял здесь тему! Чем и как генерить энтропию?

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

Генераторы псевдослучайных чисел крайне не желательно использовать для этих целей. Только источники дающие TRNG и то предварительно запуская проверки (а в друг последовательность случайно окажется периодичная).

Фиксированного количества энтропии недостаточно, чтобы давать нам криптостойкую последовательность чисел неограниченного размера (твоё утверждение).

Я больше доверяю Богу и его законам квантовой механики и то говорю что последовательности TRNG перед применением стоит проверить. А ты спрашиваешь верю ли я математикам которые сами не имеют надёжных методов оценки энтропии.

Ключа размером 256 бит достаточно, чтобы подписывать и шифровать последовательность данных неограниченного размера.

Люди не верят программистам и математикам. Они предпочитают периодически менять ключи. И чем слабее ключ тем чаще стоит его менять! Некоторые алгоритмы вообще имеют, в дизайне, ограничение на количество зашифрованных одним ключом данных...

Именно по этому и поднял здесь тему! Чем и как генерить энтропию?

Видимо, все-таки audio-entropyd, на на вход нужно подать белый шум от какого-то шумящего электронного устройства - диода, стабилитрона, транзистора... Надо поискать что-то подходящее и простое.

Ох. Ну давай тогда мыслить последовательно.

Вот у тебя есть источник энтропии в виде каких-то данных. Вот эти данные попадают в алгоритм, который тебе генерирует /dev/random. Что, по твоему, мы получим на выходе /dev/random? Те же данные, которые подали ему на вход? Другие данные? Если другие — как они будут связаны с данными, поданными на вход?

Я больше доверяю Богу

А, не. Забей.

Видимо, все-таки audio-entropyd, на на вход нужно подать белый шум от какого-то шумящего электронного устройства - диода, стабилитрона, транзистора... Надо поискать что-то подходящее и простое.

audio-entropyd - у меня не проходит тестов. Шум от куллеров компа видать плохой.

video-entropyd - с вебкамеры очень хорошею энтропию даёт!!!

Шум от куллеров компа видать плохой.

Он действительно плохой. Нужен хороший шум от стабилитрона, например.

А я пускаю кота по клавиатуре прогуляться. Мне норм.

video_entropyd

Кому нужен лишний шум?

video_entropyd + вебкамера = лучшие решение из того что есть дома!

Скорее наоборот.

примитивный тест зависимости доступной в системе энтропии от времени.

cat /proc/sys/kernel/random/*; for i in {1..100}; do sleep 10; cat /proc/sys/kernel/random/entropy_avail; done

Если за 100 - удовлетворительно, за 1000 - хорошо.