Переписка и передача данных с закрытым ключем

во избежании успеха криптоанализа?

Пожалуй да, только это скорее из категории "безопасность через неясность".

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

Rar с паролем? Gpg с паролем? Или gpg с импортированным приватным ключом? Почти все программы позволяют делать то, что вы хотите.

Почти все программы позволяют делать то, что вы хотите.

Только смысл?

Небольшое уточнение в употреблении терминов: не закрытый ключ (это слово уже занято термином "пара асимметричных ключей – открытый/закрытый)", а симметричный ключ.

Теперь: стороны имеют общий симметричный ключ, имеет ли им смысл вырабатывать для каждого нового сеанса связи новый ключ?

С одной стороны это не так уж обязательно. Если объём сообщений небольшой (а для современных шифров со 128-битным блоком он всегда фактически небольшой), можно менять только вектор инициализации в режиме шифрования. Вектор инициализации передаётся открыто, во избежание его подмены сообщение нужно аутентифицировать другим симметричным ключом с помощью симметричной аутентификации (например HMAC).

Но вот какую полезную вещь можно получить, вырабатывая каждый раз новый ключ.

Пусть у нас есть ключ K₀. с помощью функции получения новых ключей (Key Derivation Function) стороны могут вырабатывать K₁ = KDF(K₀), K_n = KDF(K_n-1), и т.д., а все предыдущие ключи после прочтения сообщения уничтожать вместе с прочитанным сообщением. Это даст протоколу почти всегда полезное свойство PFS (Perfect Forward Secrecy) – при захвате системы противник может прочитать только последующие сообщения, но не сможет получить ключи для расшифровки записанного им ранее зашифрованного трафика.

Возможность режима KDF встроена в новую хэш-функцию Skein.

Использовать для этой цели обычные хэш-функции в чистом виде не рекоммендуется или на их основе нужно применять отдельный протокол KDF.

Теперь: стороны имеют общий симметричный ключ, имеет ли им смысл вырабатывать для каждого нового сеанса связи новый ключ?

unknown, вы бы лучше сказали ответ с точки зрения именно криптоанализа, т.е. допускается, что шифр вдруг стал уязвимым – чем здесь поможет указанная выше смена ключа, шифруемого предыдущим? В идеальной модели, если "вдруг один из ключей стал известен противнику", то вскрывается вся последующая цепочка (но не предыдущая). Если же взломан алгоритм, то вскрывается и последующая и предыдущая (т.е. все сообщения полностью). Потому, попытку в текущих алгоритмах передавать новый ключ, шифруя его старым, с точки зрения защиты от криптоанализа, я расцениваю не более как запутывание (безопасность через неясность). Единственный прок от такой схемы – попытка защитить ранее переданные сообщения от бандитского криптоанализа. Конечно, если схему доработать на уровне самого протокола, и включть Skein, то ваше замечание будет вполне усместно, но пока это не то, что ваяется из подручных средств неспециалистом по теме.
зы: не автор топика.

шифр вдруг стал уязвимым – чем здесь поможет указанная выше смена ключа, шифруемого предыдущим?

Если алгоритм/протокол уязвим именно к быстрому подбору ключа, то частый rekeying позволяет закрыть данную уязвимость. Такова ситуация, например, с WEP: меняя ключ каждые пару секунд им ещё можно пользоваться. :-))

unknown, вы бы лучше сказали ответ с точки зрения именно криптоанализа, т.е. допускается, что шифр вдруг стал уязвимым – чем здесь поможет указанная выше смена ключа, шифруемого предыдущим?

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

Вообще ситуация "шифр вдруг стал уязвимым" выходит за рамки традиционной (с некоторых пор уже) модели "доказуемой безопасности". В ней всегда считается, что криптопримитивы и исходные компоненты протокола идеальны, а если нет – то вы уже проиграли.

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

Единственный прок от такой схемы – попытка защитить ранее переданные сообщения от бандитского криптоанализа.

Именно только ради этого. Ну и схожих задач: защита предыдущих принятых данных от трояна (взлома сервера или рабочей станции), отрицание ранее принятых и уничтоженных анонимных широковещательных сообщений.

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

Skein пока никем не утверждён, не признан и не является стандартом де-факто (на момент написания этих строк). Можно использовать существующие криптопримитивы для построения надёжной KDF, используя хотя бы черновые публикации NIST, например SP 800-108 Recommendation for Key Derivation Using Pseudorandom Functions.

Это может быть сделано из подручных средств, но всё-таки специалистом.

Вообще ситуация "шифр вдруг стал уязвимым" выходит за рамки традиционной (с некоторых пор уже) модели "доказуемой безопасности". В ней всегда считается, что криптопримитивы и исходные компоненты протокола идеальны, а если нет – то вы уже проиграли.

Если не копать так глубоко, а ограничиться общими критериями оценки безопасности (наподобие таковых, публикуемых в цветных книжках – ораньжевых и прочих), то можно найти в т.ч. требование апостериорного определения взлома, вмешательства извне, логов, и т.п. Т.е. только та система считается хорошо защищёной, в которой есть и механизмы на случай "а если не попёрло". Не знаю насколько близка эта параллель с чистым отмороженым дистиллированным криптоанализом, но, емнип, ввод каскадных шифров – это нечто подобное, и работы на тему их криптостойкости были (кажется, там как раз показали неаддитивность криптостойкости, так сказать).

Т.е. только та система считается хорошо защищёной, в которой есть и механизмы на случай "а если не попёрло".

Триада безопасности "предотвращение, контроль (аудит), реагирование".

с чистым отмороженым дистиллированным криптоанализом

Хороший термин. Надо запомнить. Может ещё добавить "рафинированным" по вкусу :)

Что касается изначального вопроса. В каких готовых программах это реализовано? В openVPN, кажется, была (есть?) возможность установления соединения только по общему симметричному ключу, но этот метод относится в самой программе к нерекоммендуемым. И вроде бы PFS и rekeying для него не реализован.

дистиллированным криптоанализом

На самом деле это калька с

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

lurkmore.ru/Матан

каких готовых программах это реализовано?

OTR for jabber?