Поиск подземных стуков в поточных шифрах

[metaclass]

Потратил пару вечеров на развлечение - поиск причины, почему криптоалгоритмы в питоне, php, c, openssl и C# выдают разные результаты: http://ru-root.livejournal.com/2759003.html

В итоге, оказалось что в python, php и либе mcrypt по умолчанию используется размер обратной связи в 8 бит, в C+openssl и C#+bouncycastle - 64 бита, а если запускать openssl из командной строки - он добивает ключ нулями до размера кратного блоку.
У питоновского крипто есть такой параметр, называется segment_size.
В php параметра нет, но то, что в php и mcrypt называется OFB или CFB - это на самом деле 8OFB и 8CFB, а для 64 бита (размер блока шифра) в них есть режимы nofb и ncfb, но для ncfb в питоне НЕТ константы типа MCRYPT_MODE_NCFB, а все остальные есть.

http://stackoverflow.com/questions/4052594/incorrect-key-size-in-php-mcrypt-when-porting-cryptopp-aes-encryption-to-phps-m/4054017#4054017
https://bugs.php.net/bug.php?id=51146

Comments

[aamonster.livejournal.com]

На это дело что - стандарта нет?

[metaclass.livejournal.com]

Есть рекомендация - использовать размер блока, так вроде бы более устойчивый к взлому результат получается. Но в этом варианте плейнтекст придется добивать паддингом до кратного размера.

[berezovsky.livejournal.com]

Вот интересно, отпадёт ли надобность в защите после апокалипсиса. Между людьми это точно не надо будет, ибо исходной посылкой для создания системы было недоверие. Потом всё будет по-другому.
А вот внешняя угроза, по идее, должна остаться. Но там защита понадобится больше ментально-энергетическая, чем материальная. Галактическая Конфедерация может ослабить контроль за планетой, и надо будет выстраивать оборону своими силами. Хотя, конечно, слабо понятно, как они будут подключаться к информационным системам и зачем им это надо. Проще уже прямо в тонкие тела залезть и вести атаку оттуда.

[wizzard]

Апокалипсис включает в себя разрушение правовых систем и повышение недоверия.

[ilya-portnov.livejournal.com]

А в одном широко известном в узких кругах коммерческом программном продукте есть своя реализация 3DES (не совсем так, я упрощаю). В нём, как известно, бывают варианты: EEE и EDE. Так вот в ядре упомянутого продукта в enum-е эти константы перепутаны местами. Т.е. если передать EEE то будет сделано EDE, и наоборот. И ничо, так и живут уже много лет — просто все разработчики уже в курсе, что надо передавать не ту константу которую хочешь.

[blackyblack.livejournal.com]

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

[wizzard]

э, а зачем понадобился cfb/ofb?

я бы сказал что из полезных режимов сейчас GCM, CBC, CTR и XTS (по уменьшению кол-ва юзкейсов), а остальное носит только исследовательский характер.

[metaclass.livejournal.com]

По ссылке там какая-то сторонняя библиотека его использует.
А какая разница, какой режим превращения блокового фильтра в поточный?

[wizzard]

Эээ... о_О

Вообще говоря, от блочного режима зависит больше свойств итогового шифра, чем например от выбора между AES, Blowfish и, я не знаю, XTEA каким-нибудь, а также чем от варьирования ключа от 128 до 512 бит.

[trueblacker.livejournal.com]

это называется "вектор инициализации" (IV) или "синхропосылка". Её значение стандартизировать нельзя, она не должна повторяться.

[metaclass.livejournal.com]

Не, IV там сугубо в начале, а тут наркоманы зачем-то параметризуют количество бит, протаскиваемое на следующие этапы применения блочного шифра.

[trueblacker.livejournal.com]

о как. Поспешил отвечать, стало быть. Засмущало то, что речь то об обратной связи, то о ключе. Решил, что терминология хромает.
По-нормальному если, IV - это и есть начальное заполнение буфера обратной связи и его размер равен размеру блока.