Аналог PGP с обеспечением отрицаемости и наперёд заданной секретности оффлайн?

PFS разрабатывалось и было заброшено.

Отрицаемая аутентификация могла бы быть реализована на основе кольцевых подписей. Но этот протокол не реализован ни в одном из известных криптопродуктов.


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

Насчет уведомления о прессинге хз, ИМХО это вопрос нетехнический. А сбацать IM шифровалку с окном ключей, это какраз можно. Сходу видится что-то такое: на основе OTR протокола во время онлайн сессии генерируем не один симметричный ключ, а несколько, для каждого ключа задаются временные рамки использования. Получаем окно, за пределами которого соблюдается FPS, а внутри окна работают оффлайн сообщения и не критично к глюкам сети.

Окно ключей – неплохой вариант.
Я посмотрел протокол OTR, и возникла идея тоже использовать DH в варианте "для ответа на полученное оффлайн сообщение – новый ключ". Получить DH-секрет можно минимально за 4 шага, и если в каждом сообщении (туда или сюда) объединять по шагу для 4-х последовательных ключей, то всегда будем иметь новый ключ для ответа на входящее. Если пишем несколько раз подряд, то тогда уже будет окно: каждый раз хешируем старый ключ, удаляем и заменяем хешем. То же самое, если сообщение теряется, или невалидно.
Вначале инициатор связи создает временную PGP-связкy ключей для согласования аутентификационной фразы (тот час удаляя связку после использования) и однократно использует публичный PGP вызываемого абонента. Это никого не компроментирует.
По возможности попробую набросать протокол по наличию свободного времени. Понятно, что наколенно, но, может, у кого-то возникнут свежие идеи.

Лучше, чем эти работы?

A Forward-Secure Public-Key Encryption Scheme. Ran Canetti and Shai Halevi and Jonathan Katz.

Self-Updatable Encryption: Time Constrained Access Control with Hidden Attributes and Better Efficiency. Kwangsu Lee and Seung Geol Choi and Dong Hoon Lee and Jong Hwan Park and Moti Yung.

Это только по PFS. Опишите свой вариант PFS, который превосходит хотя бы эти публикации, так чтобы можно было сравнить вашу работу и работы других авторов, да ещё прикрутите к нему отрицаемость со всеми доказательствами, чтоб не хуже, чем у них.

Есть что добавить к сказанному в конце /comment71009?

unknown, спасибо, Вы стимулируете меня изучать весьма теоретические работы, в которые я сам никогда бы не стал вникать, ограничившись просмотром имеющихся реализаций :) Конечно, любой мой вариант PFS не будет ничего превосходить, да и не в этом цель.
Просто появилась мысль в каждом оффлайн-сообщении одновременно выполнять различные этапы независимых DH-согласований для последовательных ключей. При этом новый общий секрет, абсолютно не зависящий от предыдущего, будет получен после каждого входящего сообщения. На сколько это впишется в модель невозможности восстановить последовательность подписей в случае полной коллекции всех выхлопов DH изначально злонамеренным собеседником, я пока не могу осознать, т.к. это только не более чем наброски.
Тем более, я никогда подобным не занимался и ничуть не претендую на гуру в криптографии: просто в свободное время хочется размяться, и ни меня, ни других это ни к чему не обяжет. Так что пока не обдумаю хотя-бы до уровня приличия, добавить к comment71009 нечего.

Наверное, есть что добавить к comment71041.
Почему бы для оффлайн-общения не использовать специально написанные и поднятые на HS onion-сервера с протоколом TorChat? Идея в том, что их абоненты, имея onion-email вида: own_onion_address@server_onion_address
при офлайне получателя с помощью обычного торчат-клиента смогут отправлять сообщение на свой сервер, указав onion-email получателя. Задача сервера: передать сообщение на сервер получателя (или хранить некоторое время, если недоступен). Задача сервера-получателя – сбросить сообщение получателю при его первом подключении (или хранить некоторое время). Аутентификацию можно обеспечить в самом сообщение, это уже другой вопрос.
Это просто как пример возможностей HS-инфраструктуры к вопросу, почему же такой потенциал так скудно используется на фоне такого внимания к Jabber etc.

