реализация шифра Вернама
Хочу представить сообществу свою программу – реализацию шифра Вернама (одноразовый блокнот) с дополнительными функциями. Программа написана на Python и может:
- Генерировать ключи, используя функцию os.urandom()
- Шифровать и расшифровывать данные
- При шифровании добавлять в конец данных контрольную сумму (sha1) и проверять ее при расшифровании
- Сжимать данные с помощью gzip или bzip2
Контрольная сумма нужна для зашиты от подмены в случае, когда злоумышленнику известна часть ключа/сообщения. Контрольная сумма и сжатие опциональны, по умолчанию программа добавляет контрольную сумму, если использовать сжатие, то sha1 добавляться уже не будет. При необходимости можно отключить оба варианта или использовать их вместе. Прилагается документация на русском и английском.
Размер – меньше 400 (четырехсот) строк.
Лицензия – MIT.
https://github.com/anton-tsyganenko/otppy
При привильном использовании и отсутствии закладок в ОС и интерпритаторе взлом абсолютно невозможен.
комментариев: 11558 документов: 1036 редакций: 4118
/dev/urandom, напротив, не получает энтропию непосредственно из источников случайности. Это обычный генератор псевдослучайных последовательностей, периодически ресидируемый от ввода /dev/random. Таким образом, стойкость полученных из него одноразовых блокнотов будет опираться на стойкость самого генератора и используемых в его основе криптопримитивов, которые могут быть уязвимы к различным классам атак (в том числе и помянутому Вами КК). Нельзя для OTP использовать PRNG, иначе теряется весь смысл OTP. С тем же успехом можете юзать обычный блочный шифр.
Без разницы.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 11558 документов: 1036 редакций: 4118
/dev/random блокирует чтение, если в нём недостаточно энтропии. Подключайте быстрые источники энтропии (timer_entropyd, audio_entropyd, haveged), а не компрометируйте требования к генератору. Медленное поступление энтропии — проблема пользователя, а не OTP.
комментариев: 11558 документов: 1036 редакций: 4118
Есть некоторая надежда на техническую сложность — противник не всегда знает, когда сидируется urandom, и потому не знает, ключи каких процессов связаны между собой одним seed'ом, но чисто теоретически уязвимость остаётся. Например, в ситуации, когда злонамеренный процесс запущен в той же ОС, что и критичные к безопасности, это может играть роль: зная, что другие процессы черпают энтропию из urandom, зловред тоже оттуда извлекает какой-то кусок, и теперь он знает, что всё, что наполучали втечение некоторого промежутка другие процессы, покрывается одним seed'ом. В некотором смысле из-за этого получается, что один процесс может знать, какие случайные данные получил из пула другой процесс (modulo 128-битная стойкость или какой там размер seed'а?).
Кстати, есть ли возможность более частого сидирования urandom? Можно ли сделать так, чтоб urandom сидировался (осеменялся) сразу же, как только в random появляется достаточное количество энтропии, а не так как сейчас (кажется, не чаще, чем раз в несколько минут?). Или это чем-то плохо для безопасности?
комментариев: 11558 документов: 1036 редакций: 4118
велосипедRNG?типа md5("http://site1.xxx") ^ md5("http://site2.xxx") ^ ...
Во вторых, вы где собираетесь держать список сайтов? если вшить в генератор, то злоумышленник тоже сможет получить этот-же результат