реализация шифра Вернама

/dev/random накапливает "чистую" энтропию от физических источников случайности, имеющихся в конкретной системе (от традиционных, типа тайминга нажатия клавиш, дельт перемещений мыши, задержек чтения с HDD из-за турбулентных процессов, и до более специфических, типа аппаратных ГСЧ в интеловских процессорах), иными словами, это генератор случайных чисел (ГСЧ) в общепринятом понимании, который только и может использоваться для выработки одноразовых блокнотов, поскольку в этом случае их стойкость является безусловной.

/dev/urandom, напротив, не получает энтропию непосредственно из источников случайности. Это обычный генератор псевдослучайных последовательностей, периодически ресидируемый от ввода /dev/random. Таким образом, стойкость полученных из него одноразовых блокнотов будет опираться на стойкость самого генератора и используемых в его основе криптопримитивов, которые могут быть уязвимы к различным классам атак (в том числе и помянутому Вами КК). Нельзя для OTP использовать PRNG, иначе теряется весь смысл OTP. С тем же успехом можете юзать обычный блочный шифр.


Без разницы.

Хорошо, попробую заменить /dev/urandom на /dev/random, только как быть с виндой?

С виндой лучше не быть никак, но используйте там хотя бы Crypto.Random (Fortuna RNG) из pycrypto.

Все-таки тыква получается, попытался сделать генератор, использующий /dev/random, так он несколько минут 100 байт генерировал. На такое заменять не получится.

/dev/random блокирует чтение, если в нём недостаточно энтропии. Подключайте быстрые источники энтропии (timer_entropyd, audio_entropyd, haveged), а не компрометируйте требования к генератору. Медленное поступление энтропии — проблема пользователя, а не OTP.

Хотел бы уточнить, я правильно понимаю, что нужен Криптографически стойкий генератор псевдослучайных чисел

Нет, нужен генератор истинно случайных чисел. Ничего "псевдо" для OTP не годится.

Вообще, по поводу использования urandom вместо random есть естественно возникающие вопросы: раз всё разворачивается с одного seed'а, значит, если я сгенерил несколько ключей для шифрования, не надо брутфорсить их по отдельности — вместо этого достаточно брутфорсить seed. Затем, если противник получил кусок трафика разных типов и знает, что в этот же момент я генерировал ключи, то ему, опять же, не надо по отдельности ломать всё из перечисленных (шифрование ssh, tor, LUKS) — вместо этого достаточно брутфорсить всё тот же единственный seed, который был использованы в данный момент.

Есть некоторая надежда на техническую сложность — противник не всегда знает, когда сидируется urandom, и потому не знает, ключи каких процессов связаны между собой одним seed'ом, но чисто теоретически уязвимость остаётся. Например, в ситуации, когда злонамеренный процесс запущен в той же ОС, что и критичные к безопасности, это может играть роль: зная, что другие процессы черпают энтропию из urandom, зловред тоже оттуда извлекает какой-то кусок, и теперь он знает, что всё, что наполучали втечение некоторого промежутка другие процессы, покрывается одним seed'ом. В некотором смысле из-за этого получается, что один процесс может знать, какие случайные данные получил из пула другой процесс (modulo 128-битная стойкость или какой там размер seed'а?).

Кстати, есть ли возможность более частого сидирования urandom? Можно ли сделать так, чтоб urandom сидировался (осеменялся) сразу же, как только в random появляется достаточное количество энтропии, а не так как сейчас (кажется, не чаще, чем раз в несколько минут?). Или это чем-то плохо для безопасности?

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

Вы начинаете изобретать RNG, это дурной знак. :)

Почему же сразу дурной знак? Если /dev/random слишком медленный, /dev/urandom не годится, а аппаратный ГСЧ на основе радиоактивного распада есть не у всех, то почему бы не изобрести велосипед RNG?

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

типа md5("http://site1.xxx") ^ md5("http://site2.xxx") ^ ...

facepalm.jpg

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

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