Под jabber есть стандартные программы, клиенты, интерфейсы. Под TorChat есть один-единственный гуйный клиент, написанный нарками:

То он был на питоне, то его забросили, то возобновили, то хотели делать на свободных аналогах визуал бэйсика и дельфи (Lazarus? Free Pascal?), то форкнули на плюсах, а теперь делают на Java. Там в архивах хотя бы электронные подписи есть? И торпроджект этот многострадальный проект как-то никогда не рекомендовал.

Не получится ровно по той же причине, что и для jabber'а:

это несовместимо с особенностями XMPP-протокола из-за его глубинной завязки на продвинутые фичи DNS. Единственное, что можно сделать — поставить один jabber-сервер на каком-то скрытом ресурсе и заставить всех регистрироваться именно на нём; на другие jabber-сервера он передавать сообщения не сможет.

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

gegel не нужно как-то разделять онлайн и оффлайн сообщения. Любое сообщение должно обрабатываться одинаковым образом, потому что вы не можете знать, онлайн оно или оффлайн, или вообще потеряется. Интернет рвётся, особенно при работе через Tor, другая сторона узнает об этом отнюдь не сразу. Мессенжер может вылететь в любой момент, сообщение может быть потеряно при глюке сервера.
У OTR в таких случаях происходит рассогласование сессии и сообщения молча "глотаются", пока кто-нибудь вручную не перезапустит. Это ужасно выбешивает, хочется разъебать лицо тому кто этот OTR придумал. Если ваш протокол в таких условиях работает неправильно, он будет доставлять проблемы, учтите это.

Когда в начале 70-х изобретённый RSA сразу же запатентовали, стали искать ему свободную замену. Протокол обмена по DH остался без патента, поэтому его пытались в буквальном виде реализовать для оффлайнового шифрования и подписи. Но от этой затеи отказались: для шифрования изобрели Эль-Гамаля, для подписи — DSA. А это не совсем то. Здесь первое сомнение возникает.

Затем, в девяностые, стали проектировать системы с PFS. Для онлайна и реалтайма — понятное дело DH. А для оффлайна (почты?). Думаете вы первый? Нет, тоже первым делом всплывала идея реализовать DH по шагам в оффлайновом режиме. Почему от неё опять отказались?

Почему с начала 2000-х оффлайновое PFS посчитали сложной проблемой и стали разрабатывать для него более сложные протоколы?

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

У меня только какие-то смутные догадки, но полного понимания картины нет. Подозреваю, что команда OpenPGP перерыла теоретическую часть по этому вопросу более десяти лет назад и возможно пришла к каким-то скептическим выводам не на пустом месте, отказавшись развивать стандарт PFS для переписки.

Не получится ровно по той же причине, что и для jabber'а:
это несовместимо с особенностями XMPP-протокола

Подразумевалось использование протокола TorChat в качестве анонимного транспорта, а внутри – PGP, OTR и т.п. протоколы. Транспортный XMPP тут не вписывается никак. Другое дело, что нет клиентов/плагинов, и я уже интересовался, почему. И получил ответ, но остался при своем мнении. Написать клиент – неделя для нормального программиста при наличии конкретного ТЗ.

gegel не нужно как-то разделять онлайн и оффлайн сообщения.

Я и не собирался разделять, рассматриваю все сообщения как оффлайновые (модель переписки с использованием электронной почты). Но разделяю исходящие на "Answer" (ответ на входящее, шифруется новым ключем, полученным на основе DH-материала во входящем) и "Repost" (последующие исходящие, шифруются хешем от прошлого ключа, включают KEYID, указывающий, сколько раз уже проведено хеширование ключа). Это окно ключей, которое завершается тот час после получения нового входящего.

Если ваш протокол в таких условиях работает неправильно, он будет доставлять проблемы, учтите это.

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

Есть вопрос, возможно, тупой, но мне хотелось лишний раз удостоверится:
Алиса посылает Бобу неподписанное PGP-сообщение (естественно, зашифрованное публичным ключем Боба), состоящее из двух слов X и Y. Ева перехватывает сообщение. Ей не известно содержание сообщения, но известна его структура (длина слов, их офсеты). Может ли она заменить X на нужное ей Z, оставив Y неизменным, и переслать Бобу сообщение Z+Y?

Другими словами, обеспечивает ли PGP целостность неподписанного сообщения?

А какая разница, если Ева может создать любое соощение для Боба с нуля?


Может, если правильно угадает Y. По самому сообщению угадать его содержимое невозможно (разве что по размеру, но он переменный даже для одинакового plaintext'а), так что остаются только внешние методы типа социнженерии.

Другими словами, обеспечивает ли PGP целостность неподписанного сообщения?

Да, см. RFC4880, 5.14, Modification Detection Code (MDC).

Да, см. RFC4880, 5.14, Modification Detection Code (MDC).

ОК, тогда идем дальше.
Предположим, что Алиса и Боб имеют предварительно согласованный общий секрет Y, известный только им двоим. Алиса пишет Бобу сообщение X+Y, где X – определенный текст. Боб получает сообщение, видит Y и уверен, что X тоже написано Алисой.
Но доказать это третьей стороне он не может, т.к. ему тоже известно Y, и он мог отправить это сообщение для себя сам.

Это верно?

(Это начало протокола, обеспечивающее отрицаемость. Извините, что по кусочкам мысль выкладываю, просто хочу, чтобы вовремя остановили, когда Остапа понесет)

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

Голый хэш вместо HMAC? Поначалу удивляет, но дальше всё разъясняется.

The obvious way to protect or authenticate an encrypted block is
to digitally sign it. However, many people do not wish to habitually sign data, for a large number of reasons beyond the scope of this document. Suffice it to say that many people consider properties such as deniability to be as valuable as integrity.

А проблема (не)отрицаемости давно была известна разработчикам.

OpenPGP addresses this desire to have more security than raw encryption and yet preserve deniability with the MDC system. An MDC is intentionally not a MAC. Its name was not selected by accident. It is analogous to a checksum.

Consequently, because it is a modest security system, it has modest requirements on the hash function(s) it employs. It does not rely on a hash function being collision-free, it relies on a hash function being one-way. If a forger, Frank, wishes to send Alice a (digitally) unsigned message that says, "I've always secretly loved you, signed Bob", it is far easier for him to construct a new message than it is to modify anything intercepted from Bob. (Note also that if Bob wishes to communicate secretly
with Alice, but without authentication or identification and with a threat model that includes forgers, he has a problem that transcends mere cryptography.)

Короче, gegel, спасибо за свежий взгляд, а SATtv'e за напоминание. Вы кажется нашли элементарное и готовое решение, которое лежало рядом, а все здесь присутствующие его в упор не замечали:

1. Стороны ведут сначала переписку как обычно — неотрицаемо и с подписями.
2. Затем кто-то решает, что часть вопросов хотелось бы обсудить с возможностью отрицания.
3. Стороны согласовывают общий секретный пароль для симметричного шифрования. Можно вывести его совместно из двух половинок, чтобы было никому не обидно, но это не обязательно: переслать общий пароль за своей подписью может и кто-то один.
4. Стороны переходят на симметричное шифрование с MDC.

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

Отрицаемость в OpenPGP, оказывается, давно уже есть из коробки! Нет только PFS.

Т.е., как и в обычном OTR по шагам протокола нельзя отрицать факт связи A с B, но можно отрицать содержимое написанного, обвиняя противоположную сторону в подделке разглашённой переписки.