— unknown (20/11/2013 13:01)   
PFS^[link3] разрабатывалось и было заброшено.

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


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

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

— gegel (20/11/2013 21:28, исправлен 20/11/2013 21:29)   

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

— unknown (22/11/2013 10:44, исправлен 22/11/2013 10:45)   

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

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

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^[link6].

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

— Гость (22/11/2013 14:09)   

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

— gegel (23/11/2013 01:25, исправлен 23/11/2013 01:27)   

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

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

— Гость (23/11/2013 04:13)   

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

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

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

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

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

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

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

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

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

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

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

— gegel (24/11/2013 00:43, исправлен 24/11/2013 00:53)   

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

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

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

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

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

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

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

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

— Гость (24/11/2013 04:54)   

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


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

— SATtva (24/11/2013 09:30)   

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

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

— gegel (24/11/2013 10:37)   

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

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

Это верно?

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

— SATtva (24/11/2013 11:01)   
Если у них есть общий секрет, то шифрование с открытым ключом им не нужно. Напомню, OpenPGP поддерживает симметричное шифрование, MDC там так же присутствует.

— unknown (24/11/2013 13:24, исправлен 24/11/2013 13:29)   

Голый хэш вместо 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, но можно отрицать содержимое написанного, обвиняя противоположную сторону в подделке разглашённой переписки.

— SATtva (24/11/2013 13:44)   
Если использовать OpenPGP только для транспорта, то PFS можно надстроить в виде собственного легковесного механизма управления симметричными ключами (примерно как предлагалось выше: путём отправки собеседнику в каждом сообщении нескольких новых ключей или путём их выработки по KDF из даты и ранее согласованного краткосрочного секрета). Стандарт изначально разрабатывался низкоуровневым без привязки к конкретным приложениям, и авторы закладывали в него достаточную гибкость, чтобы при желании реализовывать в том числе и подобные схемы.

— gegel (24/11/2013 14:52)   

Короче, gegel, спасибо за свежий взгляд.

Если честно, я в этом пока ни черта не понимаю, поэтому могу позволить себе незаангажированно пофантазировать, если, конечно, это никого не напрягает.

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

Это было вступление.
Теперь предположим, что общего секрета у Алисы и Боба нет, и они могут идентифицироваться друг перед другом и перед третьей стороной только своими публичными ключами, проверяемыми по PKI.
Алиса берет текст публичного ключа Боба, дописывает к нему нейтральную метку (например, версию данного протокола), и подписывает. Подпись будет Y.
Далее, как и выше, Алиса отправляет Бобу PGP-сообщение, содержащее X+Y, где X – определенный текст. Получив сообщение, Боб проверяет подпись Алисы и уверен, что X тоже написано ею. Но доказать это третьей стороне он по прежнему не может: Алиса может опровергнуть, сказав, что посылала Y Бобу ранее в контексте совсем другой беседы.
Примечание:
– честная Алиса должна тот час после отсылки сообщения Бобу удалить Y, если она не хочет, чтобы кто-то позже мог выдать Бобу себя за нее.
– честный Боб должен тот час после проверки подписи удалить Y, если он не хочет, чтобы кто-то позже мог представиться ему Алисой.
– но каждый из них может сжульничать, и это недоказуемо.

Пока верно? Если в принципе да, то продолжу.

— unknown (24/11/2013 15:15, исправлен 24/11/2013 15:17)   

2 SATtva:

Пусть PK_A — открытый (публичный) асимметричный ключ стороны A.
SK_A — закрытый (секретный) асимметричный ключ.

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

Сторона A подписывает и шифрует для B пароль: Encrypt_PK_B (Sign_SK_A (Pass)).

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

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

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

Полноценное PFS требует удаления всего использованного для шифрования ключевого материала.

— SATtva (24/11/2013 15:23)   

Не выйдет: с ЭЦП выползает такая прекрасная вещь, как метки времени, ломающие отрицаемость беседы. Боб может доказать, что получил сообщение от Алисы, если та специально не подделывала время (а это в общем случае не так). Опять же, зачем эти сложности с открытыми ключами? unknown же выше^[link10] уже привёл протокол в общем виде. Короче, не совсем понимаю, к чему Вы ведёте.

— SATtva (24/11/2013 15:25)   

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

Да, точно, поспешил с ответом.

— unknown (24/11/2013 15:30, исправлен 24/11/2013 15:31)   

Алиса берет текст публичного ключа Боба, дописывает к нему нейтральную метку (например, версию данного протокола), и подписывает. Подпись будет Y.
Далее, как и выше, Алиса отправляет Бобу PGP-сообщение, содержащее X+Y, где X – определенный текст. Получив сообщение, Боб проверяет подпись Алисы и уверен, что X тоже написано ею.

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

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

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

Но перехватчик Ева знает какие сообщения реально ходили в канале связи, а какие были опубликованы отдельно.

P.S. У меня оказался немного другой взгляд на метки времени.

— SATtva (24/11/2013 15:37)   

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

Тут имеется в виду раскрытие в прямом эфире, при котором Боб сливает Еве содержимое беседы в её процессе. Даже обычная погрешность часов в несколько минут не позволит Алисе утверждать, что это трафик из какой-то совсем посторонней беседы.

— unknown (24/11/2013 15:45)   
В прямом эфире отрицаемость не даст никакой протокол, даже OTR. Об этом речь, когда говорят о бесполезности судебной отрицаемости: если вовремя поставить экспертов и понятых с видеокамерой и часами за спиной у подконтрольного, сотрудничающего или подставного Боба, то всё что выболтает Алиса, она отрицать не сможет. Алиса может только утверждать, что она расписалась в начале сеанса, а затем связь вели с подставным лицом, а не с ней, но суд скорее поверит в честность экспертов.

— SATtva (24/11/2013 15:51)   
Нет, такой сценарий я не рассматриваю. Но в более слабом, при котором Боб и Ева удалены друг от друга, и Боб может лишь транслировать ей трафик Алисы (допустим, он перепощивает её сообщения в Твиттер для публичного унижения), использование ЭЦП с метками времени либо только MDC/MAC будет иметь принципиальную разницу в доказательной силе.

— unknown (24/11/2013 20:06)   
Небольшая модификация /comment73766^[link10].

Из man gpg:

--force-mdc
Force the use of encryption with a modification detection code. This is always used with the newer ciphers (those with a block size greater than 64 bits), or if all of the recipient keys indicate MDC support in their feature flags.

Т.е. mdc будет использоваться по-умолчанию итак практически всегда. В крайнем случае через gpg -vvv 2>log можно посмотреть подробный выхлоп присланного сообщения и поискать в нём строку mdc_method.

Тогда, первые два пункта не меняются, остальные можно сделать лучше:

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

— unknown (24/11/2013 20:30, исправлен 24/11/2013 20:32)   

С отрицаемостью вроде как всё хорошо. Даже как-то подозрительно и не верится, что всё так просто оказалось.

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

— gegel (24/11/2013 20:50, исправлен 24/11/2013 20:52)   

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

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

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

Без своей подписи? Если подпишет, теряется отрицаемость, если нет – доверие к паролю со стороны Боба. Предполагаем – общего секрета пока нет.

Не выйдет: с ЭЦП выползает такая прекрасная вещь, как метки времени, ломающие отрицаемость беседы.

Вот об этом даже не догадывался. Ну, тогда вместо ЭЦП Алиса может зашифровать текст публичного ключ Боба + версию протокола своим закрытым ключом (надеюсь, в OpenPGP это возможно) и вложить в сообщение: та же подпись, но без меток времени. Она проверяется расшифровкой ее публичным ключом.

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

К этому и веду. Расшарить с отрицанием хочу не симметричный ключ, а аутентификатор для последующих общих секретов DH:

Теперь все точно как и в предыдущий раз, но в начале Алиса генерирует временную пару ключей. X – публичний ключ из этой пары. Также Алиса придумывает случайный тег аутентификации, хеширует и добавляет к первому сообщению его хеш H. Также Алиса берет текст публичного ключа Боба, дописывает к нему нейтральную метку (например, версию данного протокола), и шифрует своим приватным ключем. Результат будет Y. Отправив сообщение, Алиса тот час удаляет Y.

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

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

Получив его, Боб сверяет хеш тега Алисы и теперь уверен, что этот тег был придуман именно ею.
Алиса и Боб ксорят теги. Теперь у них них есть общий секрет всего за три хопа с использованием PGP при двухсторонней отрицаемости. В дальнейшем он будет использоваться для аутентификации DH-секретов (анти-MitM) с сохранением отрицаемости на случай, если один из участников соберет DH-материал с целью восстановить цепочку и скомпроментировать второго, доказав, что он аутентифицировал текущий общий секрет DH. Необходимости в PGP больше нет.

Если до этого места в рассуждении явных ляпов нет, я составлю более-менее человеческое описание всего протокола (вместе с DH-стадией) и выложу на обсуждение.

— gegel (24/11/2013 21:07)   

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

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

— unknown (24/11/2013 21:10)   

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

Без своей подписи? Если подпишет, теряется отрицаемость, если нет – доверие к паролю со стороны Боба.

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

Остальную часть вашего поста может быть разберу позднее.

— unknown (24/11/2013 21:15, исправлен 24/11/2013 21:16)   

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

echo "Я Алиса Коварная, подсовываю этот пароль Бобу, который владеет ключом XXXXXXXX и делаю это во время XX.XX.XXXX XX:XX ;)" | sha256sum > password

— SATtva (25/11/2013 08:29, исправлен 25/11/2013 08:34)   

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

Это не так.

Ну, тогда вместо ЭЦП Алиса может зашифровать текст публичного ключ Боба + версию протокола своим закрытым ключом (надеюсь, в OpenPGP это возможно) и вложить в сообщение: та же подпись, но без меток времени.

Нельзя. И такой финт работал бы только для ключей RSA. OpenPGP предписывает использование меток времени для всех подписей, так что либо надо подделывать время, либо как-то обходиться без подписей, либо использовать их так, чтобы это не вышло боком.

Самое смешное, что в gpg2 есть специальный отладочный параметр --faked-system-time, в который можно было бы передать 0, однако программа этот параметр почему-то не воспринимает (может, лично у меня, хотя в 2.0.22 должно работать).

— unknown (25/11/2013 09:56)   
2 /comment73795^[link11] и в дополнение к /comment73796^[link12].

Если сторона высылает пароль, то она может подсунуть в него нечто, как в примере /comment73797^[link13], но это следует считать или неустранимой проблемой или вообще не считать проблемой согласно /comment73796^[link12]. Если пароль выводят обе стороны, неважно — объединением, сложением, ксором, хэшированием, классическим бит коммитментом^[link14], то в подписанный параметр любая сторона всегда может воткнуть хэш от какого-то предварительного заявления. Но это её заявление, которое можно рассматривать как заведомо ложное или как намерение о провокации.

Ещё раз, если у сторон заранее отсутствует предрасшаренный секрет, то за счёт подписей при согласовании, если Алиса раскроет отрицаемую переписку с Бобом:

1. Боб не сможет отрицать факт переписки с Алисой (поэтому не важно, что одна из сторон запишет в аутентифицирующий пароль).
2. Боб не сможет отрицать, что он согласился именно на режим отрицаемой переписки.
3. Если Алиса проставит криптоштампы времени у доверенной третьей стороны, то Боб не сможет отрицать, что переписка происходила в какое-то другое, более позднее время.
4. Боб может отрицать только содержимое переписки: утверждать, что его тексты были отредактированы или полностью сочинены Алисой.
5. П.4 не работает, если Алиса сливает переписку наблюдателю сразу же в реальном времени, каким-то образом доказывая ему, что она получила письмо от Боба вот только что и у неё не было времени его подменить.

— gegel (25/11/2013 18:42, исправлен 25/11/2013 18:46)   

>Если Ева контролирует трафик обоих, то, боюсь, что-то отрицать не получится, даже без его расшифровки.
<Это не так.

Тогда я, наверное, неверно понимаю термин "отрицаемость" – какая модель угроз подразумевается?

Возможна ли отрицаемость для Алисы:
– если Ева просто контролирует трафик ее и Боба?
– если Боба позже принуждают к сотрудничеству?
– если он изначально злонамеренній и скооперирован с Евой?

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

Возможно, так получится этому противостоять (считаем k хешем от компроментирующего заявления):

Алиса и Боб имеют публичные ключи друг друга и доверяют им. Боб инициирует общение с Алисой.

Задача: сгенерировать общий секрет, чтобы включать его в неподписанные PGP-сообщения для своей аутентификации друг перед другом. Так, чтобы Ни Алиса, ни Боб не смогли доказать кому-либо еще, что вторая сторона владеет этим секретом или принимала участие в его выработке, но сами в этом были уверены.

0. Боб генерирует случайное число k, подписывает и отсылает его Алисе. Это единственное сообщение, связывающее его с Алисой. Только она может получить k, и она будет уверенна, что получила его именно от Боба. Третей стороне k неизвстно. Задача протокола – сделать так, чтобы Боб (случайно, позже под нажимом или изначально злонамеренно) не смог позже связать ни факт, ни контекст беседы с Алисой с этим k, но сам мог идентифицировать Алису. То же касается Алисы.

Примечание: предполагаем, что метка времени обнулена, и Боб всегда может утверждать, что посылал Алисе это сообщение и k ранее совсем в другом контексте. Алиса может утверждать, что она это сообщение не получала и k никогда не видела.

1. Алиса генерирует случайное число ra, сохраняет и отсылает Бобу его хеш h. Она уверена, что только Боб может этот хеш получить. Ева может перехватить сообщение, подменить его, но не прочитать.

2. Боб получает h, но не уверен, что его послала Алиса, и не уверен, что факт владения h не скомпроментирует его позже. Он сохраняет его в секретном месте, генерирует свое случаное число rb, сохраняет сам и отсылает Алисе. Он уверен, что только Алиса может получить это число. Ева может перехватить сообщение, подменить его, но не прочитать.

3. Алиса получает число rb от Боба, но она не уверена, что его послал Боб, и не уверена, что факт владения этим числом не скомпроментирует ее позже. Алиса банально ксорит полученное число rb со своим ra, получает s. Т.к. она уверена, что свое число случайное, то и s будет случаен. Теперь Алиса отсылает свое случайное число ra Бобу и тот час удаляет и его, и число rb, полученное от Боба.

4. Боб получает число ra от Алисы, но не уверен, что его послала Алиса, и не уверен, что факт владения этим числом не скомпроментирует его позже. Он сверяет хеш с h, и теперь уверен, что отправитель этого сообщения то же, что и предыдущего, и не менял задуманное вначале число, исходя из полученного числа Боба. Боб ксорит полученное число ra со своим rb, получает s. Т.к. он уверен, что свое число случайное, то и s будет случайное. Боб тот час удаляет h, ra и rb.

5. В итоге у Алисы и Боба могут быть различные s (если внедрилась Ева), но если они одинаковые, то Ева о них гарантированно ничего знать не может. Также Ева ничего не знает о числе k, подписанном Бобоб. Алиса и Боб вычисляют MAC m от результата s, в качестве ключа используют k. Т.к. s случаен и для Алисы, и для Боба (как показано выше), то и m будет случаен. На шаге 1 Алиса не сможет подсунуть вместо случайного такое число, чтобы затем, реверсировав mac, доказать связь m и k. Ни Боб, ни Алиса не смогут показать связь k и m, т.к. число m было рандомизировано другим участником, и связать его с ним невозможно.

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

— unknown (26/11/2013 10:22, исправлен 26/11/2013 13:02)   

Похоже на бит-коммитмент (multibit, string-commitment) на хэшах для совместного выведения секрета. С учётом того, что принято инициирующей стороной назначать Алису, можно нагляднее переписать так, вообще без использования подписи в вашем п.0:

1. Alice: Generate R_A. Send Alice → Bob: Encrypt_PK_B (A ║ H(R_A)).
2. Bob: Decrypt_SK_B (A ║ H(R_A)). Generate R_B. Send Bob → Alice: Encrypt_PK_A (B ║ H(R_B) ║ H(R_A)).
3. Alice: Decrypt_SK_A (B ║ H(R_B) ║ H(R_A)). Send Alice → Bob: Encrypt_PK_B (A ║ H(R_B) ║ R_A).
4. Bob: Decrypt_SK_B (A ║ H(R_B) ║ R_A). Check H(R_A) = R_A. Compute R = R_B ⊕ R_A. Send Bob → Alice: Encrypt_PK_A (B ║ H(R_A) ║ R_B).
5. Alice: Decrypt_SK_A (B ║ H(R_A) ║ R_B). Check H(R_B) = R_B. Compute R = R_A ⊕ R_B.

Кое-что по теории есть здесь^[link15]. На стр. 12-14 такие протоколы критикуются как проблемные. Но в чём м.б. проблема в данном случае — сказать затрудняюсь. М.б. частичный MITM?

Отдельную ссылку на то, что это всё напоминает, вынес в /comment73841^[link16].

— SATtva (26/11/2013 16:54)   

Тогда я, наверное, неверно понимаю термин "отрицаемость" – какая модель угроз подразумевается?

Я рассматриваю по аналогии с OTR: отрицается не факт совершения беседы, а содержимое диалога, т.е. ни одна из сторон не может доказать третьей стороне, что собеседник действительно писал такое. Прослушивание OTR-трафика не позволяет внешнему наблюдателю утверждать что-либо о его содержании. Если Ваша модель допускает контроль Евы над каналами обоих собеседников, то более сильной отрицаемости (отрицание факта беседы) Вы всё равно не добьётесь даже с помощью Tor, ибо атака на подтверждение трафика.

Возможна ли отрицаемость для Алисы:
– если Ева просто контролирует трафик ее и Боба?

По содержанию беседы — да, по факту беседы — нет.

– если Боба позже принуждают к сотрудничеству?

По содержанию беседы — да, по факту беседы — возможно, если в протоколе вообще не применяются ЭЦП.

– если он изначально злонамеренній и скооперирован с Евой?

Ни по содержанию, ни по факту беседы.

— gegel (27/11/2013 01:51, исправлен 27/11/2013 11:48)   

/comment73839^[link17]

М.б. частичный MITM?

Мне тоже так показалось. Терию почитаю, спасибо.

/comment73790^[link18]:

С отрицаемостью вроде как всё хорошо. Даже как-то подозрительно и не верится, что всё так просто оказалось.

Не все так хорошо на самом деле, принимая во внимание тезизы ниже:

/comment73850^[link19]:

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

/comment73766^[link10]:

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

Но пессимистическая нота: данная схема, к сожалению, обеспечивает только отвязку беседы от ее инициализации и от публичных ключей участников. Но, в отличие от OTR, вся беседа в смысле отрицаемости является единым целым: если один из участников докажет авторство хотя бы одного любого сообщения (по содержанию, уникальной информации, известной только другой стороне и т.п.), то автоматически докажет авторство всех его сообщений. Или я ошибаюсь, и предложенная Вами схема ( /comment73788^[link20] ) поможет этого избежать?
Возможно, поможет параллельная PFS с помощью пошаговой DF, но не уверен, что все так просто будет. Как бы в итоге не получился тот же OTR. Что еще раз подтверждает его уникальность.

— Гость (27/11/2013 02:40)   
gegel, в структуре wiki цитаты ставятся от корня домена, вот так:
На печати будет:
Вместо круглых скобок всегда можно использовать квадратные.

— unknown (27/11/2013 10:47, исправлен 27/11/2013 11:39)   

Поможет скорее схема /comment73839^[link17] (чуть доработанный вариант вашей же идеи), там вообще нет использования каких-либо подписей изначально. Только шифрование на публичный ключ другой стороны, но обязательно с использованием опции MDC. Вроде, включением повторных H в ответы на запрос, можно даже избежать MITM, но это всё наброски на коленке и бездоказательно. В вышеприведённой работе вроде как указанно, что при соблюдении всех условий с биткоммитментом такие схемы аутентификации работают, но есть отсылки к другим работам, надо разбирать, где там м.б. узкие места.

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

Даже если A заготовит своё R_A за год до этого сеанса переписки, запихнёт в него хэш от содержимого предыдущих подписанных писем Боба, проштампует у третьей стороны — вроде это ничего доказывать не должно. Она дальше может полностью сочинить не только содержимое переписки, но и факт согласования параметров с Бобом.

Видится, например, небольшая утечка такого рода. Алиса пытается снова согласовать параметры с Бобом, утверждая, что предыдущее совместное R было потеряно, но использует для этого новое R_A, связанное с предыдущим по какой-то формуле, после чего разглашает эту формулу и свой закрытый ключ на каком-нибудь закрытом форуме. Тогда все его участники могут увидеть, что Боб снова вышел с ней на связь и ведёт компрометирующие его разговоры.

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

Хуже вариант, когда злонамеренная Алиса-провокатор изначально использовала в качестве своего R_A хэш от своего же закрытого ключа (можно похэшировать со вставкой какого-нибудь слова, чтобы было доказательно, но Боб не догадался). Этот закрытый ключ она и предполагала впоследствии разгласить вместе со всеми сеансами и перепиской, проштампованными метками времени и связанными цепочкой хэшей. После раскрытия своего ключа она может дать всем желающим продолжить переписку с Бобом (она может даже подсказывать диалог), так что он ни о чём не догадается и будет думать, что переписывается с ней. Все желающие смогут сами посылать на открытый ключ Боба сообщения под видом Алисы, а он будет отвечать на её ключ, включая в ответы R, выведенное из этого R_A.

P.S.: Кажется, составляя этот комент, я поломал все ваши и свои предыдущие наивные протоколы. Не изобретайте протоколы на коленке шифрпанковским способом. Пусть этим занимаются теоретики.

— unknown (27/11/2013 12:50, исправлен 27/11/2013 12:58)   

Посмотрел протоколы OTR^[link21] и SKEME^[link22]. Там всё тоже самое. Если провокатор Алиса инициализирует какой-нибудь генератор случайных чисел хэшем своего закрытого ключа и будет брать во всех сеансах связи параметры с этого генератора, а затем в ходе сеанса связи раскроет всю эту схему третьему лицу или группе лиц вместе со своим закрытым ключом и они вступят в переписку с Бобом от её имени, то они могут убедиться, что переписка с Бобом была подлинной, на другом конце линии им отвечает Боб.

Помимо того, группа лиц может заранее совместно сгенерировать общий секрет и ключ Алисы, чтобы от её имени участвовать в переписке с Бобом. Затем они опубликуют метод создания этого секрета из множества своих ключей (например известной группы хакеров или экспертов правоохранительных органов, или ещё каких разоблачителей) вместе со всей перепиской, разоблачающей Боба.

Или я чего-то не понимаю.

— SATtva (27/11/2013 13:28)   
Новостные заголовки через пару дней: "ШОК!!! Участники проекта pgpru.com взломали протокол OTR".

— unknown (27/11/2013 13:54)   
А нечего было такие провокационные вопросы задавать :D

— SATtva (27/11/2013 14:08)   
Если серьёзно, то возможен ли вообще совместный протокол, при котором стороны не могут заложить такую бомбу в передаваемые параметры? Насколько понимаю, такой риск есть везде, где участники используют случайные числа — по факту, они могут оказаться не столь уж случайными.

— unknown (27/11/2013 14:14, исправлен 27/11/2013 14:18)   

Я сейчас пытаюсь что-то ответить, попутно мучаясь с местной вики-разметкой. Следите за дальнейшими событиями. Хотя, может мне стоит просто получше выспаться и не торопиться с выводами…

Cейчас думаю над началом сеанса в OTR:

We want repudiability: no one should be able to prove Alice sent any particular message, whether she actually did, or not. For this reason, we never use a digital signature to prove Alice’s authorship of any message. The only data we ever sign are Alice’s values of g^x_A in the Diffie-Hellman protocol. Everyone, including Bob and Eve, can then be assured that Alice was really the one who chose the value of x_A that produced g^x_A, but that is all they know. Bob, on the other hand, has extra information: x_B, and with it the shared secret g^{x_A x_B}. We will use this shared secret next to prove Alice’s authorship of the message to Bob, and only to Bob.

— unknown (27/11/2013 14:32, исправлен 27/11/2013 14:35)   

Большая группа народу может совместно создать некий секрет R, подписать его всеми своими подписями. На основе этого секрета создать совместно управляемый ключ некой Алисы (журналистки, подставной пособницы преступника и др.), а хэшем закрытой части этого ключа (со вставленной строкой, например "Gotcha, Bob! We are anonymous avengers with real keys 0xXXXXXXX!") инициализировать генератор псевдослучайных чисел, с которого отправлять все параметры Бобу. Так, параметр, X_A для g^X_A будет связан с этим генератором, Боб ответит g^X_B. У обеих сторон будет вычислен сеансовый ключ g^{X_A X_B}. Но псевдо-Алиса сможет доказать, что он состоит из помеченного X_A.

Дальше надо подумать…

— unknown (27/11/2013 14:56, исправлен 27/11/2013 21:12)   

Так OTR шифрует сессии, отлично, все помеченные параметры от ГПСЧ Алисы идут в сообщения, да ещё и связываются между собой:

A → B : g^x₁
B → A : g^y₁
A → B : g^x₂, E(M₁, k₁₁ )
B → A : g^y₂, E(M₂, k₂₁ )
A → B : g^x₃, E(M₃, k₂₂ )
where k_ij = H(g^{x_i y_j} ), the result of a 128-bit hash, such as truncated SHA-1 [22]

Глава "4.3 Authentication" в прямом и переносном смысле слова — ключевая.

A → B: Sign(g^x₁ , k_A ), K_A
B → A: Sign(g^y₁ , k_B ), K_B
Where k_a , K_A are Alice’s private and public long-lived
signature keys, and k_b , K_B are Bob’s.

Обе стороны могут подсунуть на подпись друг другу помеченный секрет. Q.E.D.: В лучшем (для стойкости OTR) случае Алиса может доказать, что переписывалась с Бобом или Боб — что с Алисой, если кто-то из них подсуетился заранее. В худшем — подлинность содержимого сообщений, но это пока не вполне ясно.

Дальше, они из него же выводят MAC:

We only need to use a digital signature on the initial key exchange. In further key exchanges, we use MACs to authenticate a new key using an old, known-authentic shared secret. That is, a protocol message looks like:
g^x_i+1, E(M_r , k_ij ),
MAC({g^xi+1, E(M_k , k_ij )}, H(k_ij))

2 SATtva:

Если серьёзно, то возможен ли вообще совместный протокол, при котором стороны не могут заложить такую бомбу в передаваемые параметры?

Похоже, что нет. И похоже, что это серьёзно.

2 gegel /comment73795^[link11]:

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

Если окажется, что и обе половинки никак не помогают, то вам, gegel и вам, Гость из другой темы^[link7] теперь тоже никак не отмазаться большое спасибо.

P.S.: Надо ещё последнюю версию протокола^[link23] поковырять.
P.S.S.: Последняя версия в данном вопросе от первой, описанной в исходной работе, ничем существенно не отличается. Стороны всё равно обмениваются подписанными параметрами для вывода совместного секрета DH и получают связанную цепочку сообщений, ключей и MAC, только более сложным способом. Если злонамеренная сторона шлёт все параметры из детерминированного ГПСЧ, а затем раскрывает его алгоритм и ключ (выведенный из своего секретного ключа OTR), то фактически она доказывает и авторство второй стороны, и подлинность содержимого записанной переписки. Протокол соцмиллионера там сбоку-припёку и обычно используется только как доп. проверка. Плохо, что по последней версии нормальной работы нет.
P.S.S.: Насчёт доказательства подлинности содержимого пока сомнения остаются. Первый обмен по DH выдаст общий g^xy, на составных частях которого будут красоваться подписи обеих сторон и подставной x из детерминированного ГПСЧ. На всех последующих — выведение MAC'ов, ключей и пр. будут влиять предопределённые x, но y Алиса может выбирать свободно вместо Боба. Может ли Алиса к предопределённым g^x подбирать такие y, чтобы получить осмысленный результат во всей последующей переписке? Если может, не нарушая связности протокола со своим ГПСЧ — то тогда она может подделывать переписку, значит содержимое переписки останется отрицаемым. Если не может (и ей нужен реальный Боб) — то тогда отрицаемость действительно теряется и становится доказываемой третьей стороне. Методы с групповой генерацией секрета Алисы, также как и методы с последующей попыткой связаться участникам группы с Бобом через раскрытый ключ Алисы — это вообще отдельные сценарии, ограниченной, скажем так, неотрицаемости содержимого.

— gegel (27/11/2013 22:58, исправлен 27/11/2013 23:04)   

Может ли Алиса к предопределённым gx подбирать такие y, чтобы получить осмысленный результат во всей последующей переписке?

Я вот как раз об этом тоже сегодня думал. И, похоже, таки не может за реальное время. Со всеми вытекающими...

PS: Спасибо за викиразметку. Извините, учту на будущее.

— unknown (28/11/2013 10:04, исправлен 28/11/2013 12:42)   

А сегодня я проснулся и решил, что всё, что было написано мной вчера про OTR — полный бред. Т.е. принципы работы я понял может и правильно, а выводы сделал неверные.

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

В итоге, всё равно всё сводится к обычной схеме.
Алиса генерирует помеченный x_A, посылает Бобу g^x_A, он в ответ генерирует x_B, посылает g^x_B, каждый возводит полученный от другой стороны g^x в свою степень x и обе стороны получают совместный секрет g^{x_A x_B}. Обычный DH, который далее просто пошагово размазан по всему протоколу.

Из первого секрета стороны получают MAC, по которому ещё раз обмениваются новыми g^x_A и g^x_B для нового секрета. Так вот уже на этом этапе Алиса не имеет привязки сообщений к Бобу. Она просто считает, что раз никто, кроме них не знает текущий MAC, которым заверяется очередной обмен, то все параметры и сообщения идут от Боба. Но если она его знает, то никто не мешает ей самой себе прислать любой случайный g^x_B вместо Боба. От этого вычислится какой-то следующий случайный MAC и ключ, которым она сама себе «заверит» и зашифрует любое сообщение, якобы полученное от Боба.

Далее, каждая сторона в сообщение включает соответственно новые g^x_A или g^x_B, которые служат для выведения последующих совместных секретов, MAC'ов и ключей. Алиса может опять же присылать или записывать в свою переписку любые g^x_B, якобы полученные от Боба, заверять их предыдущими MAC, а получающимися случайными ключами и новыми MAC'ами создавать любые сообщения. То, что её ГПСЧ — предопределённый некоторым секретом — не имеет никакого значения. Она может подставлять любые g^x_B, которые никак не связаны ни с ней, ни с её ГПСЧ. Подгонять их ни под какой конкретный результат не нужно. Всю последующую сессию она может сочинять сама, как ей вздумается, выбирая g^x_B произвольным образом.

С отрицанием факта связи, по крайней мере в последней версии OTR — вроде также должно быть всё в порядке: стороны напрямую не подписывают свои параметры. Наконец, свой протокол OTR авторы считают слишком неподходящим для оффлайна и рекомендуют вместо него SKEME, который приблизительно похож на то, что я пытался изобразить в /comment73839^[link17]. Там вроде как заявлено и PFS, и отрицаемость, и сокрытие факта связи, и автор известный. Правда, протокол старый, надо смотреть новые публикации по теме.
Чуть новее — Private Authentication. Martın Abadi^[link24], также упоминаемый авторами OTR.
P.S.: Последняя работа по OTR^[link25]. Что-то там для защиты от MITM наворотили много подписей, в частности обе стороны подписывают и g^x, и g^y. Тогда опять получается, что и от факта связи не отвертеться, а при использовании помеченного PRNG, тогда и содержимое переписки может стать доказуемо записываемо для предъявления третьей стороне?

Или я опять чего-то не понимаю…

— gegel (01/12/2013 16:00, исправлен 01/12/2013 16:09)   

Unknown, я нашел время тщательно разобрать публикации по вашим ссылкам: исходную и поправленную версии OTR, аутентификации по SKEME и описанную Abadi. В отличие от двух последних протоколов, не нашел формального доказательства стойкости OTR. Разрабочики OTR заточили его под IM, отсюда сложности с аутентификацией. Появилась идея "скрестить" SKEME и OTR, максимально адаптировав к модели общения через email при сохранении всех заявленных свойств этих протоколов.

Основные отличия от оригинального OTR:

• для аутентификации DH-секретов используется долговремнный результат SKEME вместо кучи хитрых хешей от половинок DH;
• использованные ключи заменяются хешами, т.о. окно колючей имеет односторонюю PFS

Основные отличия от оригинальной SKEME:

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

x, y – DH-экспоненты (384 бита)
t,a,b,k – ключи (128 бит)
HASH(), HMAC_k() – урезанные хеши (128 бит)
ENC_k (),DEC_k () – симметричное шифрование/дешифрование (AES CTR)
PKE_A{} – PGP-шифрование публичным ключом A
g – генератор, возведение в степень – по модулю p (1024 бита)

Алиса и Боб имеют публичные PGP-ключи друг друга. Алиса инициирует связь.

Основная нить инициализации соединения:

1.A:

• выбирает и сохраняет случайные a, x, t
• подсчитывает h_a=HASH(a), X=g^x, X'=ENC_t(X)
• A->B: PKE_B {h_a, X'}

2.B:

• выбирает и сохраняет случайные b, y
• подсчитывает Y=g^y
• B->A: PKE_A {b, Y}

3.A:

• подсчитывает и сохраняет k = a xor b
• подсчитывает t'=ENC_k(t), s=Y^x, ks=HMAC₁(s), ka=HMAC₂(ks)
• сохраняет ks, ka вместе с индексом 0
• A->B: PKE_B{a, t'}
• удаляет a, x, t

4.B:

• проверяет HASH(a)==h_a
• подсчитывает и сохраняет k = a xor b
• подсчитывает t=DEC_k(t'), X=DEC_t(X'), s=X^y, ks=HMAC₁(s), ka=HMAC₂(ks)
• сохряняет ka в очереди на 2 сообщения (будет опубликовано через одно сообщение)
• удаляет b, y
• шифрует текст: msg=ENC_ks (text)
• аутентифицирует сообщение: mac=HMAC_ka(msg || ...)
• B->A: msg, ..., mac (PGP тут и далее не используется)
• заменяет ks=HMAC₃(ks), ka=HMAC₂(ks), сохраняет вместе с индексом 1

5.A:

• проверяет mac==HMAC_ka(msg || ...) для текущего и старого ключей ka, хешируя последний от текущего индекса вверх
• читает text=DEC_ks(msg)
• заменяет использованные ks=HMAC₃(ks), ka=HMAC₂(ks), сохраняет вместе с инкрементированным индексом использованного ключа

PS: во всех сообщениях, начиная со второго, запускаются параллельные нити DH, аналогичные описанным выше (но без согласования k=a xor b, т.к. k согласовывается однажды и является долговременным на всю беседу), для последующих одноразовых ключей, т.е. в течение установившегося сеанса связи каждое сообщение содержит 4 нити (три для для различных фаз DH-согласования последовательных одноразовых секретов и одну – собственно для текста). Аутентифицируется все сообщение целиком: (X'_n+3, Y_n+2, t'_n+1, msg_n), mac_n

— unknown (01/12/2013 19:21)   
Интересно, спасибо. Надо будет посмотреть, подумать. Может как-то найдётся время разобрать последний OTR и выяснить его стойкость к вбрасыванию детерминированных псевдослучайных помеченных параметров, закинуть этот вопрос в рассылку и заодно обсудить альтернативные протоколы.

— unknown (02/12/2013 13:02)   
Что-то это мне напоминает: Fully Deniable Mutual Authentication Protocol Based on RSA Signature^[link26].

— gegel (02/12/2013 15:34)   
Спасибо за очередную ссылку. Уже мозги кипят от такого количества информации в абсолютно новой для меня теме. Но тяжелое детство с ордой безжалостных репетиторов закалило. Надеюсь, крышу не снесет :)
PS:

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

Просмотрел с этой точки зрения: таки стойкий. Дело в том, что единственным вбрасываемым параметром, явно используемым противоположной стороной, есть next_dh. Он возводится в степень, и если противоположная сторона тот час удаляет экспоненту, то вбрасывающий, не зная ее, никак не может показать связь между своим next_dh и полученным общим секретом (для этого ему необходимо решить задачу дискретного логарифмирования).
Есть еще один подозрительный момент на этапе AKE: использование подписей. Пока не осознал, чем это может быть чревато, но во всяком случае, общий секрет на выходе AKE, похоже, можно связать с публичным ключом одного из участников при компрометировании второго до окончания AKE.

— gegel (24/12/2013 23:31)   
После изучения кучи работ по взаимной аутентификации (спасибо unknown) созрело очень простое решение, пригодное для адаптации OTR к высоколатентной среде Email.
Как отмечают сами авторы OTR (раздел 6^[link27]),их протокол неудобен для почты из-за интерактивных процедур начального согласования ключей и аутентификации (SIGMA^[link28] IKE требует четыре прохода и SMP – еще четыре (Appendix A^[link25])). Появилась идея сократить количество проходов IKE всего до двух «холостых» сообщений (запроса на отрицаемую беседу и разрешения) и полностью отказаться от SMP за счет использования идентификации участников по PGP PKI (использование PGP вполне естественно для Email, в отличие от IM). В предлагаемом варианте за основу взята SKEME^[link29], а также протокол Abadi^[link30], но c оригинальными изменениями.

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

Цель: сократить процедуру взаимной аутентификации с полной отрицаемостью до двух сообщений.

Новизна: выполнение Диффи-Хеллманн внутри PGP (без подписей, желательно в режиме --throw-keyid, целостность обеспечивается mdc).

Решение: X, Y – DH-паблик значения.

A->B: PKE _B (X, Pub _A)
B->A: PKE _A (Y, Fig _B)

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

а) полученное значение s может быть известно только второй стороне и никому другому (т.к. половинка секрета отправлялась через PGP конкретному адресату, и никак не могла попасть в чужие руки);

б) если кто-то докажет знание s, то он и есть нужный адресат (вытекает из предыдущего утверждения);

Далее: r1, r2 – уникальные случайные значения (в данном случае шифротекст, полученный с ключoм, выведенным из s и случайным IV).

A->B: r1, HMACs(r1)
B->A: r2, HMACs(r2)

Выводы:

1. Любая из сторон уже после первичного PGP-обмена может зашифровать сообщение и получить r, будучи уверенным, что никто, кроме второй стороны, не сможет его прочитать (обеспечивается конфиденциальность). Это вытекает из утверждения а).

2. Получатель, сверив MAC, уверен, что отправитель – нужный адресат и никто другой (обеспечивается аутентификация). Это исходит из утверждения б).

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

4. Отправитель уверен, что полученное в PGP-сообщении значение DH-паблик не может его скомпрометировать: при вычислении s оно возводится в степень приватной экспоненты (выбранной самим отправителем и доверяемо рандомной), т.е. для доказательства следов DH-паблик в s надо вычислить дискретный логарифм (обеспечивается устойчивость к вбрасываем значениям изначально злонамеренным контактом).

Если приведенный протокол не будет жестко раскритикован, покажу, как обеспечить malleability, repudiability и PFS (используя оригинальный протокол OTR), а также FS в пределах окна ключей (для обеспечения устойчивости сессии к потерям сообщений в условиях высоколатентной среды).

Также есть идеи:

– добавить механизм отрицаемой подписи (в том числе для обнаружения MitM при утечке приватных PGP-ключей одного или обоих участников при наличии частично надежного дополнительного канала (прослушиваемый телефон) при взаимном недоверии сторон;

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

— unknown (25/12/2013 09:50)   

A->B: PKE _B (X, Pub _A)

B->A: PKE _A (Y, Fig _B)

Что такое Fig?

— gegel (25/12/2013 10:40)   
Извиняюсь, имелся в виду отпечаток публичного ключа. Вообще там могут быть любые идентификаторы участников, имеющие отношение к их приватным ключам. Я исходил из того, что если Алиса – инициатор, то Боб может не иметь ее публичного ключа, поэтому есть смысл вложить его в первое сообщение. Боб может вложить только отпечаток своего ключа с целью идентификации своего сообщения как ответа на запрос Алисы (т.к. понятно, что Алиса уже имеет сам ключ Боба).

— unknown (25/12/2013 11:39, исправлен 25/12/2013 11:50)   

Ну тогда id_a или просто A — как известное имя, чтобы знать, от кого запрос.

Так всё-таки к публичным только наверное?

Если стороны заранее не знают (отпечатков) открытых ключей друг друга, то возможен MITM. Ну или просто будет разговор Боба непонятно с кем, кто выдаёт себя за Алису.

— gegel (25/12/2013 12:18, исправлен 25/12/2013 12:26)   

Ну тогда ida или просто A — как известное имя, чтобы знать, от кого запрос.

Да, именно так.

Так всё-таки к публичным только наверное?

Просто я рассматриваю публичный+приватный ключи как единое целое. Конечно, id указывает на публичный ключ и показывает факт владения соответствующим приватным.

Если стороны заранее не знают (отпечатков) открытых ключей друг друга, то возможен MITM. Ну или просто будет разговор Боба непонятно с кем, кто выдаёт себя за Алису.

Да, все так, ведь аутентификация полностью основана на PGP. Но представим реальную ситуацию, когда Алиса начинает беседу и хочет остаться псевдонимной (или раскрыться позже), но быть изначально уверенной в личности Боба. Она заводит новую ключевую пару, и должна вложить свой публичный ключ в сообщение для обеспечения возможности ответа. Т.к., начиная беседу с Бобом, она априори знает публичный ключ и отпечаток Боба, то Бобу достаточно вложить свой отпечаток (или другой id) для идентификации отправителя ответа.
К счастью, с предлагаемым протоколом в данной ситуации MitM невозможен, т.к. Алиса пишет Бобу, идентифицировав его публичный ключ. В этом сообщении уходит DH-половинка. Получить его может только Боб, и никто другой. Из этой половинки в дальнейшем выводится s. И если ее подменить, то позже аутентификация просто не пройдет.

— unknown (25/12/2013 15:36, исправлен 25/12/2013 16:53)   

X = g^a mod p
Y = g^b mod p
s = KDF ( g^a )^b mod p = KDF ( g^b )^a mod p

Обычно принято в ответ частично включать предыдущий запрос:

A → B: PKE_B (id_A, X, r₁)
B → A: PKE_A (id_B, X, Y, r₁, r₂, HMAC_s (id_B, r₁, r₂) )
A → B: PKE_B (id_A, r₁, r₂, HMAC_s (id_A, r₂, r₁) )
B → A: PKE_B (id_B, r₁, r₂, HMAC_s ( HMAC_s (r₁), HMAC_s (r₂) ) )

Тогда четвёртый шаг даже не нужен.

Всё-таки, как конкретно r₁ и r₂ получаются — не совсем понятно. Если их можно выбирать произвольно, то всё упрощается. А как то хитро детерминированно от s — непонятно чем обосновать.

Алиса просто загадывает уникальный r₁ в начале и никто кроме Боба не сможет вернуть ей правильный ответ, включающий в себя такой же r₁, если mdc стойко защищает сообщения. Аналогично и Боб может получить только от Алисы правильно подтверждающий ответ на свой сразу же посланный r₂ .

На всякий случай лучше проверять на соответствующих шагах, что: id_A ≠ id_B ≠ r₁ ≠ r₂

— gegel (25/12/2013 20:45)   

Обычно принято в ответ частично включать предыдущий запрос

Именно это мне очень не хотелось бы делать (если можно): не особо хочется отсылать обратно возможно вброшенное значение.

В протоколе Abadi запрос в ответ включается, но подчеркнуто, что протокол для "честных" участников. В SKEME – нет.
Ваш вариант похож на SKEME, но с объединенными этапами.

Всё-таки, как конкретно r1 и r2 получаются — не совсем понятно

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

Все эти извращения понадобились мне для максимального сокращения фазы аутентификации и использования PGP. В моем случае:
1. Алиса отсылает запрос на беседу, используя PGP.
2. Боб отсылает разрешение на беседу, используя PGP

3. Теперь каждый участник может отсылать другому шифротекст (он и есть r) без использования PGP. Т.к. шифротекст создан со случайным непресказуемым IV, он неотличим от рандома.

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

— unknown (26/12/2013 09:59, исправлен 26/12/2013 11:04)   

В моём варианте, Алиса убеждается в правильности согласования параметров с Бобом уже по его ответу на втором шаге.

Алиса может отправить сообщение SE-MDC, шифрованное ключом s уже вместе с третьим шагом. Боб проверяет правильность третьего шага от Алисы через PKE-MDC и если проверка проходит, то он может расшифровывать сообщение GnuPG SE-MDC, посланное Алисой на этом же шаге параллельно.

Теперь каждый участник может отсылать другому шифротекст (он и есть r) без использования PGP. Т.к. шифротекст создан со случайным непресказуемым IV, он неотличим от рандома.

Этого и хотелось избежать, чтобы не надо было самому городить аутентифицированное симметричное шифрование. А так есть тоже самое что PKE-MDC, только SE-MDC (symmetric encryption) от GnuPG.
Ну можно на третьем шаге перейти и на самопальное аутентифицированное шифрование с ключом s, если вас формат GnuPG чем-то не устраивает.

Т.е., пусть уж рэндомные числа (nonce) останутся не более чем рэндомными числами для проверки запросов через MDC и HMAC, а шифрованные сообщения пойдут отдельно после согласования. Число шагов, заметьте — такое же.

Как минимум, replay-атаками.

— gegel (26/12/2013 11:02, исправлен 26/12/2013 11:26)   

Этого и хотелось избежать, чтобы не надо было самому городить аутентифицированное симметричное шифрование.

А придется. Дело в том, что приведенный фрагмент – это лишь начало протокола, а дальше будет классический OTR (ведь нужна PFS), как описано в разделе 4.1^[link27].
Это старый протокол OTR, а в новом изменили (добавили) SIGMA-аутентификацию из-за обнаруженной identity misbinding атаки. Мой вариант аутентификации с использованием PGP устойчив к этой атаке (mdc препятствует подмене идентификатора), но не был использован в OTR, как я понял, из-за нежелания смешивать PGP с IM.
Я попытаюсь расписать весь протокол отрицаемого шифрования Email, как я его вижу в целом, тогда будет более понятнее общая идея, что, возможно, оправдает средства.

Число шагов, заметьте — такое же.

Сходу не понял, сейчас попытаюсь осознать, что с чем объединять.

Как минимум, replay-атаками

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

— unknown (26/12/2013 11:32, исправлен 26/12/2013 11:33)   

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

Противник запишет сеанс и когда Алиса будет связываться с Бобом, пошлёт Бобу старое сообщение якобы от Алисы, со старым X:
A->B: PKE _B (X, Pub _A)
Алисе пошлёт старый ответ якобы от Боба со старым Y:
B->A: PKE _A (Y, Pub _B)

Алиса отправит сообщение, думая, что отправляет Бобу.

Боб мог бы получить старый r1, хотя и не сможет расшифровать его из-за подмены (он то отправлял точно новый Y).
A->B: r1, HMACs(r1)

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

— gegel (26/12/2013 11:56)   

но как бы из этого не вывели различитель

Вот это то, что я предполагал услышать, рассуждая где-то аналогично. Напрягусь, подумаю.
Цель определена: сократить подготовку к беседе до двух сообщений: запроса (от инициатора к акцептору) и согласия (обратно). Желательно использовать PGP только в этих сообщениях. А дальше – так или иначе быть готовым писать информационные сообщения и принимать их.
Возможно, Ваша идея объединить шаги завершения аутентификации с nonce и отправки первых сообщений и есть искомое решение.

— unknown (26/12/2013 11:56, исправлен 26/12/2013 12:05)   

A → B: MDC_PKE_B (id_A, X, r₁)
B → A: MDC_PKE_A (id_B, X, Y, r₁, r₂, HMAC_s (id_B, r₁, r₂) )

После получения ответа на втором шаге, Алиса уже аутентифицировала Боба по отношению к своему запросу.

Следующие две отправки Алиса посылает параллельно:

A → B: MDC_PKE_B (id_A, r₁, r₂, HMAC_s (id_B, r₁, r₂), HMAC_s (id_A, r₁, r₂) )
A → B: MDC_SE_s (id_A, Message)

Если Боб не может аутентифицировать Алису по первой отправке, то он и не станет (и не сможет) расшифровывать вторую отправку.

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

P.S. На третьем шаге решил не менять местами r₁ и r₂ внутри HMAC, надо только следить, что никакие из пар id и r не совпадают.

— gegel (26/12/2013 12:04)   

как бы из этого не вывели различитель

Похоже, упрется в проблему дискретных логарифмов.

— gegel (26/12/2013 12:20, исправлен 26/12/2013 12:21)   

А как Вы смотрите на то, чтобы в вашем примере в качестве r1,r2 в MAC-функции использовать те же X,Y? Ведь они тоже доверяемо рандомны:
HMAC _s ( id_A, X, Y)? Или при этом возможна непредсказуемая интерференция межу DH и HMAC, от греха по дальше?

— unknown (26/12/2013 12:30, исправлен 26/12/2013 15:27)   

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

Вроде так будет экономнее по числу и размеру полей:

A → B: MDC_PKE_B (id_A, X)
B → A: MDC_PKE_A (id_B, X, Y, HMAC_s (id_B, X, Y))
A → B: MDC_PKE_B (id_A, X, Y, HMAC_s (id_A, X, Y)); MDC_SE_s (id_A, Message)

По сравнению с вашим вариантом:

1. Число шагов такое же: запрос – ответ – ответ исходной стороны с отправкой сообщения.
2. Вся проверка аутентификации идёт только внутри GnuPG MDC_PKE.
3. Вся аутентификация только на nonce или параметрах DH, не связанных с самими сообщениями в окончательном виде.
4. Отправка сообщения от A идёт только после прохождения стадии аутентификации B. A не высылает сообщение кому-попало, даже в шифрованном виде.
5. После аутентификации можно перейти на MDC_SE как на самом GnuPG, так и на другую схему симметричного рэндомизированного шифрования с аутентификацией.

2,3,4 повышают надёжность реализации. 3 и 4 — устраняет смешивание протоколов (стадия аутентификации отдельно, стадия шифрования отдельно, а не внутри одного протокола — проще анализировать, в данном конкретном случае). 5 — делает реализацию более гибкой.

— gegel (26/12/2013 19:49)   
Смотрел на то, к чему мы пришли в итоге, и вдруг дошло: а ведь получилась в точности SIGMA! (Page 7^[link28]).

Потом посмотрел еще дольше, и с удивлением понял: если отбросить все, начиная с HMAC во второй строчке, то получится протокол Abadi (Page 4^[link30]), с той разницей, что общий секрет выводится не хешированием половинок, а DH. Причем стойкость этого протокола формально доказана, и вроде как критики не было.

Просматривая условия выполнения протокола Abadi (пункт Cryptographic на стр.3), я так и не понял, подразумевается ли обеспечение целостности сообщений (mdc), но в любом случае в нашей модели PGP это обеспечивает.
Как Вы считаете, может, этого будет достаточно? (тем более, что в одном из постов давали ссылку на протокол Abadi, как перспективный).

— unknown (26/12/2013 21:19)   
А в итоге непохоже ни на то, ни на другое. В SIGMA используется MAC совместно с подписями. У Abadi всё как-то мутно — и выведение секрета (там вроде как нет отвязки от ключей через DH, а сразу выводится общий симметричный ключ) и работа, и презентащка, и система доказательств.

Получилось нечто среднее между SIGMA и Abadi. К тому же ни там, ни там не используется специфическая фича — mdc или она заменяется чем-то другим (подразумевается аутентифицированное шифрование в некоем другом абстрактном исполнении).

К тому же вариантов SIGMA и Abadi — много. Также как мы тут насочиняли сходу массу похожего.

К тому же, в SIGMA понятна идея помещать айдишники внутри MAC, несмотря на аутентификацию подписью всего сообщения целиком.

— gegel (26/12/2013 22:12, исправлен 26/12/2013 22:32)   

У Abadi всё как-то мутно — и выведение секрета (там вроде как нет отвязки от ключей через DH, а сразу выводится общий симметричный ключ)

Мутно – да. Сейчас внимательно перечитываю полную версию^[link24]. В принципе, выводы созвучны с моими, а вот что такое applied pi calculus, и на сколько эти доказательства надежны, я, конечно, не могу судить. Работа свежая (там SKEME цитируется), вполне возможно, пока не дошло дело до критики. Но идея мне нравится, можно рискнуть и попробовать реализовать. Заменить хеширование половинок на DH не проблема, не вижу причин, почему нет: кашу маслом не испортишь...

Пока это всё равно бездоказательный черновик.

Боюсь, что так все и останется, если не рисковать. Как Вы тонко когда-то заметили, если бы не было оптимистов-практиков, то все бы до сих пор пользовались одноразовыми блокнотами.

Поэтому есть идея сделать тестовый консольный софт под Linux, а там, возможно, кто-то заинтересуется и наши идеи оценит раскритикует.

Как на счет следующих криптопримитивов:
– ассиметрика: ECDH Curve25519 (все же размеры DH-паблика критичны);
– симметрика: Serpent-128 (на 256 ECDH не тянет), к AES как то душа не лежит;
– хеши: PKDF2, HMAC-SHA256
– PRNG: внутренний HMAC_DRBG, сидируется при каждом старте (т.е. при каждой операции с сообщением), с ориентировочной оценкой ентропии до заданного уровня (типа как у Yarrow), получаемой из девиации интервала между нажатиями клавиш. Если будет не юзерофильно, то, возможно, добавлять меньше энтропии, но сохранять seed-файл.

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

— unknown (26/12/2013 22:41)   

Как Вы тонко когда-то заметили, если бы не было оптимистов-практиков, то все бы до сих пор пользовались одноразовыми блокнотами.

Маловероятно, что буквально так и это не была ирония, вынутая здесь из контекста ;-)


Всё-таки это будет чат, а не почта?


Его нет в стандартных криптолибах. Ни в OpenSSL, ни в libgcrypt. А другие в кроссплатформенный проект пока тянуть не рекомендуется.

— gegel (26/12/2013 23:35, исправлен 26/12/2013 23:47)   

Всё-таки это будет чат, а не почта?

Почта (типа GPG), но с реализацией OTR. Т.е. внутри каждого письма будет и DH-паблик, и старый MAC-ключ (публикация неиспользуемых MAC-ов для repudiability), и еще пару фишек (большинство решений из OTR, я их реализацию разобрал "по косточкам"), адаптированных к Email. Я постараюсь схематично набросать весь предполагаемый протокол, а потом – и полную подробную его реализацию. В отличие от OTR, хочу сделать FS в пределах ключевого окна (чтобы выдержать правило: для каждого сообщения – всегда новый ключ, по меньшей мере выведенный из предыдущего).
Больше всего места займет DH-паблик (как минимум 2048 бит для обеспечения 128-битной секретности). А для ECDH – всего 256.

Его нет в стандартных криптолибах.

Скачал референс-код^[link31] с домашней странички^[link32], скомпилировал под Ubunta (gcc) и Win32 (MSVC6 и BCB), сверил тест-вектора^[link33] – все ОК.
Может, это и непрофессиональный подход, но я всегда пытался по максимуму запихнуть в исходный код, чтобы уменьшить зависимость от внешних либ. Имея исходный код, даже начинающий программист может всегда проверить тест-вектора любых используемых примитивов и убедиться в их валидности, тем более что этих примитивов – кот наплакал.

— ntldr (27/12/2013 03:06)   

– PRNG: внутренний HMAC_DRBG, сидируется при каждом старте

Скоро представлю свою реализацию этого, включая множественные источники энтропии.
Предварительная версия^[link34] реализации SHA512-HMAC-DRBG, комментарии насчет качества кода приветствуются.

— unknown (27/12/2013 09:55, исправлен 27/12/2013 09:56)   

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

В Torproject так делают, но только если алгоритм ожидается во внешних либах, но пока ещё не появился в стабильных версиях.

/comment75083^[link35]

Скорее SKEME^[link22] или гибрид SKEME, SIGMA и GnuPG-mdc.

— gegel (27/12/2013 11:05)   

Скорее SKEME

Да, ошибся: в SIGMA используются подписи вместо MAC. Но подписывается то же, что у Вас MAC-ается.
После тщательного гугления я все таки склоняюсь к протоколу Abadi: очень серьезный теоретический базис (правда, ни одной практической реализации в софте не нашел).

Предварительная версия реализации SHA512-HMAC-DRBG

Спасибо, очень интересно, буду разбираться.

— unknown (27/12/2013 11:19, исправлен 27/12/2013 11:48)   

Или попытка больше продвинуть именно такой базис, а не сам протокол. Его метод доказательств мне неизвестен, в мейнстримной криптографии он (пока?) не используется.

Собственно, как хотите. Мне как-то Кравчик понятнее. Чтобы не гонять одни и те же параметры кроме id, как у Кравчика и показано, и вернуть перестановку параметров внутри MAC, я пока бы остановился на таком:

X = g, p, g^a mod p
Y = g, p, g^b mod p
s = KDF ( g^a )^b mod p = KDF ( g^b )^a mod p

A → B: MDC_PKE_B (id_A, X)
B → A: MDC_PKE_A (id_B, Y, HMAC_s (id_B, X, Y))
A → B: MDC_PKE_B (id_A, HMAC_s (id_A, Y, X)); MDC_SE_s (id_A, Message)

С проверкой на неравенство всех пар id, X и Y между собой, ну и параметры DH тоже проверять, как положено.

Для этого можно даже скрипт на питоне или баше написать (вокруг OpenSSL) и воткнуть прослойкой в переписку обычной GnuPG почтой, которая бы привлекала меньше внимания, чем какой-то рэндомный набор битов, полученный специальным протоколом.

— gegel (27/12/2013 12:57)   
К сожалению, я не работал со скриптами, поэтому для меня намного проще написать отдельно симметрику на С. Хотя, конечно, можно использовать консоль GnuPG из своего С-кода.
По поводу предложенного Вами варианта: я так понимаю, после получения ответа от Боба, Алиса, сверив МАС, уверена в идентичности Боба и в их расшаренном секрете. Третий этап нужен исключительно для того, чтобы уверить в себе Боба.
Отсюда вопрос: если Алиса просто отошлет MDC_SE _s (Message), разве это не убедит Боба в личности Алисы? Учитывая, что s используется строго однажды. Я понимаю, что мой подход (найти подходящую атаку) неакадемичен, и надо искать отличие от идеальной модели, и тем не менее хочется руководствоваться здравой логикой.

— unknown (27/12/2013 13:24, исправлен 27/12/2013 14:29)   

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

A → B: MDC_SE_s (id_A, "Hello Bob!")

Мэллори перехватывает и пересылает обратно Алисе.

B → A: MDC_SE_s (id_A, "Hello Bob!")

A → B: MDC_SE_s (id_A, "WTF? Are you fucking kidding me?")

Мэллори конечно не знает, что там точно написано, но может попытаться нарушить ход общения.
Вот например, это Мэллори возьмёт и переотправит. Или вставит в середине разговора от имени Алисы.

— gegel (27/12/2013 21:38, исправлен 27/12/2013 21:41)   

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

Спасибо, четко и понятно. Убедили, однозначно примеряю Ваш вариант к планируемому протоколу.

Мэллори перехватывает и пересылает обратно Алисе.

Вообще-то я исходил из того, что ключ никогда не будет использован для шифрования/дешифрования дважды. Всегда выводится новый ключ шифрования: или из полученной и своей DH (рутовый), или из старого ключа хешем с увеличением на 1 его индекса (в пределах ключевого окна, это будет отличие от OTR). Использованный ключ тот-час безвозвратно удаляется. То же для дешифрования: если ключ подошел, он тот час заменяется хешем и увеличивается на 1 его индекс. Исходя из разницы индексов, хешируем имеющийся декрипт-ключ требуемое к-во раз перед дешифрованием (ведь могли быть потери сообщений).

Но от греха подальше, буду делать, как положено, т.е. подписывать параметры в точности как Вы предложили. Надеюсь, это не повредит отрицаемости (надо подумать).

Возник вопрос по поводу id: на сколько критично держать его под mdc:
– в первой части третьего сообщения под MDC_PKE
– во второй части третьего сообщения (шифротекст) под MDC_SE
Я все-же пока планирую симметрику с маком (начиная с третьего сообщения). Т.е. можно ли вынести id из-под мака во второй части? Можно ли просто прилепить его к HMAC в первой?

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

— unknown (28/12/2013 16:36)   
Всё таки MDC обеспечивает только целостность, поэтому строгая аутентификация параметров должна быть по MAC. Даже у Кравчика написано, что id должен быть строго внутри MAC, даже если всё сообщение заверено подписью. Наконец, формальное соображение, результат внутри MAC должен отличаться. Это обеспечивается соответствующими разными id на разных шагах и перестановкой X и Y. Перестановка носит скорее перестраховочный характер. Наконец, в MDC_SE должно быть понятно, какая из сторон отправила сообщение. Иначе Боб кто-то может получить обратно своё же сообщение.

— gegel (29/12/2013 15:34, исправлен 29/12/2013 15:43)   

В который раз внимательно перечитал презенташку по SIGMA^[link28], сравнил с предложенной Вами схемой^[link36] и рассуждаю следующим образом:
В начале стр.9 приведен исходный SIGMA (отдельно sig и mac). На стр.10 Кравчик определяет роли: sig защищает от изменения DH publics (MitM), а mac – от атаки подмены идентичности (DVW, описана на стр.6). У нас функцию sig как бы выполняет целевое PGP-шифрование (вместо "это я, Алиса, ввожу данное значение" будет "только он, Боб, может его получить"), что для DH зеркально и эквивалентно. Функцию mac у нас выполняет mdc, таким образом, DWV в виде, описанном на стр.6, уже невозможна. Рассуждая так, можем плавно превратить пиджак в брюки предложенную Вами схему в тот же протокол Abadi. Серьезные проблемы в этом случае начнутся при утечке одного из приватных ключей. SIGMA (и Ваш вариант с маками) в таком случае все равно остается устойчив и к DWV, и к MitM, т.к. изначально предназначен для работы без mdc.

Поэтому пришел к таким ответам на свои же вопросы:
– в первой части третьего сообщения Id можно выносить из-под MDC_PKE, т.к. он входит и в mac, что препятствует его подмене. Но при этом он будет разглашен, что нежелательно.
– во второй части третьего сообщения (шифротекст) Id тоже можно выносить из-под mdc, т.к. на данном этапе s уже аутентифицирован, а корректность расшифровки обепечивается MDC_SE. Но опять же, нежелательно по той же причине.
Т.е. в принципе, Id тут нужны, я так понимаю, только как указатель на отправителя. Таким образом, для Вашей схемы идеальным будет все же предложенный Вами вариант.

Но есть проблема: в MDC_SE должно быть сразу понятно, кто отправитель сообщения.
Похоже, Вы постоянно исходите из того, что s однажды согласован и не меняется. Но, как я писал выше, для обеспечения PFS на каждое сообщение будет новый ключ. Как вы предлагаете расшифровывать SE c Id внутри, полученное, скажем на Tor HS Алисы, если она переписывается параллельно с многими собеседниками? Пробовать все имеющиеся s для всех контактов? Все же лучше, если снаружи SE будет какой-то id. Я предполагаю использовать снаружи не постоянный id, а временный tid, выведенный из s (если это не противоречит безопасности), определять по нему отправителя и нужный ключ из имеющихся. Тогда, по идее, внутри SE id как бы и не нужет, т.к. корректность расшифровки все равно обеспечивается mdc.

— Гость (04/01/2014 20:56)   

В тему:

Т^[link38]ор не умеет отвечать ни на что кроме как A-запись через свой днс порт, потому что тор не умеет передавать сложные запросы экситам. Проблемы могут быть к примеру с подключением к джабер серверу, т.к. использует свои записи.

Ещё см. это^[link39] и это^[link40].

— gegel (11/01/2014 21:20)   
Потихоньку ваяю шифровальщик почты, появился нетривиальный вопрос, хотел услышать мнения.

В протоколе OTR ключ аутентификации выводится непосредственно из ключа шифрования как один из способов обеспечения отрицаемости содержимого сообщения: в разделе 2.1^[link27]

The MAC key used is a hash of the decryption key for that message. This way anyone who can decrypt the message can also forge a correct MAC tag, but an adversary unable to decrypt messages cannot.

Это входит в неразрешимое противоречие с рекомендацией неотличимости шифроключа от рандома, например, в цикле лекций Кравчика (кстати, очень информативном и поучительном): p 24, slide 56, 57^[link41]

Secrecy: If E learns anything about the session key then it can distinguish it from random.

Вопрос в том, чем пожертвовать: защитой или отрицаемостью? Как сопоставимы последствия того или другого решения в целом конкретно для модели Email?

— Гость (11/01/2014 21:46)   
Я так понимаю, вы хотите чтобы не было критериев останова при брутфорсе ключа? В реальных условиях это недостижимо. Если шифруется не рандом, критерием правильности ключа будет снижение энтропии результата расшифрования.

— unknown (11/01/2014 23:21)   

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

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

А вот то, что там в слайдах много чего понаписано вызывает некоторое сомнение в способностях создать безопасный протокол. Если опираться на шифрование OpenPGP-MDC, является ли оно заменой MAC со всеми требованиями к неразличимости? Если ли утечка при изменении размера имени, ограничивается ли она только размером блока шифра? При перестановке параметров всё ли останется безопасным в этом MDC-контейнере?

— gegel (11/01/2014 23:40)   

Я так понимаю, вы хотите чтобы не было критериев останова при брутфорсе ключа?

Именно. Но с энтропией – убедительно.

Если опираться на шифрование OpenPGP-MDC

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

— Гость (12/01/2014 00:18)   

Есть ли утечка при изменении размера имени
Fxd

— unknown (12/01/2014 14:31, исправлен 12/01/2014 14:34)   

Вот я как раз и думал об PGP mdc, что оно ну никак не соответствует идеалам, и тем не менее стойко.

Стойко пока. Потому что Кравчик его ещё не посмотрел. А может посмотрел, поморщился и не заинтересовался :)

выводить ключ аутентификации из ключа шифрования хешированием теоретически допустимо?

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

Я внимательно прочел все три лекции Кравчика и там критикуется абсолютно все, что есть на сегодня. Весьма пессиместический подход.

И правильно. Потому что всевозможные SSL, VPN, отчасти OpenPGP — шифрпанковский ужас, который пролез в неформальные стандарты за неимением лучшего.

— Гость (12/01/2014 14:42)   

Или вставит в середине разговора от имени Алисы.

какова ценность такой вставки, если смысл ее не в контексте общения?

— unknown (12/01/2014 15:44, исправлен 12/01/2014 15:44)   

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

Это как с неидеальностью старых хэш-функций. Тоже думали, зачем делать универсально неразличимую во всех сценариях конструкцию? А затем пришлось придумывать множество костылей и подпорок для использования в реальных протоколах. Реализация абстракции должна быть как можно ближе к идеалу, неразличимее от него, чтобы «не протекала».

— gegel (13/01/2014 02:49)   
unknown, а что Вы думаете по поводу протокола согласования ключей HMQV? (p.18, slide 40^[link42]). Была найдена и исправлена уязвимость, и на сегодня есть FHMQV^[link43] на эллиптических кривых (правда, только в либе Crypto++, и пока патчем). Вообще-то он идеально подходит для задачи, которую мы тут обсуждали раньше: статический публичный DH-ключ FHMQV-протокола даже можно было бы каждый раз создавать в начале беседы, подписать своим PGP и отправлять контакту. Затем уничтожать после FHMQV-согласования ключей: так даже надежнее в плане утечек.

— unknown (13/01/2014 10:22)   

Более важно то, что Менезис нашёл аргументы данной работы ошибочными. Кравчук утверждал, что модифицированная система согласования ключей увеличит свою эффективность без проведения дополнительной проверки безопасности (называемой "валидацией публичного ключа"), которая была добавлена в MQV для предотвращения известных атак. У него было "доказательство" безопасности, которое дало ему уверенность в этом. Но Менезис быстро нашёл, что несомненно HMQV уступает протоколу MQV перед теми же самыми атаками, которые возможны на MQV, если в него не включить дополнительную проверку безопасности. После того как стало ясно, что некоторые выводы теорем Кравчука были ошибочны, Менезис стал читать "доказательство" внимательнее, пока не нашёл вопиющий изъян в аргументации.

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

© Коблиц

После прочтения статьи Нила Коблица в последнем номере "Заметок AMS", я считаю необходимым ответить на некоторые неверные и вводящие в заблуждение комментарии, сделанные Коблицем в данной статье. Это включает в себя вопиющие попытки дискредитировать целую область криптографии, основанной на теории сложности, в особенности её важный вклад, который она привносит в практику криптографии. Эта статья также содержит персональный выпад против моей работы и моего поведения, особенно в отношении разработки и анализа HMQV протокола, который я не могу проигнорировать.

© Кравчик

О непростых взаимоотношениях между математикой и криптографией^[link44].

Честно говоря, даже вынесение каких-то оценок по этим протоколам выше моей компетенции, даже не в курсе, до чего там эксперты договорились и в каком состоянии это всё находится.

Тут ещё Бернштейн подозревает кривые от НИСТ и ANSSI во всяком нехорошем:
http://safecurves.cr.yp.to/

— unknown (21/01/2014 11:31, исправлен 21/01/2014 11:59)   

Короче, если хотите создать ПО для топика и сами придумать протокол, то надо уметь писать такие работы^[link45]. Не знаю, насколько она верная во всех деталях, но это пример хорошей работы от китайцев. Там разобраны протоколы от Кравчука и их альтернативы, в т.ч. даны указания на создание протокола, очень близкого к теме топика: одноходового обмена ключами с отрицаемостью.

• Over past few years, one-round AKE protocols with PFS have been proposed based on authenticated primitives, e.g., signature and MAC etc., which loss full-deniability. An urgent work is that can we design a provable AKE protocol with PFS as well as full-deniability based on weaker primitives, e.g., proof of knowledge [24], in the PACK model.

Мне кажется, что никому из участников форума написать такую работу или выявить в ней возможные ошибки — нереально. А тем более провести её через ревью, конференции, публикации и пр.

У меня после прочтения этой работы только сейчас встали в голове на место элементарные базовые понятия о различии FS и PFS за счёт понятия Freshness, что было бы важно в обсуждении в другой теме, начиная с /comment74446^[link46]. О чём я чисто интуитивно и с подсказок оппонента догадался в /comment74895^[link47]. Но, естественно, понятие Freshness для различения FS и PFS сам я ввести не мог. И ни о какой грамотной формализации протокола не могло быть и речи — при незнании базовых понятий.

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

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

— gegel (21/01/2014 14:29)   
Спасибо за очередную ссылку. Я очень бегло прочел и понял, что иду тем же путем. За основу взял проект tabby^[link48] (похоже, ефемеральные ключи и хеши там используются в точности так же, как и китайцев). Tabby хорошо документирован, интуитивно понятен. Единственное, что мне там не совсем понравилось, так это использование библиотеки Snowshoe^[link49] для curve25519, т.к. в ней используются публичные ключи в формате x,y (64 байта: x,y). Поэтому я нашел время вникнуть и в это (почитал Бернштейна) и сам реализовал tabby на базе урезанной библиотеки ed25519^[link50] на основе ref-кода Бернштейна (публичные ключи 32 байта: x) Вроде все получилось, тестовые вектора совпадают с Бернштейновскими^[link51], но пришлось преобразовать публичные ключи с Edwards в Montgomery.

Конечно, за 10 минут нереально вникнуть в представленную Вами статью, но мне показалось, что идея сходная: я планирую использовать DH-обмен в точности из протокола OTR (это будут Session keys в терминологии статьи), и затем для отправки сообщений использовать tabby с ефемеральным ключом, уникальным для каждого сообщения (как бы key-wrapper). таким образом, получаем идеальную PFS для отправителя (приват ефемерал удаляется еще до отправки сообщения). Для получателя создается ключевое окно до следующего обмена DH в стиле OTR. Аутентификация нужна только в самом начале (см. OTR), и я все же остановился на аналоге Abadi (с использованием PGP), но можно также использовать долговременные DH-ключи (например, для мессенжеров).

Не судите строго, т.к. я очень активно влез в чужую область знаний, но это все просто оказалось очень интересно. Подробное описание предоставлю после полной отладки c-кода и, конечно же, изучения свежей китайской работы.

— ressa (21/01/2014 16:32)   
gegel

Не судите строго, т.к. я очень активно влез в чужую область знаний

Какой судить, перед тобой только шляпу снять могу. Жду новых релизов;)

— Гость (21/01/2014 19:19)   

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

Вы думаете, эта^[link52] работа проще? Ну, или вот вот эта^[link53] с этой^[link54]? Они написаны участниками форума, как и десяток-другой иных имеющихся работ сравнимой сложности.

А тем более провести её через ревью, конференции, публикации и пр.

Упомянутые работы прошли через ревью и конференции, будучи в итоге опубликованными в ведущих мировых журналах по теме. Например, первые две работы вышли здесь^[link55], последняя — тут^[link56], даже фотоотчёт с конференции^[link57] есть. А где вышла ваша китайская работа? STOC/FOCS/Crypto? По-моему, пока её ещё нигде нет.

Не каждая профильная кафедра может похвастать тем, что у них есть сотрудники, публикующиеся в журналах этого уровня. В ведущих исследовательских московских институтах о наличии публикаций даже в журналах меньшего ранга^[link58], которыми на Западе никого не удивить (обычные журналы для обычных нормальных публикаций), говорят с придыханием, как будто это какое-то особенное достижение.

Фундаментальный бэкграунд у всех этих работ один — прикладная математика, теория информации, CS; отличается только конкретная прикладная область. При желании можно вникнуть в другую прикладную область, систему их определений (подчас доморощенных, кривых, костыльных и бессмысленных), но это требует времени и желания. Вот если бы понимание статей затребовало знания сложных областей математики, которых легко не изучить, то был бы другой разговор. В конце концов, как говорилось в интерьвю с одним математиком (перерыл весь интернет, не могу найти),

— Насколько сложно решить задачу такого класса?
— Трудно сказать. Её могут поручить аспиранту, который будет 3-4 года заниматься только этой проблемой, и в итоге продвинется дальше, чем все остальные, чем всё мировое сообщество, в итоге доведя решение до конца. Появление такого рода внезапных решений трудно предсказать.

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

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

Так можно про любую задачу сказать: раз ещё не решили, значит, бьются и решают. А если приглядеться внимательней, то есть, в лучшем случае, 2-3 научных коллектива, а то и вообще всего несколько человек, которым эта задача интересна. Другие занимаются другими задачами. Лишь очень небольшое число проблем удостаивается официального статуса трудных. Это проблемы, к которым, например, сводится решение множества других важных проблем. В криптографии можно легко придумать тысячу проблем-вопросов, ответа на которых наука не знает. Это не значит, что все они трудные (нахождение и постановка действительно трудной проблемы — само по себе уже открытие, но трудность надо доказать чем-то помимо «я пробовал, и у меня не получилось решить»; например — сведением к другим трудным задачам). Это значит (обычно) только то, что никто из квалифицированной публики серьёзно за них не брался.

Предвосхищая вопросы, скажу, что лично мне PFS неинтересна до такой степени, чтобы всё бросить и сидеть год разбираться с чужими протоколами. Тем не менее, я уверен, что за год смог бы разобраться с темой, если заниматься всё время только этим. PFS могу пообсуждать, поздавать вопросы, полистать статьи, указать на какие-то нестыковки, но не более того, личного персонального интереса к конструированию новых PFS-протоколов у меня нет.

— unknown (21/01/2014 20:41, исправлен 21/01/2014 20:44)   

По поводу ваших заслуг все в курсе, речь о специалистах в более узкой области. Хотя физиков-криптографов — достаточно много.

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

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

— ressa (21/01/2014 22:00)   
У меня есть возможность привлекать инвестиции под ИТ проекты и саму компанию-инициатора заводить в Сколково, т.е. делать ее полноценным резидентом фонда, вот только вопрос в востребованности и последующей комерциализации подобных проектов для меня не ясен, а как все понимают, в нашей стране меценатов, готовых на безвозмездной основе выделять деньги нет, хотя может просто я не встречал подобных Business Angeles..

— Гость (21/01/2014 22:13)   

Он не физик, он «консультант по ИБ»^[link59] ☺


В CS, как и в других науках, первостепенны журналы — мне был интересен этот вопрос, и я его специально выяснял. На конференцию отправляется, как правило, сжатая статья, страниц на 10 (STOC/FOCS), потому что там жёсткий лимит на число страниц, все подробности в такой статье на опишешь. Такие статьи часто даже называют «расширенный abstract». Предполагается, что после конференции вы напишете уже полную работу по теме и отправите её в журнал, хотя не все и не всегда так делают, ленясь доводить дело до конца. При сабмите работ-abstract'ов на конференции и при сабмите статей есть требование к оформлению ссылок: если работа уже вышла как журнальная публикация, а не только как труд конференции, она должна быть процитирована как ссылка на журнал, за этим следят. Т.е. преференцию журналов с их полными статьями и развёрнутой трактовой проблемы признают, хотя быть принятым на конференцию труднее, чем в журнал. Вам понятно, что IACR — это не журнал?

Кроме того, к конференционным трудам вы не можете написать комментарий, если нашли ошибку в чужой статье. Максимум, вы можете подготовить отдельный доклад по теме нахождения ошибки и выступить с ним на этой же конференции позже, в другой год. Однако, если результат закоммичен в виде журнальной статьи, есть официальные comments, которые рассматривает редактор, и которые, возможно, даже проходят реферирование внешними оппонентами при надобности. Т.е. если кто-то накосячил в журнальной публикации, и я нашёл у него ошибку, я могу срубить на публикации этой ошибки новую публикацию для себя. Эта новая comments-публикация, даже если состоит из одного абзаца — официально признаваемая статья, её можно указать в CV, в списке публикаций, у неё есть журнальные номера томов/страниц, на неё можно ссылаться. А как поймать за хвост того, который наговорил кучу всего на конференции? А вот никак, несмотря на престиж конференций.

Вспомните, что писал Голдрайх про конференции (пост убит^[link60]): PC просто формирует «программу конференции»: он не «судит» работы, а только отбирает те, которые ему «больше понравились». Конечно, у хороших работ шансов понравиться больше, но это не тщательное судебное разбирательноство, как то, что идёт в журналах, где вы можете сраться со своими офиициальными анонимными оппонентами, редактором и даже жаловаться наверх главному редактору на то, что редактор по вашей секции журнала завернул вашу статью (это всё официальные возможности; как это делать, описано на сайтах журналов). Если вы послали работу на конференцию, и её не приняли, вы часто даже не знаете, почему; вам не отправляется никакого ответа с критикой. В некоторых случаях его отправляют, но у вас нет возможности на него ответить, даже один раз (разве что вы будете неофициально писать письма в PC с требованием разобраться).

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

Кстати, что касается шифрпанка, вы же сами говорили о том, что часть из них потом стали «академиками», начав заниматься исследованиями на вполне приличном уровне с другими соавторами. Помимо ярких неукладыващихся в общую картику примеров Меркля, Визнера и Диффи есть и другие, просто не такие громкие, когда у человека были действительно интересные идеи, опережающие своё время, но продвинуть он их смог совсем не сразу, и до этого момента его в лучшем случае непонимали, а в худшем — откровенно смеялись.


Нужна научная школа и традиции, общепризнанные основы, а судя по той точки зрения, что вы здесь на форуме привили, криптография от этого далека. Даже на уровне основ в одной и той же области работает несколько школ, совершенно непонимающих друг друга, чего в других областях знаний (той же математике) просто немыслимо. И я сомневаюсь, что положение скоро исправится. Возможно, криптографию как отдельную науку со своими «методами» упразднят точно так же, как когда-то упразднили евгенику, заменив её научно обоснованной генетикой. Т.е. просто покажут, что криптография — новый раздел формальной математики (теории сложности), и все проблемы криптографии могут быть сформулированы как формальные вопросы в рамках этой математики. Может быть, получится как с Ньютоном: известная история гласит, что он в своё время ввёл понятие производной, тем самым заложив основы анализа, для решения задач на механику. Но мы же сейчас понимаем, что никакой особой производной в механике нет, это просто применение анализа (математики) к конкретной задаче.

P.S. Я, кстати, собирался перечитать прочитать обсуждения в этом топике, но много их, сложные, поэтому вынес на потом.

— Гость (21/01/2014 22:24)   

У меня нет вопросов с востребованностью и успешной коммерциализацией при условии, что это «будет сделано», но нейтральный (не под ФСБ) бизнес на безопасности в России невозможен (наверное, даже в Сколково; вон, не зря же люди скрывают^[link61]). К тому же, людские ресурсы могут не окупать такие бюрократические препоны^[link62].

— ressa (22/01/2014 00:15)   
Не могу ничего утверждать на счет нейтральности. Дело в том, что даже операционный контроль не отдадут. Ну ок, я смогу решить этот ворос, но смысл? К тому же, самый вероятный исход событий – после первых неплохих бонусов, добровольно-принудительно передать исключительную лицензию и право на дальнейшую разработку с последующей выплатой роялти, либо периодического бенефита, оставаясь в роли ведущего разработчика уже чужого проекта. Это все, с учетом того, что я обошел упомянутые выше моменты, т.к. на практике я с подобным дела не имел. Не знаю, как там действует ФСБ и прочие, знаю, что есть способ обхода всех косяков, но это все уже будет не альтруизм и полное погружение в проект, зная, что он лишь на благо, а всего лишь неплохой финансовый инструмент, способный дать толчок для небольших своих проектов и не более..

— Гость (22/01/2014 04:02)   
Знаменитые 10 правил^[link63] ведения бизнеса в России от ifolder'а сейчас актуальны, как никогда. К ним можно добавить разве что последние два:

11. Не работайте с клиентами из России (если не хотите, чтобы к вам и вашей компании были какие-то претензии в России).
12. Не приезжайте в Россию (по тем же причинам).

— unknown (22/01/2014 09:54)   

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

Отдать проект коммерсам и контролирующим их службам на съедение в обмен на печеньки.

— sentaus (22/01/2014 11:05)   

Отдать проект коммерсам и контролирующим их службам на съедение в обмен на печеньки.

Судя по тому, сколько акций обычно остаётся у основателей успешных проектов, когда эти проекты становятся успешными, это обычный путь развития :)

— ressa (22/01/2014 13:43)   

Знаменитые 10 правил ведения бизнеса в России

*IT-бизнеса.

Отдать проект коммерсам и контролирующим их службам на съедение в обмен на печеньки.

Ну я более завуалировано описал, но тоже прямо. Это двояко, нужно понимать, какую роль человек занимает под солнцем, один все все-равно не вытащит, и здесь "кесарю – кесарево", соответственно в коммерсах нет ничего плохого, если изначально оговорить о запрете игры в одни ворота. Приведу обезличенный пример. Как знаешь, сказки начинаются: "Жили-были...", так и я начну, только это уже не сказка: в конце 90х, начале 00х, одни парни из Питера спаяли схему и накодили софт, ну короче почти готовый мобильник вышел, немного денег было, бОльшую часть заняли, поехали на Урал и в Новосибирск искать производственные площадки в аренду, нашли, привлекли еще денег, устали отбиваться от полу-бандосовских "предложений", на рынок вывести сами не смогли, разрабы все-таки, а в команду никого не наняли. Так вот продали контрольный пакет одной московской компании, одной из дочек Согаза, та в свою очередь переформатировала разработку на голосовое управление (ну не гуглопоиск, а попроще, просто достойно точка-точка передача голоса была), и перепродали производителю мобильных, который до конца 00х был лидером на рынке, парни питерские получали, как ты сказал "свои печеньки", и занимались своими проектами, а мобильный производитель, как уже успели догадаться был Nokia. Вот скажи, как на это смотреть? Да, берет гордость, что основная изюминка передачи голоса в Nokia – наша, отечественная разработка, и в тоже время может и мы сами могли потеснить рынок. И второе – да, парни придумали, старались, а тут их так обломали своими "печеньками", но печеньки то достойные были и я думаю, если парни не дураки – сделали на них не менее достойные и уже самостоятельные проекты.

Судя по тому, сколько акций обычно остаётся у основателей успешных проектов, когда эти проекты становятся успешными, это обычный путь развития :)

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

— unknown (22/01/2014 14:12, исправлен 22/01/2014 14:13)   

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

— Гость (22/01/2014 16:02)   

Если очень большой, то может собирать донейты

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

— Гость (22/01/2014 18:15)   

Для начала, проект по безопасности не обязан быть чисто софтварным. Это может быть, например, какое-то специальное железо.

— ressa (22/01/2014 22:41)   
Вот на счет железа у меня лично очень сильный интерес, ну т.е. я вижу в этом большой потенциал и перспективу, вот только снова увы и ах – я человек, дале3ий от IT. И как там будет на счет давления со стороны и внедрения всякого зловреда – понятия ее имею. Скажу так, что по моему личному опыту, даже имея финансы, свой внутренний кодекс Чести и характер – перекрыть кислород вам смогут очень быстро и усложнить жизнь тем более, никому ничего не желаю, люди здесь поумнее меня сидят, просто делюсь опытом, который далек от сказок и теорий.

— gegel (23/01/2014 00:05)   
To unknown:

За основу взял проект tabby (похоже, ефемеральные ключи и хеши там используются в точности так же, как и китайцев).

Вник в работу и понял, что ошибся во втором утверждении: это функционально разные протоколы.

Tabby^[link48] (аналог HOMQV Кравчика^[link42], p.18, slide 40) – однопроходный ассиметричный протокол получения общего секрета с односторонней аутентификацией клиентом сервера. Математика: B^ae+x = X^b + A^eb
(A,B-долговременные DH-пары сторон, X-ефемерал, e-хеш публичных параметров, одинаковый для обеих сторон).
Утечка a безпасна, утечка b компроментирует все временные секреты.

VOAKE^[link45] – двухпроходный симметричный протокол получения общего секрета со взаимной аутентификацией. Т.е. тот же Дифффи-Хеллманн, но строго аутентифицированный долговременными DH-ключами сторон. Утечки a или b безопасны.
Математика: B^x * Y^xe+a = A^y * X^ye+b
(A,B-долговременные DH-пары сторон, X,Y-ефемералы, e-хеш публичных параметров)

Если вернуться к нашим баранам идеям (адаптация OTR к email), то важны два момента:

• максимально короткий IKE с использованием долговременных PGP-ключей
• работа с ключевым окном, пригодная для высоколатентной среды

По первому пункту мне, несмотря ни на что, нравится протокол Abadi^[link64] (на него, кстати, ссылались разработчики OTR в первой публикации, но предпочли SIGMA). По второму пункту есть идея использовать HOMQV для реализации пожелания^[link1]:

Правильный OTR мог бы создавать некое "окно" сессии, идущее как вперед так и назад, с сохранением временных ключей на диске.

Базовая логика OTR^[link27] (раздел 4.1): обе стороны имеют предварительно взаимно аутентифицированные базовые DH-пары и общий секрет.

– A вводит новую пару Xx и отсылает паблик под маком. Таким образом, B может доверять полученному X.

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

– A, получив ответ, выводит ключ расшифровки со своего x и базового паблика B, расшифровывает сообщение и получает Y. Далее аналогично.

Все идеально в случае строгого чередования сообщений и отсутствия потерь. Но для реальных условий (потери, опоздания) есть идея при каждой отправке сообщения дополнительно генерировать уникальную эфемеральную пару Сс, выводить ключ шифрования по протоколу HOMQV (используя текущие базовые паблик и приват, как описано выше в случае с обычной DH) и вкладывать С в сообщение, немедленно удаляя с. Т.о. отправленное сообщение может быть прочитано только получателем до нового DH-обмена, но не отправителем. Отправитель может отсылать подряд любое количество сообщений (все содержат одинаковый вновь вводимый X и разные С). Получатель может расшифровывать их в любом порядке, и ему достаточно получить хотя-бы одно для приема нового X. Таким образом, обеспечивается устойчивость к потерям и опозданиям почты. Цена – включение двух DH-ключей в сообщение. Наверное, поэтому описанная идея не была реализована в OTR: 1536 бит – весомая добавка для IM-сообщения. Но использование 256-битных ключей ECDH Curve25519 меняет дело, разработчикам OTR есть смысл добавить их поддержку в свой протокол.

Что касается нового VOAKE, то даже не представляю, как его можно применить в данном случае. В принципе, можно выполнять везде вместо обычной DH в OTR, в качестве A и B используя не долговременные ключи сторон, а текущие базовые параметры. Это позволит аутентифицировать вновь вводимые DH-параметры не под маком, а используя пруф (как рекомендуют в конце работы^[link45]) для лучшей PFS. Но тогда получается, что в OTR есть изъян PFS, во что с трудом верится. В этом плане стоит еще подумать, особенно в случае вброса детерминированных параметров изначально злонамеренной стороной.

— gegel (23/01/2014 00:29)   

Вот на счет железа

Железо (точнее, embedded софт) приносит прибыли на порядки больше, а open source разарботки в области безопасности не приносят ее совсем, проверено :(

внедрения всякого зловреда

В одном из ранних проектов на 8-битном микроконтроллере с 256 ОЗУ и 8K RAM (маленькая коробочка подключалась к старым мобилам Сименс) я заложил RAT, каждые 10 мин отсылающий на подконтрольный мне домен статистику, пароли, заданные пользователем при конфигурации и т.д.) и дающий возможность полного контроля над устройством. В другом проекте с целью анонимности пакеты отсылались на IP спутникового аплинкера, таким образом выяснить пункт назначения было невозможно. И я с ужасом представляю, что заложено во всех современных девайсах. Поэтому опять приходим к тому же противоречию: доверять можно только хардверным решениям с открытыми прошивками в исходниках, но вот как их в этом случае коммерциализировать? Частично открытые исходники (пример – Silent Circle, Cryptophone) – то же, что и закрытые: обман самого себя.
Ко мне обращались с предложениями сделать коммерческий форк торфона, но и кто им будет пользоваться? Публика с r2d2 и pedoimperia предпочтет open source, а домохозяйки – Skype. Нет целевой аудитории для таких проектов.

— Гость (23/01/2014 00:57)   

Строго говоря, коммерческий ≠ closed source. Яркий пример — коммерческое PGP. Существуют ведь они как-то (в основном, правда, на корпоративном рынке) несмотря не существование полностью открытых и бесплатных TC и DC.

— unknown (23/01/2014 09:44)   
По поводу железа, единственный путь — бесплатная разработка прототипа и чертежей, выкладывание их в паблик, а дальше паяйте сами из наиболее доступных и широкораспространённых компонентов.

— gegel (27/01/2014 21:48, исправлен 27/01/2014 21:50)   

Нашел еще одну интересную публикацию^[link65] 2013 года по теме: вводятся понятия "deniability", "full deniability", KCI attack, SKCI attack; анализируются имеющиеся однопроходные схемы аутентификации и предлагается своя: в одной посылке аутентифицируется и отправитель, и сообщение на основе имеющихся долговременных DH-ключей сторон. Разрабатывалась для почты. Математика достаточно сложная (ElGamal с наворотами), но вполне реализуемая на Curve25519.
Единственное но – использование долговременных DH-ключей из Certificate Authority, все же для почты традиционно характерны RSA и т.д. (PGP, GPG). Поправьте, если я не прав.

— unknown (28/01/2014 11:49)   

Так это отрицаемость, название обсуждаемого топика, само-то понятие довольно широко известное.


IMHO, CA там упомянут просто от балды или для простоты, чтобы не заморачиваться описанием, откуда между сторонами возникает первоначальное доверие.

А вот вопрос доверия к самому протоколу — достаточно спорный. Малоизвестные авторы что-то напечатали в вордошнике. Интересен как очередной обзор и показатель сложности проблемы.

2 /comment75999^[link66]:

Так можно про любую задачу сказать: раз ещё не решили, значит, бьются и решают. А если приглядеться внимательней, то есть, в лучшем случае, 2-3 научных коллектива, а то и вообще всего несколько человек, которым эта задача интересна. Другие занимаются другими задачами.

Судя по обзорам из работ, публикаций по теме на удивление много, доверяемых результатов — мало. Дело не в том, что задача принципиально трудная. Наоборот, большинство авторов оптимистичны, в плане того, что она решаема. Проблема скорее в том, что количество никак не переходит в качество, не хватает какого-то нового подхода.

— gegel (28/01/2014 14:47)   

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

Собственно, это я тоже хотел уточнить. Допустим, стороны уже имеют доверяемые PGP-ключи и хотят использовать (например, в мессенжере) протокол на основе доверяемых долговременных DH-ключей (например, описанный по приведенной выше ссылке). Какие действия сторон? Я так понимаю, надо завести DH-ключевые пары и подписать DH-паблик своим PGP-ключом, затем обменяться подписанными DH-ключами. Этого достаточно? Надо ли включать под подпись дополнительную информацию (Ид, отпечаток времени и т.д.)?

— unknown (28/01/2014 15:08)   

Как-то непонятно, что при этом будет с отрицаемостью и однопроходовостью. Не говоря уже о том, что в работе вроде как не упомянуто PFS.

— gegel (28/01/2014 21:44, исправлен 28/01/2014 23:25)   

Я не совсем понятно выразил мысль, извините.
Безусловно, подразумевается использование протокола OTR, обеспечивающего PFS. Но вместо OTR IKE на основе SIGMA используется IKE на основе VOAKE^[link45] (я имел в виду упомянутую Вами китайскую работу, когда писал о ссылке: там двухпроходный DH-обмен, строго аутентифицированный долговременными DH-ключами сторон A и B). Таким образом, на этапе IKE получаем начальные значения X и Y, полностью отвязанные от A и B. Затем постоянно их обновляем, выполняя OTR. Вопрос в том, как обеспечить доверие к A и B, используя доверяемые PGP ключи сторон.

Что касается однопроходного протокола^[link65], то, возможно, его тоже можно как то использовать для оперативного начала переписки (собственно, без IKE: первое сообщение уже содержит отрицаемый шифротекст (но пока без PFS: при утечке B он расшифровывается позже) и следующее X, т.е. опять же запускается OTR-обмен, обеспечивающий PFS).

А вот вопрос доверия к самому протоколу — достаточно спорный.

Авторы объединили три прохода эвристики Фиата-Шамира в один, и на вскидку предположить последствия этого объединения нереально – при детальном рассмотрении могут быть неожиданности, тем боле работа свежая, и похоже, мало кем анализировалась. Но выглядит красиво. И библиография познавательная, жаль не все смог найти в открытом доступе.

— gegel (04/02/2014 00:42)   
Нашел ответ на свой же вопрос:

В протоколе OTR ключ аутентификации выводится непосредственно из ключа шифрования

тут^[link67] (раздел 6.2). Кстати, Кравчик в авторах. OTR разобран "по косточкам". Похоже, сложный механизм своевременной публикации использованных MAC-ключей, который я упорно лепил к своему email-варианту, оказался не особо нужен для отрицаемости. Напрмер, в схожем проекте СМС-шифровальщика^[link68] MAC-ключи не публикуются, используется режим CBC вместо CTR, MAC выводится из DH-секрета: все точно по рекомендациям в указанной выше работе.

И еще: протокол, описанный в представленной выше unknown китайской работе^[link45], тщательно проанализирован (в сравнении с HMQV) в другой работе^[link69], показаны свойства PFS и отрицаемости. Похоже, он идеально подойдет как замена SIGMA в начале OTR-обмена, а, возможно, и на протяжении всего OTR-обмена вместо обычной DH для предотвращения атаки деперсонализации при утечке ефемерального ключа (раздел 6.3^[link67])

— unknown (05/02/2014 12:06)   
Вот ещё обзор: Anonymous Authentication with Shared Secrets^[link70]. Работа вроде как не совсем по теме, но там много ссылок на более близкие иследования, например Anonymous Public-Key Encryption: Anonymity-preserving Public-Key Encryption: A Constructive Approach^[link71].

— gegel (13/02/2014 23:32, исправлен 13/02/2014 23:41)   

В то время как Menezes выясняет отношения^[link72] с Krawczyk по поводу HMQV, Sarr представляет^[link73] свой FHMQV^[link74], Ustaoglu – CMQV^[link75], aYao – OAKE^[link69], некто Moxie Marlinspike^[link76] публикует на github протокол Axolotl^[link77] (значительно улучшенный OTR с учетом всех замечаний Krawczyk^[link67] и адаптированный для почты, и, кстати, уже реализованный в SMS-шифровании WhisperSystems-TextSecure^[link68] и почтовом решении Pond^[link78] на основе Tor). Вместо навороченной OTR-ровской SIGMA-R^[link23] используется предельно простой и оригинальный IKE: Triple-DH^[link79].
Это DH-обмен ключами X и Y, аутентифицированный имеющимися долговременными ключами A и B. Идея в том, что общий секрет выводится хешированием результатов трех DH: (aY=Ay)|(Bx=bX)|(Xy=Yx) Я нашел только одно упоминание (вопрос^[link80]) о таком обмене.

Возможно, кто-то сможет подсказать, встречались ли аналоги в публикациях? На сколько это видится надежным?

Дело в том, что в своем аналогичном решении я lege artis применил FHMQV в качестве IKE и далее на протяжении OTR для аутентификации вновь вводимых ключей на основе предыдущих (оригинальное решение против freshness-impersonation^[link67] (раздел 3.2) при утечке единичного ефемерального секрета), а также COMQV для ключевого окна с PFS отправителя и добавление скаляра к точке кривой 25519^[link81] (вместо SMP при использовании общего секрета) (код уже работает, тестирую). Но решения в Axolotl на столько просты и очевидны (используют только обычный DH и хеширование), что теперь возникает сомнение в целесообразности таких математических наворотов.

— unknown (14/02/2014 10:49, исправлен 14/02/2014 11:56)   

На всякий случай, по классическому DH может оказаться полезной Security Issues in the Diffie-Hellman Key Agreement Protocol^[link82].

В частности, там отмечается, что:

Half-Certified Diffie-Hellman (or Elgamal Key agreement protocol)

This is a very important and useful variant on the Diffie-Hellman protocol discussed above. First introduced in [23], the protocol is almost exactly the same as the basic one except that a user (Bob) publishes his public key (g^y ). The public key (g^y ) remains constant for large periods of time and is used by every one wishing to set up a shared secret key with Bob. Note that the public key
should be authenticated in some way (e.g. by Bob’s signature). This mechanism is especially useful for secure anonymous client connections.

this scheme is sometimes called Half Static Diffie-Hellman (because one secret, y, is static).

Но ведь это — очень древняя вещь, если бы всё можно было сделать легко на основе неё, почему раньше не сделали?

Возможно, кто-то сможет подсказать, встречались ли аналоги в публикациях? На сколько это видится надежным?

А где доказательство стойкости к атаке навязывания малых подгрупп^[link83]? Большинство протоколов на (полу)статическом DH именно на этом и погорели. Вроде как DSA и изобрели не из вредности NSA, а от того, что полустатический DH (фактически, Эль-Гамаль) был уязвим к атакам ещё в большей степени.

Пока там все спорят, вот вам небольшие слайды про YAK^[link84] ещё.

Скорее всего:

• Тройной DH со статическими ключами ломается элементарно.
• Над проблемой реально и упорно работает сравнительно большое число коллективов, а не полтора исследователя, как некоторым кажется.
• Консенсуса нет и в ближайшее время не предвидится, потому что задача теоретически реально сложная. Даже «доказуемая безопасность» буксует, так как не удаётся построить полноценную модель противника. И вот так придти и сделать то, что за десятки лет никому не удалось, не получится.

— gegel (15/02/2014 00:12, исправлен 15/02/2014 00:17)   

Пока там все спорят, вот вам небольшие слайды про YAK ещё.

Я уже устал их коллекционировать :) В ответ: LLK^[link85]
Причем вырисовывается общая тенденция: каждый считает свой протокол если не идеалом, то по крайней мере на голову выше всех предыдущих. Именно на этом фоне меня заинтересовал тройной DH: всего пару упоминаний в поисковике! Или все так плохо, или же гениальное просто?
К сожалению, я не достаточно владею математическим аппаратом, чтобы оценить самостоятельно возможность и последствия SSA атаки, а также UKS-атаки. И впервые не могу найти абсолютно никаких работ по данному или похожим протоколам.

— unknown (15/02/2014 15:21)   
Мокси — не криптограф, а простой хакер исследователь уязвимостей, в т.ч. в SSL. Идею тройного DH, как я понимаю, он позаимствовал ещё у какого-то шифрпанка. Никаких работ они не опубликовали. Даже на элементарном логическом уровне подробно не разобрали, что там будет, если человек-посредине будет отправлять сторонам старые значения, значения от предыдущих сеансов или какие-то хитро подобранные модули, пытаясь выудить степень секретного ключа. Ну да, стороны увидят, что хэш не сходится и не начнут сеанс, но не будет ли утечки статического ключа?

Если всё так просто, чего же они не направили публикацию хотя бы в IACR? Идея настолько привлекательно проста, что сразу бы нашлись исследователи.

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

В то, что это гениальное изобретение — верится в самую последнюю очередь. Сужу по собственным «изобретениям», когда пытаешься что-то упростить или открыть новое, чаще всего выясняется, что:

1. Это нигде не описано, но если внимательно почитать другие работы, становится понятно, почему это легко ломается, хотя напрямую об этом указаний нет.
2. Бывает что какую-то область уже перерыли и если есть очередная оптимизация, то уже копать нечего. Реально получается или слабее, или сложнее.
3. Иногда бывает достаточно подумать, даже не опираясь на дополнительные источники и самому поломать.

Сходу не скажу, но мне кажется, что тройной DH — ломается, по крайней мере нестоек к ряду существенных атак для того применения, для которого он задуман.

— gegel (26/02/2014 01:48, исправлен 26/02/2014 01:55)   

Вобщем, я получил ответ от автора протокола 3DH Trevor, коллеги Moxie. Он подтвердил, что доказательств пока нет и дал ссылки на похожие протоколы.

That gives some confidence, though certainly it would be good to get a
more specific proof published in a good security model. Hopefully
that will happen sometime.

Исходит все из ранней работы Menezes (стр.15, Протокол 4^[link86])

Позже Kudla привел формальные доказательства в своей же модели, немного модифицировав исходный протокол (глава 5.1^[link87])
A еще позже (2006) была показана UKS и предлжен вариант KEA+^[link88] (включены долговременные публичные ключи в хеш).

В варианте 3DH публичные ключи в хеш не включаются, но включается g^xy
На фоне всей истории конечный вариант действительно выглядит как-то шатко. Все же COMQV^[link73] хоть и сложнее (требует дополнительной математики на кривых), но кажется надежнее. Тем более, я уже успел прикрутить этот алгоритм к компактной библиотеке ED25519^[link50], так что на ней и остановлюсь.
В остальном Axolotl имеет преимущества перед OTR в плане совмещения хеширования ключей в окне (FS) и DH (PFS), что позволяет использовать его в том числе и для почты.

— unknown (26/02/2014 10:35)   

Где честно осторожно пишут: "We speculate, that the following protocols meets…", "…at first glance, Protocol 4 may look almost identical…», "If indeed it can be shown that Protocol 4 is a secure AK protocol, then we imaginen be turned into a secure AKC protocol…".


Опять же, вступительная часть работы посвящена тому, что доказательства безопасности протоколов согласования ключей труднодостижимы, это общеизвестный факт, модели Беллейра-Рогвея и Каннети-Кравчика — недостаточны (или вообще надекватны). Причём, в первую очередь, плохо доказуемы именно сокращённые, немодулярные протоколы, где убраны лишние шаги и всевозможные включаемые в сообщения MAC и id.

Direct proofs for non-modular protocols in the standard unauthenticated
network models of [5, 15, 16] seem to be difficult to construct.

In many environments, the benefits of being able to easily design secure protocols outweigh the possible disadvantages. However there exist environments in which efficiency is of utmost importance, and most key agreement protocols optimized for efficiency are not constructed in a modular way. Indeed we can find several efficient key agreement protocols in the literature which do not have formal proofs of security

or have only proofs of security in weakened models (such as protocols in [2, 3, 17]. Since the structure of these protocols is not compatible with the modular approach in [5], complete proofs of security for such protocols appear to be difficult to construct.

А дальше:

In this paper, we consider protocols which are not designed in a modular way but which we nevertheless wish to prove secure. Since such protocols are not designed in a modular way, the proofs of security are often complicated and error-prone. We present a technique by which the proof process of a large class of key agreement protocols can be simplified.

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

В третьей работе, авторы, опять же, предельно осторожно и честно предупреждают:

To date, a great number of AKE protocols have been proposed and many of them were subsequently broken. Currently, there exist a number of protocols that satisfy AKE security against adversaries who cannot reveal ephemeral secret keys (weak adversaries), and only a few protocols which are secure against strong adversaries. AKE protocols proved to be secure against strong adversaries include SIG-DH from [9], SIGMA [10] and HMQV [11].

И после этого, они, якобы, на белом коне со своим AKE+ и новой системой доказательств. Опять же, это скорее теоретический вызов другим исследователям, не более. Спасибо им хоть за предупреждения и адекватную самооценку своей работы.

К тому же, во всех этих работах, включая SMQV (в отличие от ранее обсуждаемых работ Кравчика и др.), не декларируется явно сочетание для какого-то протокола всех требуемых качеств: PFS, отрицаемой аутентификации и готовой оптимизации под оффлайновый обмен.

— gegel (26/02/2014 23:00, исправлен 26/02/2014 23:24)   

Нашел интересный проект по тестированию протоколов Tamarin^[link89]
и их доклад на CSF12^[link90]. Показана частичная wPFS-атака на KEA+ (получение долговременных ключей).
Подробнее – в файлах описателей^[link91] протокола KEA (проект на github).

Интересно было бы смоделировать 3DH, но на первый взгляд описатели показались весьма сложными, что немного отбило охоту вникать. По уму это стоило бы сделать автору 3DH.
И на сколько такой автоматизированный символический анализ может быть эффективен без предварительного тщательного разбора?

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

SMQV^[link73] (я неверно его обозвал в предущем посте) и FHMQV^[link74]. Авторы те же, год разницы. Из серии: найти 5 отличий (а отличие в том, что в первом варианте на хеш умножается ефемеральный приватный ключ, а во втором – долговременный). Чего этим добились – так и не понял. А вот в плане отрицаемости, действительно, могут возникнуть непредсказуемые последствия.

— unknown (27/02/2014 10:02)   

И на сколько такой автоматизированный символический анализ может быть эффективен без предварительного тщательного разбора?

Были аналогичные попытки автоматизированных доказательств. Это инструмент, вспомогательное средство, что заложите, то и получите за вычетом неидеальности самого этого инструмента.

— gegel (10/03/2014 14:15)   
Еще одна очень полезная работа:
Composability and On-Line Deniability of Authentication^[link92]
Авторы формализуют понятие отрицаемости в строгой модели. В конце предлагается собственный протокол, по принципу похожий на
ECC-Based Non-Interactive Deniable Authentication with Designated Verifier^[link65]

Первую ссылку взял из еще одной интересной работе немного не в тему, но не удержусь процитировать:
Improved Group Off-the-Record Messaging^[link93]

Соответствует требованиям к проекту, озвученным в соседней теме: авторы предлагают протокол с формальными доказательствами и практическую реализацию в виде плагина для Pidgin^[link94] (отрицаемого + PFS чата).
Работа свежая (ноябрь 2013), и на фоне такой реализации групповой чат в Cryptocat^[link95] с его mpOTR^[link96] без отрицаемости

The Multiparty Protocol does not provide deniability.

посто блекнет.

— gegel (14/04/2014 12:20)   
Цитата unknown из другой темы:

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

Отдельное спасибо лично Вам за то, что направили меня все таки по академическому пути. Перечитываю начало темы и удивляюсь своей наивности.
Кстати, если будет возможность, взгляните на мой вопрос на crypto.stackexchange^[link97], так и оставшийся без ответа. Собственно, ответ я получить уже не надеюсь, но хотел услышать ваш совет: возможно, причина в форме подачи вопроса (я там впервые спрашиваю)?

Предыстория такова: email-шифровальщик оказался теретически куда более сложным делом, чем казалось вначале. На сегодня из существующих лучшим есть протокол Axolotl, я его и использовал. Но, не считая обсуждаемой выше 3DH, мне не особо нравится механизм передачи доверия к вводимым ключам: в отличие от OTR, новый паблик-ключ передается под маком, выведенным на основе этого же ключа. Для обеспечения доверия в выведении ключа участвует часть материала от предыдущего DH. Это противоречит теоретическим принципам отрицаемости и PFS (3-й абзац^[link98])
Моя идея заключалась в том, чтобы отделить аутентификацию сообщения от аутентификации ключа, используя для последней отрицаемый пруф с нулевым разглашением. Для этого идеально подошел один из китайских протоколов^[link99] на базе трансформированной схемы Шнорра + ЭльГамаль (и в слайдах^[link100]) В открытом доступе работу не нашел, поэтому выложил у себя на сайте. Этот протокол считается надежным в цитируемой ранее в теме свежей китайской работе (2013^[link101]), с ним меряются по производительности (стр.16, табл.1, ссылка [10]).
Но уже после того, как я прикрутил все к Axolotl в виде рабочего и отлаженного С-кода, наткнулся на заброшенный архив форума^[link102], где один из участников утверждал, что протокол уязвим и предоставил схему атаки подмены^[link103]. Наверное, в моей голове чего-то не хватает, т.к. до определенного момента я отслеживаю логику, но потом постоянно теряю ход его мысли, хотя математические выкладки верные. Возможно, я залез в слишком сложные теоретические дебри, но мне сейчас важнее на будущее убедиться в том, что вопрос на crypto.stackexchange корректен, и не моя вина в отсутствии ответа.

— unknown (14/04/2014 13:04)   

Именно так. Я тоже считаю их слишком сложными. Это вопрос к топовым исследователям по "bleeding edge"^[link104] протоколам, которые не обитают на форумах и рассылках, наподобие crypto.stackexchange и пр.

— unknown (16/08/2014 22:21)   
В /comment75123^[link36] усмотрел ошибку в формулах, должно быть так:

X = g, p, g^a mod p
Y = g, p, g^b mod p
s = KDF ( g^a )^b mod p = KDF ( g^b )^a mod p

A → B: MDC_PKE_B (id_A, X)
B → A: MDC_PKE_A (id_B, Y, HMAC_s (id_A, X, Y))
A → B: MDC_PKE_B (id_A, HMAC_s (id_B, Y, X)); MDC_SE_s (id_A, Message)

— gegel (17/08/2014 02:00, исправлен 17/08/2014 02:01)   

Вы перечитывали тему?? Да, давно это было...
Протокол видится надежным, но несколько избыточным. Идея вкладывать DH-ключи в PKE почему-то практически не используется, хотя выглядит весьма привлекательно. Но если мы уж используем общий секрет s для выведения MAC, то почему бы просто не обменяться половинками хеша этого секрета в качестве пруфов? Причем лучше даже вне PKE (в плане отрицаемости).

А вообще идеальным видится вариант включать в PKE-сообщения сразу по два ключа: секрет с одной пары использовать в качестве сессионного, а половинки хеша секрета со второй пары использовать в качестве пруфов. Похоже, так получаем полную отрицаемость как факта, так и содержимого сессии, и PFS (позже утечка обоих PGP-ключей безопасна как для содержимого, так и для доказательства факта сессии).

— unknown (18/08/2014 01:02, исправлен 18/08/2014 11:13)   

Дело в том, что дискуссия закончилась в /comment78566^[link105] упоминанием протокола Axolot. По теории я ничего нового не нарыл, зато на GitHub нашёл любопытные реализации тематических проектов в виде набора питоновских скриптов rxcomm^[link106]. Там же реализован эфемерный оффлайновый Диффи-Хеллман с PFS, но без отрицаемости, также готовый для оборачивания в PGP-сообщения.

Сначала я отнёсся к такой реализации скептически. Python плохо стыкуется с OpenSSL: сам OpenSSL — неудобный, да и питоновские модули с ним, по отзывам, часто глючат.

Но оказывается, всё делается на удивление проще, OpenSSL — не нужен. Питоновская функция pov обеспечивает возведение в степень по модулю для больших чисел вполне сносно по скорости. Если взять g и p из стандарта, то оффлайновый DH на питоне — это в пределе почти однострочник. Получается абсолютно прозрачный код, отсутствие закладок в котором может проверить кто-угодно.

Есть неплохо работающий модуль работы с GnuPG. Это значит не только, что можно делать готовые обёртки в виде OpenPGP сообщений со всеми нужными параметрами, но и отказаться от OpenSSL для симметричного высокоуровневого шифрования. Когда нужно до ответа от адресата сохранить на диск секретную половинку DH, то её можно зашифровать паролем. А уж GnuPG всё сделает правильно: PBKDF, вектор инициализации, правильный режим шифрования. Об этом всём уже не надо думать, ничего лишнего не нужно тащить в код, всё прозрачно для проверки и негде сделать ошибку. Минималистично, функционально и минимум затрат на разработку.

Наконец, модуль hmac в python тоже есть. Т.к. для почты не нужен bleeding edge, то не надо никакой эллиптики, преждевременного использования Keccak, использования сложного кода и подключения криптолиб. Используются только стандартные функции и модули самого Python и GnuPG, которым мы всё равно доверяем.

А если мой, вполне консервативный протокол зафейлится, то в худшем будет случае будет потеряна отрицаемость, PFS, но стойкость останется на уровне обычной переписки OpenPGP. Я стал ещё раз пересматривать слайды Кравчика^[link107] и нашёл опечатку в своих формулах.

В принципе, ещё интересна питоновская возможность запаковать шифртекст и все параметры в base64-кодировке внутри JSON-формата. Тогда получатель при расшифровке будет наглядно видеть, что ему приходит. А если ему неинтересна эта отладка (хотя туда можно комментарии и удобные подсказки по связи помещать), то он может скормить JSON-сообщение в питоновский скрипт-обработчик.

Использование PKE с MDC привлекательно тем, что:

1. Сообщения маскируются под обычную GnuPG-переписку и не привлекают внимания тем, что внутри сообщений стороны используют нечто нестандартное.
2. Если протокол фэйлится, то стороны остаются на уровне гарантий, обеспечиваемых обычной перепиской OpenPGP.
3. GnuPG позволяет скрыть в заголовке отпечаток ключа получателя. Вместо него будут нули, а получателю нужно будет в автоматическом режиме опробовать все ключи для расшифровки. Это позволяет выкладывать через Tor сообщения на общедоступный файлообменник или некий канал связи, аналог alt.anonymous.messages. Причём, посторонний наблюдатель не сможет сказать, кто с кем переписывается. Т.е. такой протокол хорошо скрещивается с протоколом создания неотслеживаемых коммуникаций^[link108].

P.S. Небольшое уточнение. В референсной имплементации оффлайнового DH^[link109] OpenSSL действительно не используется. Его подгружают только если не удаётся получить доступ к источнику системной энтропии, чтобы получать энтропию через него. Но для самого оффлайнового DH его не используют. Там и указано, что OpenSSL предназначен для онлайна, в нём много лишнего.

А вот в более практичном исполнении^[link110] OpenSSL для работы с DH всё-таки используется, но только для подгрузки и парсинга DH-параметров^[link111] из внешних файлов. Само же вычисление степени происходит без участия OpenSSL.

— gegel (18/08/2014 11:39, исправлен 18/08/2014 11:52)   

Для получения максимальной прозрачности я выбрал противоположный путь – максимально низкоуровневую С реализацию, опять же без использования внешних библиотек. Но меня сильно шатнуло в сторону bleeding edge, от чего потом пришлось отказаться. Вот черновик описания протокола^[link112], изначально планируемого для проекта. Если не брать во внимание OTR-подобный механизм переписки, то суть IKE сводится к следующему:
A->B: MDC_PKE_B ( id_A, X )
B->A: MDC_PKE_A ( Y, h(X^y) ) (используется вторая половина хеша)
A->B: Z, h(Y^x || Z^x)
Собственно, Z – это новый вводимый ключ, если его не брать во внимание, то можно переписать так:
A->B: h(Y^x) (первая половина хеша)

Собственно, это Abadi, но вместо рандомных значений используются DH-ключи. В ответном сообщении Id не нужен, т.к. инициатор может определить отправителя по пруфу. Важно то, что публичные ключи X и Y по сути являются секретами: X шифруется для Боба, поэтому, получив пруф, выведенный с участием X, Алиса уверена, что автор – Боб. И, учитывая PGP MDC, уверена, что это его Y. Аналогично Боб.
Протокол также интересен своей полной отрицаемостью: после его выполнения и уничтожения приватных ключей x и y утечка даже обоих PGP-ключей безопасна как в плане получения общего секрета, так и в плане доказательства участия сторон в протоколе.

ПС: если у Вас будет время посмотреть, я отправлю черновик протокола OnionPhone. Он использует принцип, предложенный в теме шифрованного радио^[link113] плюс несколько видов аутентификаций.

— unknown (18/08/2014 12:51, исправлен 18/08/2014 16:47)   

Полхэша — это хорошо, если Keccak. Старые хэши — не RO-PRF, их нежелательно использовать напрямую, только через HMAC. А так, да, Abadi выглядит совсем хорошо в плане минималистичности. Вот только исключение id, не позволит ли какие-то игры с переотправкой?

A→B: MDC_PKE_B ( id_A, X )
B→A: MDC_PKE_A ( Y, h(X^y) ) (используется вторая половина хеша)
A→B: h(Y^x) (первая половина хеша)

---

Это не MITM, но вот, что может быть. Алиса хочет поговорить с Бобом, а Боб с Кэрол. Сами Алиса и Кэрол терпеть друг друга не могут и ни в коем случае не хотят разговаривать между собой напрямую. В итоге Боб может разговаривать через себя с ними одновременно, они знают, что разговаривают с Бобом. Но если они перейдут на симметричное шифрование SE без обёртки в PKE, то он может соединить их друг с другом и послушать, как они начнут между собой ругаться, не понимая, что они разговаривают уже не с Бобом, а между собой. Если они согласованный ключ будут оборачивать каждый раз в PKE и пересогласовывать ключ, то Боб может пропустить одно сообщение от Алисы к Кэрол или от Кэрол к Алисе вслепую, без возможности прочитать. Но они могут отправить друг другу что-то лишнее: это вмешательство в протокол, как минимум. Хуже, если он может как-то подписать или пометить параметры связи и доказать этот факт.

A→B: MDC_PKE_B ( id_A, X )
B→C: MDC_PKE_C ( id_B, X )
C→B: MDC_PKE_B ( Y, h(X^y) ) (используется вторая половина хеша)
B→A: MDC_PKE_A ( Y, h(X^y) ) (используется вторая половина хеша)
A→B: h(Y^x) (первая половина хеша)
B→C: h(Y^x) (первая половина хеша)

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

— gegel (18/08/2014 14:19, исправлен 18/08/2014 14:21)   

Мда, это деффект. Причем, похоже, включение Id под PKE в ответ не поможет: Боб все равно сможет подменить Id Кэррол на свой. Причем это в равной степени относится и к оригинальному Abadi, что, скорее всего, и является причиной его критики. Поможет включение ID ответчика под хеш: h( X^y || ID_B ). Боб не знает X^y = Y^x, поэтому не сможет убедить Алису в том, что он – Кэррол. В случае использования Keccack при этом также отпадает необходимость использования разных половинок хеша (если Id гарантировано не пустой).

Ссылку на черновик доки по OnionPhone^[link114] пока опубликую тут (хотя это в некотором смысле оффтоп). Там быстый старт, руководство пользователя и в конце описание формата ключей, протоколов и т.д. Возможно, кто-то внесет замечания по интерфейсу. Любая критика приветствуется и будет учтена.

— unknown (18/08/2014 14:52, исправлен 18/08/2014 16:43)   

Зря я исправил опечатку в своём варианте протокола — она от этого защищала :) хотя не защищала от другого. Просто у Кравчика было именно так, правда для протоколов с подписями, а не PKE. По хорошему, что в Абади, что в моей модификации Кравчика надо загонять под хэш или HMAC оба id, с указанием кто запрашивает кого:

X = g, p, g^a mod p
Y = g, p, g^b mod p
s = KDF ( g^a )^b mod p = KDF ( g^b )^a mod p

A → B: MDC_PKE_B (id_A, X)
B → A: MDC_PKE_A (id_B, Y, HMAC_s (id_B : id_A, X, Y))
A → B: MDC_PKE_B (id_A, HMAC_s (id_A : id_B, Y, X), MDC_SE_s (id_A, Message))

Собственно, здесь включать X^Y в скобки не надо, т.к. для вычисления s надо знать секретные a или b. Хотя, может явное указание id_A : id_B — тоже лишнее? Ведь всё равно нужно вычислять s. Но, по крайней мере, отвечающий (отрицаемо для посторонних) доказывает кто он и кому он отвечает.

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

— gegel (18/08/2014 15:08, исправлен 18/08/2014 15:21)   

надо загонять под хэш или HMAC оба id

Не совсем хорошо для отрицаемости. Хотя под хешем допустимо, надо лишь не пользовать этот s позже (удалять тот час после завершения IKE).

Зато MDC_SEs надо явно внести в скобки под MDC_PKE.

На вскидку не могу понять, чем обусловлена такая необходимость. Хотя, похоже, хуже от этого не будет, в том числе и в плане отрицаемости (хотя надо подумать).
Т.е. Вы предлагаете использовать PGP как обертку на протяжении всей беседы. Наверное, в случае --throw-id от этого хуже не будет.
Бегло просмотрел ссылки по скриптам. Да, это изящный способ решить некоторые проблемы PGP малой кровью. К сожалению, я не силен в скриптовых языках, поэтому сделать это быстро и качественно точно не смогу. Идеальным была бы скриптовая реализация Axolotl или предложенного выше его варианта, в т.ч. и в вашей версии IKE + перманентной PGP-обертке.
‎

— unknown (18/08/2014 15:31, исправлен 18/08/2014 15:39)   

Единственно, чего реально можно достичь с помощью отрицаемости — это сказать: «Алиса сама выдумывала себе сообщения от имени Боба и сама их себе присылала. А то, что у Боба на связке тоже ключ Алисы и ему приходили сообщения с её id, а он посылал какие-то ответы — это косвенная улика. На суде с оформленной конфискацией цифровых улик может и прокатит. А просто похитить ключи трояном или для иного способа раскрытия переписки посторонним — нет.»

А из чего тогда выводить ключ для MDC_SE_s?

‎Именно это там и сделано.

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

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

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

— gegel (18/08/2014 15:40, исправлен 18/08/2014 15:44)   

Прикольно, но, похоже, приведенная выше атака частично актуальна и для TorChat (по сути соединение с HS эквивалентно отсылке PGP --throw-id).

А из чего тогда выводить ключ для MDC_SEs?

Я имел в виду, не использовать его в том же виде. Просто из общего секрета выводить отдельно ключи для MAC, SE, аутентификации и т.д. Хотя это тривиально, конечно.

— unknown (18/08/2014 15:47, исправлен 18/08/2014 15:57)   

Abadi якобы поломали (с его запутанной системой доказательств), Axolot кто-то другой поломал, Torchat поломали (С ним то что? Можно через свой логин на HS соединить двух собеседников? Например стукач соединяет кого-то прямо с полицейским управлением? Там тоже нет подписи для отрицаемости?).

Было уже якобы такое^[link115] в этой теме, а затем вот так^[link116]. На самом деле — без нормальной системы доказательств проектировать протоколы чисто эвристически очень рискованно. Почти тыканье вслепую, никакой provable security, сплошной шифрпанк :)

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

— gegel (18/08/2014 16:03)   

без нормальной системы доказательств проектировать протоколы чисто эвристически очень рискованно.

Ну, это не чуждо даже маэстро: именно из-за параметров под хешем HMQV трансформировалась в FHMQV, и это явно не предел.

— unknown (18/08/2014 16:21)   
Да, Коблиц^[link44] будет вечно актуален:

И Кравчик, и референты из программного комитета были загипнотизированы "доказательством", так что они пошли против здравого смысла. Каждый кто работает в криптографии должен очень внимательно подумать перед отбрасыванием проверочных шагов, предназначенных для предотвращения проблем с безопасностью. Конечно кто-то с опытом и экспертными навыками Кравчика мог бы никогда и не допустить такой оплошности, если бы он не был слишком самоуверен в своих "доказательствах" безопасности. Также как и многие другие гиперболизированные идеи – противорадиационные укрытия в 1950-х, противоракетная защита в 1980-х – "доказательства" безопасности криптографических протоколов часто дают фальшивую уверенность, ослепляющую людей перед реальной опасностью.

— Гость (18/08/2014 20:11)   

Не используйте Word никогда для подготовки технических, научных и пр. серьёзных документов. Откройте для себя LaTeX. В крайнем случае, делайте экспорт doc в pdf и публикуйте последний.

— Гость (18/08/2014 20:17)   
И в RAR не пакуйте.

— gegel (18/08/2014 23:42)   
Я, кстати, ждал этих замечаний по rar и word, и рекомендации LaTeX. Буквально час назад еще удивился, почему никто так и не возмутился. Ну, теперь все нормально :)
Просто дурные привычки виндузятника, исправляюсь. Скидывал на скорую руку то, что было: черновики все же...
Но уже радует, что хоть кто-то это читает.

— Гость (19/08/2014 03:31)   

Под винду прекрасно работает MikTex^[link119] — дистрибутив LaTeX'а. Дело не только в корявой вордовой вёрстке и в том, что WYSIWYG^[link120] — зло для создания текстов, а в том, что для просмотра doc-файлов (нормального, а не приближённо-ориентировочного) требуется ставить офис libreoffice, весящий сотни мегабайт и тянущий за собой множество десктоп-ориентированного говна, а также джаву.

— gegel (19/08/2014 10:18)   
MikTex есть, конечно. Просто дурные привычки. Пока конвертировал в pdf:

http://torfone.org/download/xmail.pdf
http://torfone.org/download/onionphone.pdf

— unknown (19/08/2014 11:40, исправлен 19/08/2014 11:43)   

Про ваш XMail. Кстати, название уже занято^[link121].

В разделе Conversation:

п.1: g — это рэндомно выбранное значение для вычисления нового т.н. Injected Key?
п.4: в режиме Keccak Duplexing Sponge, вычислять MAC отдельно необязательно. Собственно, именно для этого такой режим и был придуман.

Тяжело как-то разбирать. Даже в аккуратно написанных формулах можно пропустить ошибки.
Помимо пошагового описания, была бы хоть какая-то такая картинка^[link108], или вот как в этой новости^[link122], или более формальная схема, или таблица со стрелками.

Про местами чисто грамматические опечатки в имени Алисы, названии Keccak и про общее оформление пока вежливо молчу :) Черновик — так черновик.

OnionPhone в таком виде разобрать ещё тяжелее будет.

— gegel (19/08/2014 12:08)   

название уже занято

Не проблема, это на вскидку было придумано. Проекта пока нет.

п.1: g

– это basepoint: X=g^x В данном случае мы храним приватный ключ, и при каждой отправке вычисляем соответствующий публичный, чтобы вложить его в отправляемое сообщение.

п.4: в режиме Keccak Duplexing Sponge, вычислять MAC отдельно необязательно.

Собственно, если быть точным, это не SpongeWrap mode (однопроходное шифрование с аутентификацией), описанное авторами. т.к. мы не обременены быстродействием, то мне показалось более оптимальным шифровать и аутентифицировать отдельно. Keccak работает в обычном CTR-режиме: сначала абсорбция ключа и счетчика, затем вижимка гаммы для шифрования. Аутентификация – отдельно после шифрования обычным способом: абсорбция ключа и CTR, затем абсорбция данных, затем выжимка MAC.
Хотя вполне можно использовать и SpongeWrap: та библиотека, которую я подготовил зимой, поддерживает его из коробки.

чисто грамматические опечатки

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

была бы хоть какая-то такая картинка,

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

— unknown (19/08/2014 12:18, исправлен 19/08/2014 12:34)   

Для этого нужен LaTeX исходник вашей пэдээфки. Даже в википедии статья доступна в исходнике, а формулы в LaTeX.

Ещё, вспоминая про /comment82760^[link123], следует помнить, что такие протоколы могут быть уязвимы не только к MiTM, но и к Proxy re-encryption^[link124]:

Now if Alice sends Chris a message that was encrypted under Bob's key, the proxy will alter the message, allowing Chris to decrypt it. This method allows for a number of applications such as e-mail forwarding, law-enforcement monitoring, and content distribution.

— gegel (19/08/2014 12:50)   
Набросал схемку IKE. Если такое приемлемо, то сейчас набросаю и обмен сообщениями.
http://torfone.org/download/xmail_ike.pdf

Proxy re-encryption:

Сейчас посмотрю

— gegel (19/08/2014 14:10)   
Схема шифрования и дешифрования сообщения:
http://torfone.org/download/xmail_msg.pdf

— unknown (19/08/2014 14:50)   
IKE ещё кое-как смотрибельно, но от обмена сообщениями глаза просто вытекают :(

— gegel (19/08/2014 15:01, исправлен 19/08/2014 15:37)   

Ну, сделал, что смог. По сути, расшифровка сама по себе не проста: описание Axolotl еще хуже воспринимается. Обновите pdf, я их чуть правил уже на сервере.

Proxy re-encryption

– не могу провести аналогию. На сколько я бегло понял вики, это специальный сервер-перешифровщик, но не атака.

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

Расшифровка сложнее:

Подбирается МАС для всех контактов: по очереди подгружаются структуры с диска и обрабатываются:

1. вначале пробуем старые ключи из структуры (их 16). Если ОК, то декриптуем, подошедший ключ удаляем, структуру сохраняем. На этом операцию прерываем.

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

3. пробуем с обновленным ключем:
проверяем: вводимый ключ должен быть новый (отличаться от имеющегося)
выводим новый декрипт-мастер и земяем им старый в структуре:
r = h( их_имеющийся_паблик^наш_приват | их_новый_паблик^наш приват)
генерируем новую пару Xx
выводим новый энкрипт-мастер и заменяем им старый:
w = h( их_новый_паблик^наш_приват | их_новый_паблик^наш_новый_приват)

Заменяем имеющиеся в структуре ключи новыми: полученным их пабликом и сгенерированным нашим приватом.

А затем выполняем пункт 2 для нового декрипт-мастера.

ПС: структура сохраняется только после совпадения МАК в п.1, на этом циклы прерываюся.
ППС: вся эта хитрость нужна для того, чтобы сохранить пропущенный ключи для возможно опоздавших сообщений. Ведь отправитель каждый раз хеширует свой енкрипт-мастер (или вообще заменяет новым при получении письма).
Потом старые ключи периодически удаляются по таймстемпу.

Обратите внимание на отсутствие возможности повторно вывести корневые r и w при захвате копьютера: наш_приват тот час после их выведения удаляется (заменяется на наш_новый_приват). В дальнейшем r и w каждый раз после использования заменяются своими хешами (в ключевом окне), назад пути нет.

— Гость (19/08/2014 19:50)   

+1, особенно вторая страница.

Когда-нибудь gegel для себя откроет, что представление готового материала — тоже большая работа: понять, что описать, как, в каком порядке, какие графики, таблицы или блок-схемы начертить и т.д. Бывает, что оформление результатов в приемлемой для чтения другими форме отнимает больше времени, чем их получение. И по ходу аккуратного грамотного оформления вылазят такие тонны багов в алгоритмах, формулах и понимании, что готовый документ приходится по нескольку раз переписывать с нуля, меняя всю парадигму изложения (хотя когда начинаешь писать первый раз, кажется, будто уже всё ясно).

— gegel (19/08/2014 20:22)   

Когда-нибудь gegel для себя откроет

Представляете, я это давно открыл. Но что я могу сделать? Действительно, хорошее оформление – это титанический труд, сравнимый с остальной частью разработки. И на это уходит масса времени. Но у меня, к сожалению, нет оформительского отдела и нет даже помощников. Поэтому приходится царапать на коленке, в Word – да как угодно, лишь бы быстрее. Ведь помимо это есть другие важные задачи.
Остается надеяться, что информация, вложенная в нацарапанное, будет полезна. А по поводу багов – тоже абсолютная истина – я за сегодня перегрузил эти несчастные доки на сайте раз 10, вот только сейчас в последний раз. Но варится в собственном соку, пытаясь достичь совершенства в одиночку и выдать на гора гениальное коробочное решение – тоже не выход.

— unknown (19/08/2014 21:27)   
Я же упоминал про слайды Кравчика^[link107], ссылку на которые вы же вроде мне и присылали. Нигде стрелки между буквами в формулах не рисуют. Это вообще не нужно. Нужна некая смесь псевдокода с пошаговой диаграммой состояний. В особо экзотических случаях через графы представляют.

Можете хоть от руки нарисовать и отсканировать, как Шамир и прочие патриархи. Все знают, что они гениальные. Они могут себе позволить, чтобы за ними разбирали любые каракули.

— Гость (19/08/2014 22:20)   

Неанонимно же! Почерк спалится. Это как своё фото выложить.

— gegel (20/08/2014 00:01, исправлен 20/08/2014 00:08)   

стрелки между буквами в формулах не рисуют

Да, стрелки – это была неудачная идея. Я буду безмерно Вам благодарен, если Вы найдете время вникнуть в протокол ( хотя-бы по описанию в /comment82805^[link125] ) и намекнете, что лучше для восприятия со стороны. Очень тяжело, сварив это все самому, сообразить, как лучше для понимания преподнести другим. Как и в случае с Торфоном, многое мне кажется естественным, но, оказывается, может быть истолковано по другому. Например, Ваш вопрос по поводу генератора g (basepoint в эллиптике).
Но сейчас важнее другое – вообще имеет ли право этот протокол на существование? Кроме Вас вроде как и не с кем посоветоваться...

PS: я все же добавил ID_B и в ответ, и под хеш, иначе возможна классическая UKS атака. Что касается TorChat, то там это не актуально по определению, т.к. нет, собственно, KS: нет своего слоя шифрования.

— Гость (20/08/2014 02:08)   

На pgpru тоже. LaTeX: \leqslant, pgpru: &leqslant;, на печати: ⩽. И таких примеров много, html-коды во многом похожи на LaTeX.

— gegel (20/08/2014 08:48)   

Нужна некая смесь псевдокода с пошаговой диаграммой состояний.

Набросал еще один вариант:
http://torfone.org/download/xmail_txt.pdf
на русском, хорошо структурированный и с форматированием в т.ч. цветом.

— Гость (20/08/2014 11:21)   
Лучше, но всё же:

gegel, ваши фразы типа «тот час^[link127] заменяется сгенерированным новым» вас вообще не смущают? Ну вот хотя бы с точки зрения не грамматики даже, а логики. Мог бы «тот арбуз замениться новым», но в данном случае заменяют не арбуз, а час. Вы чувствуете отличие буквального смысла от иносказательного? Где по смыслу грамматической связи «час» — это часть наречия, а где существительное — чувствуете? Таких перлов у вас в текстах (и форумных постах) много, и я уже начинаю сомневаться, нормальный ли я. Вот скажите, на этом форуме я один только вижу все эти косяки, для остальных они прозрачны (SATtva не в счёт)?

По существу если, то не надо писать «наш_последний_сгенерированный_приват». Придумайте для него обозначение, опишите список обозначений в начале статьи, а в самой статье/алгоритме пользуйтесь готовыми обозначениями. Слова PRF/PRP/Adv и пр. взялись именно оттуда. Где-то Key пишут, где-то ещё как-то, вы же этих криптостатей большего моего перечитали, неужели у вас не появилось собственного чувства, как надо писать?

— unknown (20/08/2014 12:02)   

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

Например, предыдущие 16 ключей, да блин это же {K_n-16 … K_n-1} или как-то так хотя бы обозначается, ну и т.д. Чтобы это разобрать надо вместо автора всё переписать по своему, привести в нормальнй вид и поместить в наглядном виде перед глазами, чтобы оно в голове отложилось и можно было спокойно думать.

Я вот в своей формуле чуть ли не с полгода спустя как ошибку нашёл, хотя она у меня в LaTeX была набрана и в закладках лежала для регулярного просмотра. И это был примитивный трёхстрочник, а не безструктурная простыня!

— gegel (20/08/2014 12:22)   

это же {Kn-16 … Kn-1}

Ну, уж последний документ старался писать для домохозяек.

а как делать по-нормальному — сто раз было сказано. Какая-то помесь из самых жутких стандартов

Я и сам ситуацию адекватно понимаю, так что все говорите прямо :) Но даже от автора к автору в серьезных работах стандарты бывают совсем разные. У меня их, по видимому, совсем нет. Но когда я впервые читал описание OTR, а затем описание Axolotl, то в душе возмущался не меньше вашего. На самом деле, протокол не такой и сложный, и разбирать алгоритм там особо и нечего. Другое дело – криптографические тонкости, но до этого дело пока не дошло.

Вобщем, с формой все понятно и лучше пока не будет: и так ушла масса времени на это. А что касается сути, то пока еще надеюсь на конструктивные замечания. Но если нет – то нет :(

— unknown (20/08/2014 21:04, исправлен 22/08/2014 09:47)   

Ну, по-крайней мере, если вы считаете, что лучше по минимуму светить айдишниками под чистым PKE и запрятать их от греха подальше, чтобы затем методом перебора подбирать все входящие сообщения под свою секретную половинку, то под влиянием вашей идеи (хотелось бы доказать, что это не перестраховка), я предлагаю и свой модифицированный протокол, где получатель подбирает свои ранее использованные параметры для вычисления правильного s и пытаясь подобрать связанные с ними id получателя.

X = g, p, g^a mod p
Y = g, p, g^b mod p
s = KDF ( g^a )^b mod p = KDF ( g^b )^a mod p
s' = KDF (s)

A → B: MDC_PKE_B (id_A, X)
B → A: MDC_PKE_A (Y, HMAC_s (id_B, id_A, X, Y))
A → B: MDC_PKE_B (MDC_SE_s' (Message), HMAC_s (id_A, id_B, Y, X, Message))

Вариант с непрерывной перепиской и пересогласованием (возможны дальнейшие варианты и исправления):

Round for s=0

A → B: MDC_PKE_B (id_A, X₀)
B → A: MDC_PKE_A (Y₀, HMAC_{s_0} (id_B, id_A, X₀, Y₀))
A → B: MDC_PKE_B (MDC_SE_{s'_0} (Message), MDC_SE_{s_0} (X₁), HMAC_{s_0} (id_A, id_B, Y₀, X₀, X₁, Message))

Round for s=1

B → A: MDC_PKE_A (Y₁, MDC_SE_{s'_1} (Message), MDC_SE_{s_1} (Y₂), HMAC_{s_1} (id_B, id_A, X₁, Y₁, Y₂, Message))
A → B: MDC_PKE_B (MDC_SE_{s'_1} (Message), MDC_SE_{s_1} (X₂), HMAC_{s_1} (id_A, id_B, Y₁, X₁, X₂, Message))

Round for s=2

B → A: MDC_PKE_A (Y₂, MDC_SE_{s'_2} (Message), MDC_SE_{s_2} (Y₃), HMAC_{s_2} (id_B, id_A, X₂, Y₂, Y₃, Message))
A → B: MDC_PKE_B (MDC_SE_{s'_2} (Message), MDC_SE_{s_2} (X₃), HMAC_{s_2} (id_A, id_B, Y₂, X₂, X₃, Message))

…

Round for s=i

B → A: MDC_PKE_A (Y_i, MDC_SE_{s'_i} (Message), MDC_SE_{s_i} (Y_i+1), HMAC_{s_i} (id_B, id_A, X_i, Y_i, Y_i+1, Message))
A → B: MDC_PKE_B (MDC_SE_{s'_i} (Message), MDC_SE_{s_i} (X_i+1), HMAC_{s_i} (id_A, id_B, Y_i, X_i, X_i+1, Message))

…

и т.д.

Знака "║" для конкатенации (неформатированного объединения встык) я избегаю, полагая, что поля для параметров могут быть специально форматированными. У Кравчика принято обозначать также. Но, естественно, операция расположения параметров в функциях — некоммутативна: от порядка следования символов, разделённых запятыми, результат меняется.

Проблема даже не в этом. Понятно, что это черновик. Понятно, что там и откуда, мы это долго обсуждали. Понятно, что оформление — дело наживное.

Проблема в том, что вы излагаете идеи не для домохозяек, но и не для криптографов. А как будто для тупо кодеров. Бывает такая форма стандартов, при этом достаточно кривых. Их цель – чтобы самые тупые кодеры по пунктам поняли, что надо закодить, а возможные ошибки нашли по тестовым примерам. Но такие стандарты не рассчитаны, что кто-то будет анализировать идею, которая там заложена. Т.е., по форме — это инструкция к реализации без удобства обсуждения теоретической части.

— Гость (20/08/2014 23:10)   

Домохозяйки не будут это читать. :-)


Очень точно подмечено. Так и хочется написать эссе «как бы выглядели программы, если б математики их писали так же, как прогеры пишут матаналитику». Типа нафиг нам отступы — и так всё понятно, на интерпретацию программы это не влияет. Зачем ставить лишние пробелы? И так же разобрать можно. Зачем давать осмысленные имена переменным? Это только делает код длиннее, поэтому давать всё именовать как a1...a999. Зачем бить код на модули и функции? Давайте писать всё вместе, чтоб сразу было всё на месте, а где надо, нарисуем стерлки поставим goto. Зачем писать комментарии? Комментарии к коду — сам код; кому надо, тот разберётся. И т.д.

Unknown, а зачем вы выделяете формулы жирным шрифтом? Без него вам плохо видно или плохо воспринимается?

— gegel (20/08/2014 23:54, исправлен 21/08/2014 00:10)   

А как будто для тупо кодеров.

Вот тут согласен на 100%. Как для себя писал :) Когда поздно ночью пытаешься переложить какой-то протокол (например, тот же китайский NIDA выше по теме) на рабочий С-код, то именно так и хочется видеть описание. Одновременно анализировать и кодить нереально хоть тупо-кодеру, хоть и не-тупо.

поставим goto

читал топик про ФП и с трудом удержался от коммента: мазохизм ради идеи. Когда я считаю оптимальным использовать goto, я его используя, не взирая на "гласные и негласные стандарты". Это в продолжение темы: корячимся, делая черновики в LaTeX, первично отлаживая код в GCC, работая в Linux-консоли... Я не готов отказаться от благ цивилизации ради идеи. И не одинок: китайцы делают embedded-разработки в основном в средах под Windows, сопроводительный софт – на моем любимом Borland C++Buider 6.0 (вытягивая мышей компоненты), документацию – в Word. Причем очень быстро и эффективно. А у нас ракеты не летают почему-то...

я предлагаю и свой модифицированный протокол

Да, он бронирован, как танк.

В вашем примере непонятно, из каких DH-ключей выводятся s_n (что с чем паруется).

Я так понял, что s' выводится из того же секрета, что и s?

И чем обусловлено решение передавать ключ отдельным MDC_SE? Отрицаемостью?

PS: во второе сообщение (B->A) я все же включил ID_B и вне хеша из соображений удобства релизации: получатель должен подобрать подходящий файл. Если ID не указан в сообщении явно, то он должен храниться в этом файле на диске. Мне показалось безопаснее включать свой ID в ответ под PKE, чем хранить чужой ID у себя в файле контакта. Лучше оставить файл контакта анонимным, не привязанным к конкретному ID.

Может, есть смысл сделать первичные запрос и ответ неразличимыми? Тогда при утечке PGP невозможно будет определить, кто инициатор.

Не хотите добавить мастер-ключи и хеширование, как в Axolotl или в предложенном мною варианте? Отличная идея, модификация из Циммермановского SilentCircle, позволяет создавать управляемое ключевое окно и разруливать нарушения последовательности и потери ( см. advanced-ratcheting^[link128] )

— Гость (21/08/2014 01:29)   

Тут некоторые люди даже свои кустарные шифры предлагали анализировать по их C-коду, а не описанию. Напомнило фразу «хороший экспериментатор думает в терминах происходящей физики, плохой — в терминах показаний приборов, хороший теоретик думает в терминах смысла производимых действий, плохой — в терминах матвыкладок "я подставил это туда, и у меня получилось"». Здесь так же.


Если вы всю жизнь забивали гвозди оконным интерфейсом микроскопом, а потом вам дали в руки командную строку с автодополнением молоток и объяснили его преимущества, вам тоже будет неудобно. Переучиваться всегда тяжелее, чем учиться сразу правильно с нуля. Особенно C++^[link129] веселит: http://yosefk.com/c++fqa/picture.html.

б^[link130]удет наверное такое же количество весёлых публикаций и бесcмысленных исследований как у индусов и китайцев. Надо же рост и развитие будет показывать, раз у граждан такая наркотическая зависимость от пропаганды гордости за державу. У китайцев и индусов тоже видимо, как у всех больших интенсивно развивающихся стран с амбициями. А реальный результат будет очень маленький. По крайней мере на первое время.

— unknown (21/08/2014 11:26, исправлен 21/08/2014 12:57)   

Изначально обычным шрифтом была выделена часть протокола, относящаяся к вычислению DH и вычислениям «на месте», а передаваемые далее параметры были выделены жирным шрифтом.

Сейчас исправлено по другому принципу: вычисления DH и «на месте» остались вынесенными в начало протокола, а жирным шрифтом выделены названия функций в формулах, названия шагов и заголовки.

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

В каждом раунде i генерятся секретные параметры a_i, b_i и соответствующие им открытые X_i, Y_i. Ключ s_i выводится для параметров с одинаковым i. Поэтому, кроме нулевого раунда, совместно выведенный s_i используется для передачи симметрично шифрованных сообщений дважды, в одну и в другую сторону. А параметры для s_i+1 (для следующего сеанса связи) передаются также в текущем сеансе, при этом остаются связанными с текущими параметрами: если в текущем сеансе выявлено, что согласование прошло неверно, то и следующий сеанс согласовать не удасться.

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

Это сделано только для одной стороны, так что отрицаемость от этого зависит слабо. Это позволяет сделать несколько вещей:

Только сторона, знающая текущий правильно согласованный s_i, может расшифровать новую половину ключа и тем самым проверить значение HMAC_{s_i}, в которое также включена половина нового ключа вместе со старыми. За счёт такого дополнительно связывания сторонам легко убедиться, что никто не вклинивается с момента первоначального установления контакта, не передавая при этом больше своих id в открытом виде.

Пусть все перебирает.

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

Если сторона захватила секретный PKE-ключ стороны B (SK_B) и при этом записала всю переписку, она всё равно может расшифровать только параметры id_A, а расшифровав ещё и все X_i и Y_i, она не сможет подобрать id_B, поскольку не может по ним вычислить s, так что она не проверит HMAC и не расшифрует SE-переписку. Но ведь она и так знает, что украла ключ стороны B с id_B и взяла переписку с неё.

А если она украдёт ключ стороны A, то без дополнительных сведений, она не узнает, с кем связывалась сторона A. Если используется анонимный канал связи, то инициатор не скрываем при захвате секретного PKE-ключа отвечающего, а вот при захвате секретного PKE-ключа инициатора, отвечающий остаётся скрытым. Т.е. наблюдается скрытность отвечающего в рамках PFS. Как добиться такого и для инициатора — не знаю. Разве что договориться о секретном позывном вместо id в нулевом раунде, но это аналог совместного секретного ключа, который знают обе стороны.

При этом, отрицаемость сохраняется, если не путать её с нераскрываемостью в рамках PFS: любая из сторон может утверждать, что эти сообщения сфальсифицированы и/или подброшены, так как никто из сторон их не подписывал.

Посмотрю ещё. Пока надо этот минимум довести до ума, и так уже с самого примитивного уровня много накручивается по необходимости.

---

Я вообще подозреваю, что в протокол надо включать процедуры обработки ошибок согласования, процедуры реакции на откат к предыдущим значениям, перезапросы, защиту от повторных отправок. И если это всё сделать как настоящий продуманный стандарт, то он будет столь же громоздкий, как какой-нибудь SSL. А если к нему доказательства безопасности подгонять, то это будет целая серия больших теоретических работ.

Или это будет просто шифрпанковская поделка с китайским колоритом, которая просто как-то работает, радуя покупателей пользователей (и их противников). Ведь сами пользователи проверить качество безопасности не смогут, в отличие от качества обычных товаров. Так что, китайский эмпирический подход здесь не годится.

P.S. Аутентификацию расшифрованного Message внёс ещё и под MAC. Теперь можно меньше доверять стойкости реализации функции MDC в GnuPG (или даже вовсе от неё отказаться, хотя карман не тянет, она всё равно по умолчанию используется), а опираться на стойкую аутентификацию по совместно выведенному симметричному ключу в HMAC. MDC, похоже остаётся критичным только в первых двух шагах с PKE и тольео в нулевом раунде.

P.S.S. С Keccak-Sponge^[link131] (рис.4, 5) всё выглядело бы намного проще — один нешифруемый параметр Y_i передаём в открытую, всё остальное в скобки без повторений и результат MAC от хвоста шифрования.

— gegel (21/08/2014 13:43, исправлен 21/08/2014 14:00)   

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

Ясно. Дважды – не совсем хорошо в теории. Логика OTR и Axolotl другая: допустим, А вводит ключи a, c, ...
В вводит b, d... Секреты парятся как ab, bc, cd... по одному в каждую сторону. В вашем примере: ab, cd в обе стороны каждый. Но, возможно, в этом есть и преимущества, надо подумать.

в которое также включена половина нового ключа вместе со старыми.

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

Пусть все перебирает.

В любом случае все перебирает. Но вы абстрагируетесь от реализации: ведь предполагается, что файлы контактов псевдонимны (они не содержат ИД) И где мне, открыв очередной файл, брать ИД, чтобы проверить MAC? Вариантов два: или отправитель дополнительно включает свой ИД в свое сообщение вне хеша, или я храню чужие ИДы в файлах контактов (тогда файлы становятся "именные"). Меньшим злом мне показался первый вариант.

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

Вот я и предлагаю добавлять ID во второе сообщение и рандом вместо MAC в первое, чтобы невозможно было по длине и содержимому (кроме ИД, остальные данные выглядят как рандом) отличить сообщения A->B от B->A в случае утечки PGP.

Аутентификацию расшифрованного Message внёс ещё и под MAC.

Это разумно, сам хотел предложить это сделать.

PS: и еще вот что приходит на ум. Задачей аутентифицированного IKE является однозначно связать вводимые эфемеральные ключи со своими ИД. Таки образом, эти ключи становятся псевдонимами ИД для участников и могут быть использованы вместо ИД в следующих обменах. Может, есть смысл оставить ИД только в первичном сеансе, а затем использовать ключи предыдущих сеансов вместо ИДов под МАС? Это существенно облегчит реализацию и избавит от необходимости делать файлы контактов "именными", храня в них ИДы. При захвате компьютера может весьма помочь выкрутиться.

PPS: Все же найдите время вникнуть в реализацию Axolotl (если нет желания возится с каракулями его варинта в моем исполнении). Мокси и Тревп – таки гениальные ребята, и из их протокола можно взять оригинальные идеи, которые, в сочетании с армированностью вашего протокола смотрелись бы замечательно.

— unknown (21/08/2014 14:59, исправлен 21/08/2014 15:42)   

Хорошо, в нулевом раунде можно обменяться ID в открытую, забив HMAC рэндомом. А в последующих раундах включать в Message, которое шифровано симметричным ключом: «Алиса — Бобу», «Юстас — Алексу» и т.д. Вообще, подразумевается, раз Алиса помнит куда писать Бобу, то она помнит или у неё где-то хранится его id — отпечаток PGP-ключа, например. Вообще, айдишники, также как и секретные параметры DH хранятся на диске в зашифрованном паролем виде (как, впрочем и закрытые ключи). Если у какой-то из сторон перехватят закрытый ключ и пароль к нему, то из-за PFS не смогут разве что прочесть ранее переданные сообщения. Но вытащить список предполагаемых адресатов из компьютера всяко смогут. Это ведь не относится к отрицаемости?

— gegel (21/08/2014 15:41)   

забив HMAC рэндомом.

Нет-нет, ни в коем случае! Я вот что имел в виду:
A → B: MDC_PKEB (idA, X, R) R-рандом по длине совпадающий с HMAC.
B → A: MDC_PKEA (idB, Y, HMACs (idA, idB, X, Y))
Исключать idB из-под HMAC нельзя, Вы сами на это указали. Иначе возможна UKS: А соглсовывает ключ с E (при активном сочувствии B), будучи уверенной, что делает это с B. А далее – как на слайде Кравчика с F19.

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

Не прошло и пары часов, как до меня дошла Ваша мысль: действительно, злоумышленник, записывающий трафик на стороне участника, позже при утечке PGP, в любом случае может определить роль участника по направлению сообщения.
А злоумышленник, перехвативший сообщение где-то по средине анонимного транспорта, все равно не знает, чей ключ ему нужен для дешифровки. Так что смысла вводить R для неотличимости запроса от ответа особо и нет.

— gegel (21/08/2014 19:20)   

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

Не проще ли будет сделать так, чтобы программа/скрипт изначально хранили все (включая саму себя) в TrueCrypt?

Но вытащить список предполагаемых адресатов из компьютера всяко смогут

Список то смогут вытащить, другое дело, что в нем будет указано: он может быть псевдонимный и не содержать реальных ID. То же касается и адресов: это могут быть специально заведенные онион-адреса. Ведь вся затея с динамическими псевдорандомными идентификаторами и поиском по файлам и состоит в том, чтобы нигде не светить ИД долговременных ключей в процессе переписки после IKE.

— Гость (22/08/2014 01:54)   

Да, так смотрится намного лучше. Вам на заметку: названия шагов и прочего, чтоб они не сливались с основным текстом, можно писать как заголовки 5-го ранга:

Round for s=0

Разметка:
=====Round for //s//=0=====

— unknown (22/08/2014 10:56)   

Спасибо за совет. Поправил.


Дисковое шифрование крайне желательно, но оно опционально и не решает всех проблем. Когда-то, в начале использования PGP, дискового шифрования практически ни у кого не было. Тогда и решили: закрытый ключ хранить на диске только в зашифрованном паролем виде, а расшифровывать только временно в память, когда нужно пользователю — для расшифрования сообщений, подписи, изменения самого ключа и пр. Понятно, что такое не прокатывает на серверах, где живого пользователя нет. Но на рабочей станции такую годами сложившуюся практику лучше оставить. Например, у противника есть эксплойт, который может прочитать файл с диска и он утаскивает закрытый ключ. Но нет более редкого эксплойта, чтобы выполнить произвольный код или как-то иначе подсадить троян, чтобы перехватить пароль для его расшифровки. Поэтому в GnuPG все секретные ключи шифруются. Разумно также и шифровать все временные секретные параметры DH с id и только в таком виде писать на диск.


Здесь возникает масса соображений. Как мелких, так и принципиальных. Постараюсь привести по-возможности их все.

Стороны всё равно светят в переписке хотя бы один id. Если перехвачено начало переписки и перехвачен секретный ключ получателя вместе с паролем для его использования, то этот id всё равно будет извлечён. Конечно, внутри переписки, стороны могут договориться поменять id на клички-позывные. Могут даже попросить друг друга сменить адреса или выслать отпечатки новых ключей. Но здесь теряется доверие, возникает опасность навязывания контакта с третьей стороной.

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

Что у нас есть и формализовано:

1. Perfect Forward Secrecy. Треться сторона, имеющая запись всей переписки в шифрованном виде, захватившая закрытый ключ любой из сторон A или B и пароль на доступ к нему, не сможет расшифровать ранее переданные между ними сообщения из-за постоянного DH-пересогласования и удаления временного ключевого материала.
2. Deniability. Отрицаемость. Сторона A или B не может опубликовать переписку публично или для некоей отдельной третьей стороны так, чтобы формально убедить всех (или выбранную третью сторону) в её подлинности. Это так, потому что на сообщениях сторон не будет подписей. Значит сами стороны, или любой сомневающийся может утверждать, что переписка искажена, полностью выдумана или даже, что никакого контакта вообще никогда не было.

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

Вы предлагаете ввести в протокол защиту и от такого сильного противника. Но для этого протокол должен обладать неким свойством, не попадающим в два вышеприведённых. Они не обеспечивают решения требуемой задачи. Нужно задать и формально описать некое третье свойство, например Perfect Forward Anonymity (Pseudonymity). Но мне о протоколах с таким свойством ничего неизвестно. Более того, даже толком не сформулировав это свойство, не стоит ради приближения к нему вносить изменения в консервативно достигнутую защиту, обеспечивающую два основных свойства. А то может получиться, что и неясное третье свойство достигнуто не будет, и какое-то из двух предыдущих поломается (за счёт открытия противнику путей вмешателсьтва во взаимную аутентификацию, например).

Ну и ещё раз по практическим соображениям. Для шифрования и нераскрываемой для третьей стороны аутентификации используются OpenPGP-ключи. И ключи всех, с кем вы теоретически могли бы переписываться, будут висеть у вас на связке. Это как книга ваших возможных контактов. Если противник может добраться до компьютера и расшифровать все данные, то он может установить потенциальные контакты. Разве что, вынести все открытые ключи и контакты с id в шифрованном виде на какой-нибудь onion, а на своём компьютере хранить только свой закрытый ключ.

id нужны для того, чтобы стороны точно знали кто отправляет сообщение кому и за счёт этого не было вмешательства в аутентификацию. Конечно, можно вместо прямых id ввести какие-то rolling id, т.е. псевдослучайные значения, завязанные на секрет от предыдущего согласования. Axolotl что-то похожее и пытается сделать, использовав две пары DH-согласования ключей для получения двух различных s в одну и в другую сторону, а заодно и решения вопроса, кто и кому отправляет сообщения. Но у нас всё завязано на OpenPGP. И если аутентификация собъётся, то стороны могут откатиться к исходному ключу OpenPGP и начать всё с нулевого раунда. А для этого надо помнить id-ключей и передавать, по крайней мере в первом запросе, именно их.

Ещё в Axolotl есть KDF от текущего ключа вместо пересогласования по DH. Это, чтобы задать окно безопасности на несколько сообщений, отправляемых за короткое время, чтобы не ждать ответа от другой стороны и самому создавать новые s в одностороннем порядке, так чтобы другая сторона могла вопроизвести этот процесс. Это такой суррогат PFS при помощи средств только симметричной криптографии, удобный для короткого временного применения, его и к предложенному мной протоколу прикрутить несложно.

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

— gegel (22/08/2014 21:01, исправлен 22/08/2014 22:55)   

Сторона A или B не может опубликовать переписку публично или для некоей отдельной третьей стороны так, чтобы формально убедить всех (или выбранную третью сторону) в её подлинности.

Это расслабленное определение отрицаемости, оно касается лишь содержимого переписки. Полная отрицаемомть дает возможность отрицать факт участия в переписке.
В данном протоколе хотелось бы достичь отрицаемой аутентификации (формальное определение есть тут^[link134], 2.1). Я частично ориентировался на сценарий 2^[link135] (стр.1), предложенный Raimondo и Gennaro (одна из их работ тут^[link136]). Там вводится понятие forward deniability (созвучное с вашей Perfect Forward Anonymity). В другой работе^[link137] поддается сомнению возможность достижения сильной отрицаемости и вводится свое расслабленное понятие peer_and_time deniability (раздел 4).
PS: вот еще работа Кравчика^[link138] с общей формализацией понятия отрицаемости и анализом SKEME и SIGMA

Отрицаемость не работает, если третья сторона сама захватывает или взламывает Такому противнику доказательства не нужны

По вышеприведенному сценарию она должна работать. Но не путайте роль информанта и судьи (по первой ссылке).

Но вся эта отрицаемотсь интересна нам с вами, но вряд-ли – практикующим террористам/педофилам/наркодиллерам: их все равно будут бить не по паспорту. Поэтому я исходил в основном из практических соображений, оценивая возможные последствия от вполне реальной ситуации: захвата компьютера одного из участников уже после аутентификации, в процессе переписки (при этом второй участник не является информатором, иначе об отрицаемости речь не идет). В этом случае считаем, что все пароли будут выданы под давлением, поэтому толку от обычного шифрования приватной информации никакого. Другое дело – скрытые TrueCrypt контейнеры, я бы предпочел их в любом случае.

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

Самое первое, что сделает даже участковый – посмотрит вашу телефонную книгу. Ценное свойство Axolotl – скрыть реальные ID, заменив их псевдонимами (причем постоянно меняющимися в процессе переписки), надежными для сторон так же, как и ИД, но выглядящими рандомно для злоумышленника, получившего доступ к компьютеру и слушающего переписку до этого. Если аутентификации сбивается, то можно рискнуть начать с начала (момент выполнения IKE – уязвим для отрицаемости факта контакта), но опять же, удалив PGP-ключи контакта после согласования. Именно поэтому я и не хотел перманентно заворачивать все сообщения в PGP.

Ещё в Axolotl есть KDF от текущего ключа вместо пересогласования по DH. Это, чтобы задать окно безопасности на несколько сообщений

И еще буфер для хранения неиспользованных ключей (несколько выведенных наперед (KDF) со старого в момент согласования нового, а также пропущенные при последовательных KDF). Это и есть та фишка, которая делает возможным переписку по email: опоздавшие сообщения читаются в определенном регулируемом окне. Т.е. адаптация OTR к условиям почты (обсуждалось в начале темы).

— unknown (23/08/2014 13:22)   
Введём понятие Synthetic Pseudo Random Forward Deniable ID. Слово "synthetic" здесь не лишнее, так как означает вывод псевдослучайного параметра из определённых параметров сеанса и это слово из распространённой терминологии. Пусть те параметры раунда (Round Parameters), которые у нас идут под HMAC, обозначаются как RP.

Тогда, каждая сторона на этапе своей отправки вычисляет и сохраняет для следующего раунда SPRFDID_i+1 = KDF (HMAC_s (RP_i)). Это же она делает для противоположной стороны, на основании данных, полученных на шаге приёма.

Пусть все шаги нулевого раунда остаются такими же, как есть. Инициатор Алиса всё равно должна один раз послать свой id в открытую. Хотя Боб уже со второго шага нулевого раунда может заменить свой id на синтетический, ему это не нужно — если Алиса заинтересована в удалении секретных DH-параметров также,как и Боб, то не зная s, id_B под HMAC подобрать невозможно. Зато, на первом раунде стороны переходят на SPRFDID_{A_1} и SPRFDID_{B_1}, вычисленным по результатам предыдущего раунда.

Получается, что связь между всеми параметрами раунда и даже отправленными сообщениями переходит на параметры DH для следующего раунда и на синтетические ID. Эта связь заверяет DH и ID, но делает ID отрицаемыми — ведь предыдущие s и необходимые для его вывода параметры предыдущих раундов уничтожаются. Сами сообщения при этом, в принципе можно сохранять, если они чем-то ценны.

В таком виде стороны конечно могут после согласования заменить регулярные PKE-ключи на более анонимные, чтобы после провала, раскрытие ключей не показывало их привязки к кому-либо. Концепция SPRFDID будет отрицаемо для противника тянуть на себе всю аутентификацию, с самого начала (нулевого раунда). Но это не устраняет опасности атаки втёршегося в доверие переотправщика. Так что, сторонам следует делать выбор: рисковать хранением публичных ключей друг друга на связке или поменять ключи и рискнуть столкнуться с определённым вариантом злонамеренного поведения одной из сторон. В принципе, SPRFDID уменьшает эту вероятность — если сторона A уже списывалась с E, она будет хранить SPRFDID с предыдущего сеанса, если не списывалась — она спросит у злонамеренной стороны B, почему та делает перезапрос SPRFDID. Хотя строгой защиты от переотправки при полной отвязке ключей это не даёт. Только позволяет заподозрить неладное, на что злонамеренная сторона всегда способна выдать правдободные оправдания. Отрицаемость — это штука обоюдоострая.

Совет на будущее. Не пишите везде H как хэш, если результат не идёт о самой низкоуровневой детализации протокола. Потому что (H)MAC и KDF — это не просто тупо взять хэш. Это должны быть разные вещи и в теоретическом плане, и в плане реализации. В плане теории отличие MAC от KDF будет важно, если будет проводиться формальное доказательство стойкости протокола: будет виднее, что в каком виде заменять на PRF. В плане реализации: SHA-2 напрямую использовать нельзя, нужен HMAC и KDF отдельно. Причём, сам KDF может быть реализован через HMAC с определённым параметром вместо ключа, для вывода производного ключа произвольной длины, если нужно растянуть ключ меньшего размера до большего. При переходе на Keccak всё значительно упростится, но там тоже важно знать в каких режимах его использовать для MAC и KDF, какие режимы комбинировать, как подавать и снимать параметры.

KDF и MAC — это определённые устоявшиеся понятия, которые могут быть заменены разными практическими конструкциями, которые ранее исследованы теоретически. Когда вместо KDF и MAC везде тупо подставляют хэш, то про такое говорят poor-man-KDF, poor-man-MAC. Авторы Axolotl — похоже, poor man's в этом смысле.

— gegel (23/08/2014 14:04, исправлен 23/08/2014 15:00)   

Концепция SPRFDID – Именно то, о чем я постоянно думал, но четко формализовано Вами.

Хотя Боб уже со второго шага нулевого раунда может заменить свой id на синтетический

После вашего замечания я тщательно анализировал варианты на предмет UKS: заменить может, но в параметры, с которых этот синтетический ИД будет выводиться, в нулевом раунде Боб должен обязательно включить свой рельный id.

Сами сообщения при этом, в принципе можно сохранять, если они чем-то ценны.

Одно время у меня была идея пойти еще дальше: полностью отделить DH-согласование для выведения ключей шифрования от параллельного DH-согласования для аутентификацииключей (передачи доверия по цепочке). Т.е. в каждое сообщение вкладываем по 2 DH-ключа и два MAC: одним заверяем ключи, как описано выше, вторым только аутентифицируем сообщение (этот МАС выводится с использованием того же секрета, что и ключ шифрования: полученного с помощью "чистой" DH). Получаем интересное свойство: любой может написать письмо получателю и аутентифицировать текст, но получатель (и только он) всегда сможет определить, действительно ли письмо от отправителя. Теперь можно отрицать наличие (или следы) сообщений на диске: да, я получил и прочитал сообщение (файл), думая, что оно от моей бабушки. Но оно оказалось недоверяемым, и его содержание отношения ко мне не имеет.

Потому что (H)MAC и KDF — это не просто тупо взять хэш.

Да, это я усвоил еше год назад по Вашему замечанию о выведении ключей с DH-секрета. "Исправление" SHA путем алгоритма HMAC тоже разобрал. Хотя не совсем почувствовал теоретическую разницу между HMAC и KDF (внешнее различие – произвольная длина выдачи в KDF и фиксированная в HMAC). Но после работы над библиотекой Keccak это как-то стерлось, что, конечно, в общем случае неверно.
Надо посмотреть, какую хеш-функцию ребята используют в Open WhisperSystems TextSecure: если, например, blake2^[link139], то их тоже можно понять.

— unknown (23/08/2014 18:18, исправлен 23/08/2014 18:55)   

От таких вариантов я сознательно отказывался, ограничив себя одним обменом DH. Наплодив много пар DH можно было бы и разные симметричные ключи s для A → B и B → A в одном раунде использовать, и каких-то других свойств достичь. Но, помимо лишней ресурсоёмкости, выходит слишком громоздко, сложно и некрасиво. А так всё попарно группируется в раунды, каждому раунду соответствует согласованный ключ s_i, а для следующей итерации раунда готовятся параметры i+1.

Я бы не стал ради этого так сильно загромождать протокол. Но если очень хочется, то можно сделать по-другому, сохранив всё в духе оптимизированного минимализма. Вместо {Message} в шифрованном виде под s отправляется {R, Message}, где R — сгенерированное отправителем случайное число размером 128 или 256 бит. Во все проверки и выведение параметров протокола подставляется {R, Message}. Когда всё проверено и параметры для следующего сеанса выведены, пользователь извлекает {Message}, а R — уничтожает. Теперь {Message} можно спокойно хранить. Сторона, узнавшая все предыдущие секреты, не сможет его аутентифицировать.

Для предполагаемого протокола придумалось название. Или напрямую SPRFDID-DH, или близкое по согласным "Flat Spheroid".

The flat spheroid (an ellipsoid of revolution rotated about the minor axis)

"Revolutions of Geometry", p.179. © Michael O'Leary.

Также см.: "Early galaxy evolution from deep wide field star counts. I. The spheroid density law and mass function^[link140]", A.C. Robin1, C. Reyl1e and M. Creze. И "Stability of Bose-Einstein Condensates Confined in Traps^[link141]", TAKEYA TSURUMI, HIROFUMI MORISE and MIKI WADATI.

И эмблему в виде разукрашенного сплюснутого эллипсоида^[link142] можно нужно рисовать. Лучше в виде сетки с определённым числом ячеек и векторов. И не в виндовой программе, а в открытой. С экспортом в открытый формат svg. И домен с таким именем регистрировать.

— Кэп (23/08/2014 23:03)   

Если так глубоко лезть, то вас вообще никакая отрицаемость не спасёт: сами всё расскажете, что говорил собеседник, что не говорил, кто является собеседником, какая информация была вам передана и т.д. А какая разница, что пишется на диск или не пишется, если противник сделает live forensics, считав сразу всё содержимое оперативки? А если уже установлено негласное наблюдение, и содержимое экрана перехватывается скрытыми видеокамерами или восстанавливается в соседней комнате по излучению^[link143]? Что тогда поможет? Сетку Фарадея делать или сразу бункер рыть?

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

1. Нельзя с ней работать там, где проходной двор. Защита №1 — крепко запертые двери и окна. За 5 секунд противник не доберётся до компьютера, а этого будет достаточно для обесточивания системы.
2. Должно быть отработано на уровне автоматики: стук в дверь (мы даже не проверяем, от кого) — жмём на reset или power off (и вынимаем батарею, если есть). Ранее завершения процедуры двери не открываем.
3. Бессигнатурное и другие виды скрытого шифрования — ваш друг. Пусть ищут то, неизвестно что, там, неизвестно где.
4. Не общайтесь на приватные темы с тем, кто ничем не запятнан не имеет мотивов беспокоиться о защите данных или ещё не имеет достаточной квалификации для этого. Ваши данные куда быстрее утекут не от того, что прийдут к вам, а от того, что придут к нему (или, ещё проще, он запустит скайпик или браузер от того же юзера, от которого ведёт с вами переписку).
5. Не раскрывайте информации сильно больше, чем следует, даже если доверяете. Сегодня он друг, а завтра враг, но свои слова обратно вы уже не заберёте. Или сегодня он в расслабляющей домашней обстановке, а завтра ему будут в участке ломать пальцы, требуя рассказать о вас всё и вся.
6. Если у вас несколько друзей, которым вы полностью доверяете, не рассказывайте их секреты друг другу. Если утечка произойдёт по вине того, кому вы рассказали, вина будет на вас. И чем моложе человек, тем тяжелее ему хранить секреты — он всё равно будет стараться поделиться «самым интересным» хотя бы с кем-то, хотя бы с лучшими друзьями, обсудить это, похвастаться, заполучить долю их внимания и уважения. Риск таких действий лет до 30, думаю, вообще не осознаётся. Сама природа человека толкает его к этому.
7. Старайтесь не знать важной технической информации. Помните: вы себя которолируете не на 100%. При давлении (не говоря уже о пытках) вам будет намного легче не рассказать лишнего, если вы это лишнее действительно не знаете.
8. Даже сам факт обладания важной технической информацией (если это ваш случай) должен быть тотально засекречен и никогда никому не рассказываться, даже самым ближайшим друзьям. Нельзя говорить «я знаю это», потому что сегодня вы похвастались, а завтра может получиться так, что к вам придут нежеланные гости и попросят это рассказать.
9. Не светите список своих контактов. Накосячит один, а в гости придут ко всем. Помните об этом. Даже друзьям не раскрывайте список всех своих контактов, если в этом нет необходимости.
10. Самая надёжная защита — недоведение ситуации до того стадии, когда она понадобится, поэтому тотальное шифрование всего и вся, принцип разделения информации и контактов, анонимизация трафика — самые важные вещи в защите.

— Кэп_2 (23/08/2014 23:25)   

/comment58602^[link144]

— Гость (24/08/2014 04:04)   

Когда мне сказали, что работа должна быть в LaTeX'е, я пришёл домой вечером, взял книжку Львовского и начал читать. Ночь читал. Утром пришёл на работу, открыл текстовый редактор и начал писать в LaTeX'е. С тех пор я больше добровольно не использовал Word никогда. Если для вас освоить язык разметки LaTeX — проблема, то за протоколы даже браться не стоит — необходимые усилия несоизмеримы.

Я не представляю, как ваш проект можно достойно где-либо (хоть даже на сайте) представить без LeTeX. Это то, с чего всё должно начинаться, а не чем заканчиваться. Бросайте нахрен всё, берите доки и изучайте, LaTeX — это MUST KNOW. Без этого просто не о чем говорить. Любой специалист, увидев статью в ворде, отправит её в мусорное ведро тут же, он даже читать её не будет. Этим сейчас страдают разве что китайцы, накручивающие себе индексы липовыми статьями в таких же липовых китайских журналах и конференциях.


I^[link146]nformation Technology Journal:

У этого «журнала» даже нет страницы в википедии, и я почему-то почти уверен, что его нет ни в scopus'е, ни в WebOfScience (могу проверить, но лень). Но вышвырнуть такую статью в помойное ведро у меня возникло желание сразу же, потому что она написана в ворде, и я про такой журнал нигде и никогда не слышал (а должен бы, будь он нормальным). На практике это значит, что то, что там написано — бред с вероятностью близкой к 100%, а доверие — такое же, как к написанному на форумах. Было бы это не так, авторы наверняка бы послали свою работу в более достойный журнал, который, во-первых, не принимает ворд, во-вторых, индексируется основными БД, и, в-третьих, имеет приличный Impact Factor.

— Гость (24/08/2014 04:41)   

Я бы предпочёл, чтобы gegel слез с винды и перестал рекламировать бред в виде TC.

---

Как убить TrueCrypt своими руками

Показываю, как сделать скрытый контейнер на произвольном диске всего несколькими командами:

1. Пусть у нас есть диск /dev/sda. Смотрим его размер в секторах (blockdev --getsz /dev/sda) и таблицу разделов, если есть (fdisk -l -u /dev/sda).

2. Выбираем с какого по какой сектор отмаппить в скрытый диск, чтобы не перекрывалось с записанными данными (номинально выбранные сектора могут относиться к чему угодно, хоть даже к размеченному пространству неподмонтированной файловой системы^*). Допустим, весь диск — это 912345678 секторов, а вы хотите отмаппить сектора с 500000000 по 700000000 в новое виртуальное блочное устройство, играющее роль диска. Это делается так:

   # dmsetup create YourNewDevice --table '0 200000000 linear /dev/sda 500000000'

   Можно объединить в одно виртуальное блочное устройство и сразу несколько областей на диске — для этого пишете таблицу в файл и кормите ею dmsetup:

   # cat /path/to/YourTable
   0 200000000 linear /dev/sda 500000000
   200000000 10000 linear /dev/sda 700000000
   # dmsetup create YourNewDevice /path/to/YourTable

   (в последнем примере добавили ещё 10000 секторов диска к первому устройству, взяв их после 700000000-го на диске). Можете сразу посмотреть размер нового устройства:

   # blockdev --getsize64 /dev/mapper/YourNewDevice

   Эта команда тоже его напишет:

   # fdisk -l -u /dev/mapper/YourNewDevice

3. Делаете на этом новом блочном устройстве бессигнатурное шифрование:

   # cryptsetup -c aes-xts-plain64 -s 512 -h sha512 \
     create YourCryptoDevice /dev/mapper/YourNewDevice

4. Теперь можете это устройство для удобства разбить на LVM-разделы (сделаем парочку, на 5G и 10G):

   # vgcreate Your_VG /dev/mapper/YourCryptoDevice
   # lvcreate -L5G -nYourLV1 Your_VG
   # lvcreate -L10G -nYourLV2 Your_VG

5. Форматируете ваши LVM-разделы под LUKS с ext4 и монтируете:

   # cryptsetup -q --use-random \
     -c aes-xts-plain64 -s 512 -h sha512 luksFormat /dev/Your_VG/YourLV1
   # cryptsetup -q --use-random \
     -c aes-xts-plain64 -s 512 -h sha512 luksFormat /dev/Your_VG/YourLV2
   # cryptsetup luksOpen YourFS1 /dev/Your_VG/YourLV1
   # cryptsetup luksOpen YourFS2 /dev/Your_VG/YourLV1
   # mkfs.ext4 /dev/mapper/YourFS1
   # mkfs.ext4 /dev/mapper/YourFS2
   # mount /dev/mapper/YourFS1 /path/to/your/dir1
   # mount /dev/mapper/YourFS2 /path/to/your/dir2

6. Отключение всего и вся, стирание ключей из памяти, возврат к исходному состоянию:

   # umount /path/to/your/dir1
   # umount /path/to/your/dir2
   # cryptsetup luksClose YourFS1
   # cryptsetup luksClose YourFS2
   # vgchange -an Your_VG
   # cryptsetup remove YourCryptoDevice
   # dmsetup remove YourNewDevice

Судя по man dmsetup, всё это могло успешно работать, как минимум, ещё в мохнатом 2006-ом году, просто местная pgpru-публика в то время об этом почему-то не знала (unknown только-только перелез на Linux, SATtva продолжал насиловать труп винды, а я просто не знал, и подсказать некому было).

По-моему, связка dmsetup + LVM + LUKS — это просто, гибко и универсально. Понятно, что то же самое можно было бы проделать не со всем диском, а с любым другим блочным устройством — например, разделом диска /dev/sda2.

Если этот метод сопрячь с бессигнатуркой-лайт^[link148], добавить Xen с бэкапами гостевых ОС, автоматизацию поиска неиспользуемых секторов и автоматизацию запрятывания загрузочного носителя в этот же диск, то получится настоящая бессигнатурка, превосходящая по своим возможностям скрытые ОС TrueCrypt (не будет завязки на FAT^[link149] и сомнительный софт, каким TC является^[link150]), Qubes^** и Whonix (есть виртуалки, но нет отрицаемого шифрования), а также Tails с Liberte (нет виртуалок).

---

^*Наверно, можно работать и с подмонтированной файловой системой через дополнительные опции dmsetup типа multipath.
^**Точнее, у Qubes будет одно преимущество^[link151], которое тут не достигается.

— Гость (24/08/2014 04:46)   

Когда подключаете это же устройство второй раз, правильность пароля можно проверять командой vgscan. Если она находит volume group с именем Your_VG, значит, пароль верный, если нет, делаете cryptsetup remove Your_VG и повторяете create-команду снова.

— gegel (24/08/2014 15:04, исправлен 24/08/2014 15:20)   

И эмблему в виде разукрашенного сплюснутого эллипсоида нужно рисовать.

Название и эмблемма – это хорошо, но на каком варианте протокола все-же остановились (и остановились ли)? Хотелось бы увидеть весь протокол в LaTeX (шучу, конечно: за Вами, unknown, я готов вычитывать любые каракули, как за Шамиром :) ).

Мои мысли по работе с защищённой информацией

Хороший пример здорового практицизма. Пока мы тут пытаемся втиснуться в модель Raimondo & Gennaro, в реале существуют совсем другие модели, и если предполагается разработка для практического использования, то именно они должны быть приоритетными.

Бросайте нахрен всё, берите доки и изучайте, LaTeX

Я тоже когда-то за ночь прочитал Львовского, открыл текстовый редактор и начал писать в LaTeX. Но вот только эйфории от этого не получил. Понятно, что презентабельный вариант придется готовить именно так (LaTeX – идеальное решение для единого стиля журнала, как html-css для сайта), но в процессе рутинной работы использую то, что для меня удобнее.

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

Честно, я специально привел эту ссылку, чтобы посмотреть реакцию, и она предсказуемо не заставила себя ждать. А вот АНБ, наверное, не брезгует это читать, выуживая ценные идеи или для своих разработок, или чтобы блокировать их по пути в WebOfScience-издания.

gegel слез с винды

С чего ради? Подавляющее большинство жителей планеты ею успешно пользуется. Для меня компьютер – инструмент для улучшения жизни, а не самоцель. Если бы я занялся практическим терроризмом, тогда другое дело.

перестал рекламировать бред в виде TC

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

сомнительный софт, каким TC является

TC пользуются даже дети, пряча секреты от родителей, в отличие от приведенного Вами варианта (попробуйте объяснить его практикующему террористу).

Если этот метод сопрячь с бессигнатуркой-лайт, добавить Xen с бэкапами гостевых ОС, автоматизацию поиска неиспользуемых секторов и автоматизацию запрятывания загрузочного носителя в этот же диск, то получится настоящая бессигнатурка, превосходящая по своим возможностям скрытые ОС TrueCrypt

Так сделайте коробочное решение c GUI, и убъете TC.

— Гость (24/08/2014 22:07)   

А что не так? Плоха память на разметку? Всегда можно поглядеть в книжку. Ну, комфорт, конечно, за один день не получить, нужно попрактиковаться, но насилий над собой вроде практически не требуется (в отличие от того же vim'а).


Какой смысл что-либо блокировать, если всё правильно оформленное принимается, как минимум, в arXiv и IACR? Если у автора не примут, будет скандал, но ни одного такого скандала не припоминается. АНБ вообще придерживается другой стратегии: всё утекшее рассекречивается, потому что считать засекреченной утекшую информацию бессмысленно.


Подавляющее большинство мух предпочитают говно. Если вы плывёте по течение и слепо ориентируетесь на мнение большинства, это повод задуматься, что что-то вы делаете не так.


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


По ходу, я даже вам это объяснить не могу.


Опыт показывает, что коробочные решения чаще всего приводят к такой же коробочной игрушечной безопасности. Нужна инструкция, как сделать, и готовый скрипт: запустил — и всё готово. GUI для этого ненужно. Думать, что вместо каждой команды удобнее иметь GUI-приложение с кнопочками — последняя степень невежества. Ещё немного, и можно будет перейти на термины «интернет у меня красный (opera), а у тебя синий (IE)».

— Гость (24/08/2014 22:33)   

Честно, когда я вам объяснял как исправить ваш абсолютно идиотский английский^[link152], я уже чувствовал, что ваш случай очень тяжёлый и запущенный. Просто люди, которые могут отсетственно что-то разработать, в вашем возрасте уже знают английский, а если они не знают, они не специалисты. Короче, был явный симптом.

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

Потом вы начали городить бред в вордовых файлах. Это уже никуда не годится. Вы, я так понимаю, никогда сами ничего серьёзного не писали, и серьёзных тем не прорабатывали, это по вашим попыткам написать что-либо техническое сразу видно. Даже если б у меня не было времени, и я б писал тексты при жутком нехватке ресурсов, такое говно я бы не породил, ей богу.

Теперь вы ещё начинаете говорить о том, что винда всему голова. Ну, у меня нет слов. У вас уже полный набор всех симптомов, хотя предсказать можно было ещё на самой первой стадии. Даже ntldr никогда не пиарил винду и признавался, что это просто сложившиеся обстоятельства, а не заслуга MS.

Чем вы после этого лучше того же ZAS? Тем, что вы сливаетесь на общих вещах, хоть в целом и признаёте научный подход к крипто (а по факту всё равно шифропанк получается), а он сливается уже на самых основах?

Я сколько слежу за вами, и не могу представить, как у вас может родиться нормальный проект. Этому препятствует всё от начала и до конца. Либо у вас должен быть руководитель, который вас заставляет, контролирует, ставит задачи и приоритеты, и нещадно порет за любое отклонение от нормы по принципу «я начальник — ты дурак» (так пишутся дипломные работы), либо вы как-то должны дозреть до этого сами (не видел в жизни ни одного такого успешного примера).

Основа основ — «сделай минимум, но сделай его хорошо». Детали и «лицо работы» первичны — если даже с ними что-то не так, то обсуждать по существу никто не станет. Неаккуратное офомление, вопиющие опечатки — сразу в мусорку, такую работу никто не будет читать, не будет отсылать рецензентам, исправлять коллективными усилиями и т.д. Даже с поправкой на то, что вы пока не пишете полноценную работу, а просто делаете набросок для обсуждения, это всё равно такой ужас, что даже в сотом приближении не годится.

— unknown (24/08/2014 23:28, исправлен 24/08/2014 23:32)   

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

Единственно, что можно отметить для практики и вынести в отдельную тему — как заслать человека в любую точку мира, где есть интернет и он мог с нуля поставить на месте чистую систему. Затем, пользуясь только паролем из головы, восстановить все контакты. Может быть шифрованные ID, находящиеся через поиск, может быть шифрованные UID на GPG ключа на серверах ключей. Восстановленное таким трудом — маленький список открытых отпечатков чужих ключей, свой собственный закрытый ключ. На месте всё это может быть минимизировано и в шифрованном виде записано на флэшке или даже распечатано на бумаге и творчески упрятано. Малое количество информации спрятать и замаскировать легко. Т.е. нечто вроде такого информационного зерна, которое хранится только в голове и которое прорастает в любом месте, где есть компьютеры и связь.

Есть интересные мысли — создавайте отдельную тему, там могли бы развивать дальше, а не путать всё в кучу.

Я уже где-то намекал в форуме, что перелез на него тогда, когда там не было не то, что dmsetup, там даже официального cryptoAPI не было в ядре и его приходилось накладывать отдельными кривыми шифрпанковскими патчами на ядро и утилиты, самому его править, чтобы синхронизировать с security-апдейтами ядра и т.д. И было время кучи сырых несовместимых наивных реализаций, про которые не было смысла ничего излагать.

В Linux есть несколько гуёв к cryptsetup. Тем, кто пользуется cryptsetup, они нужны примерно также, как и тем, кто не пользуется, т.е. никак. Даже к GnuPG для кого-то GUI более востребованы. А GUI для бессигнатурки — это оксюморон. Типа, смотрите все отвернитесь и не подглядывайте, у меня не просто затёртый раздел с рэндомом, у меня там бессигнатурка, а к ней GUI торчит.

Хотел в очередной раз переписать, но времени не хватает.

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

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

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

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

— Гость (24/08/2014 23:44)   

Пруф^[link154].


Пример в тему^[link155].

— gegel (25/08/2014 18:40)   

Честно, я специально привел эту ссылку, чтобы посмотреть реакцию

И реакция превзошла все ожидания. Ради Бога, извините, если это Вас лично обидело или затронуло больную тему.

Я сколько слежу за вами
в вашем возрасте уже знают

Мне кажется, Вы сделали ошибочные выводы

случай очень тяжёлый и запущенный

Все намного хуже – это вообще не тот случай, он не вписывается в приведенные оценки. Давайте расставим точки на i. Я никогда не был ни математиком, ни криптографом, и никогда ими не стану, даже если захочу. Никогда не буду печататься в тематических журналах, никогда не буду соискать диплом или PhD в CS (хотя бы потому, что у меня нет подходящего технического базового высшего и потому, что у меня уже давно есть PhD). Я просто приоткрыл для себя дверь в другой мир, но не собираюсь там оставаться. Предвидя вопрос о том, что же я здесь делаю: считайте, занимаюсь профилактикой болезни Альцгеймера (обычно рекомендуют учить японский, но CS – тоже вариант).

а доверие — такое же, как к написанному на форумах.

Как Вы верно заметили, форум – не CS-симпозиум, а место, где можно в произвольной форме поделиться мыслями: наивными, смелыми, иногда просто глупыми. Воспринимайте меня как наивного любителя (или просто игнорируйте) – и Вы не так будете нервничать, и, возможно, у unknown быстрее получится практическая реализация протокола отрицаемой электронной почты.

— Гость (25/08/2014 21:28)   

Господи, в чём у вас PhD? Люди, которые выстрадали диссертацию, грамотно писать умеют, и оформлять свои мысли в виде блок-схем/формул — тоже. Да, признаю, что вы пишете по-русски заметно грамотнее, чем остальные, но вот бы ещё с остальным так было..


Если вы знаете какая будет реакция какое будет к этому отношение, зачем это делать? Троллинга ради что ли? Вам хочется, чтобы вместо предметного обсуждения люди рапсылялись на очередное обсуждение прописных истин?

— Гость (25/08/2014 21:32)   

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

— unknown (26/08/2014 17:28, исправлен 26/08/2014 17:40)   

Пока лежит здесь^[link156].

Пофиксил вычисление s и s': они вычисляются параллельно, а не последовательно. Знание одного не даст узнать другой, нужно знать результат совместно выведенного DH-значения.

Также пофикшена ошибка, что начиная со второго раунда Y_i не надо передавать в текущем раунде. Он также, как и X_i берётся с предыдущего раунда, где передаётся под SE.

Возможно, где-то ещё будут ошибки-опечатки, смотрите внимательнее.

— gegel (26/08/2014 19:33, исправлен 26/08/2014 19:37)   

Господи, в чём у вас PhD?

Я стараюсь об этом или совсем не говорить, или шепотом. Но, если уж пошла такая пьянка, у Вас есть есть чувство юмора и под вами крепкий стул, то 14.01.02, защищена в 1997. И, чтобы повеселить окончательно, добавлю сертификат на семейную практику. Ну а теперь, как в том анекдоте про Ржевского: молчать, господа гусары!

смотрите внимательнее.

Вот что настораживает: в раунде n обе стороны вводят новые ключи X_n+1 и Y_n+1, шифруя их с помощью SEs_n, но не аутентифицируя. В следующем раунде n+1 одна из сторон первой отсылает сообщение, зашифрованное SE_n+1, выведенным с участием полученного, но пока не аутентифицированного ключа X_n+1 (или Y_n+1). Возможно, спасает PGP-обертка или MDC, или же я не заметил еще какой-то элемент, но это кажется не хорошо. Может, лучше передавать X_n+1 и Y_n+1 открыто (т.е. только под PKE: все же это публичные ключи), но аутентифицируя их с помощью MACs_n?
И еще одна мысль: зачем в выведение SPRFDID включать Message? Если это не улучшает безопасность, то в теории потенциально ухудшает отрицаемость.
Ну и совсем креатив: может, SPRFDID выводить с помощью того же s, что и MAC, но играя с параметрами (скажем, переставляя местами X и Y и оставляя на месте ID_A и ID_B? Конечно, это не улучшит свойства (а, может, и наоборот), но смотрится изящнее.

PS: спасибо за LaTeX-src, буду на них ориентироваться.

— unknown (26/08/2014 22:07, исправлен 26/08/2014 22:44)   

Медицинские работы бывают весьма сложными, особенно исследовательские с использованием физических приборов, но оформлены обычно отвратительно, да. Правда и не в ворде, а в каких-то пакетах вёрстки мед. пэдээфники выглядят несколько лучше. Я ориентируюсь в своих впечатлениях по зарубежным медпубликациям. Ну и кстати, вам есть куда стремиться, по примеру одного известного врача-анестезиолога^[link157], который самостоятельно изучал ВУЗ-овскую программу по компьютерным специальностям.

X_i+1 и Y_i+1, которые фактически извлекаются в текущем раунде, в последующем раунде обозначаются как X_i и Y_i и идут под MAC вместе с другими параметрами. Если их подменить, то результат MAC с вычисленным из них s не совпадёт.

Верно, у нас уже есть R, который всё равно удаляется после всех вычислений. После нулевого раунда стороны могут посылать друг другу разные R. Надо только приделать индексы R_A и R_B.

Раз будут R_A и R_B, то всё ещё проще и изящнее. Другое дело, что s и s' всё равно лучше иметь разные для MAC и SE, а поскольку в SPRFDID результат MAC обрабатывается KDF, то и было решено использовать s'. Кроме того, в изначальном варианте, туда включалось и Message, которое по вашему замечанию можно убрать. Если его не убрать, то использовать одинаковый s нельзя, так как результат вычисления такого же MAC уже передаётся в сеансе.

Ну и с перестановками хватит играть: id идут в порядке «от кого к кому», а X и Y также идут в том же порядке, что и в основном MAC. Некрасиво лишний раз переставлять, кроме как один раз попарно.

Надо также учесть, что в нулевом раунде R — одинаковые. И вообще надо подумать насчёт атак «отзеркаливания», чтобы стороны намеренно не посылали друг другу одинаковые X и Y, R_A и R_B и т.д. Неприятно, что R, который предполагалось удалять сразу после извлечения Message, теперь надо хранить до получения другого R ответной стороны. Т.е. в хранимых параметрах мы отрицаемой аутентификации не получаем в течении раунда.

Хуже того, так же как Perfect Forward Secrecy, так и Perfect Forward Deniability ломается для последующих сеансов после одного скомпрометированного. Если для PFS это не так критично: противник не может прочитать предыдущие сообщения, часть информации от него скрыта, то для PFD — это фатально. Информация то скрывается одна и та же. И если противник захватит все параметры текущего сеанса, то он может послать запрос другой стороне или пассивно дождаться ответа от неё и увидеть, что сторона корректно ответила на текущие секретные параметры, тем самым выдав свою аутентификацию. Нельзя только строго доказать, что предыдущие сеансы аутентификации имели место именно с ней, но это делает всю концепцию достаточно ограниченной.

Ещё можно вернуться к идее всё-таки использовать две пары X и Y параллельно, чтобы выводить разные s для передачи в одну и другую стороны, но пока я к этому не готов и если решить так делать, то это стоит оставить на самый заключительный этап. Также как и прикручивания цепочек KDF для удобства использования симметричного суррогата PFS в пределах некоего короткого окна времени.

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

Они очень черновые: лишние скобки в первой же формуле, нужные пробелы где-то включены в знак модуля, а где-то окружают его спецсимволами снаружи. Ужас, не ориентируйтесь на это пока. Правится очень на скорую руку, урывками между дел, а копипастить текст исходников и заливать отдельно рендеринг формул на сайт — тоже достаточно неудобно. Но хоть удобнее хранить, воспринимать и использовать в дальнейшем, чем обычную форумную вики-разметку.

— gegel (26/08/2014 23:09, исправлен 26/08/2014 23:19)   

X_i+1 и Y_i+1, которые фактически извлекаются в текущем раунде, в последующем раунде обозначаются как X_i и Y_i и идут под MAC вместе с другими параметрами. Если их подменить, то результат MAC с вычисленным из них s не совпадёт.

Возможно, я что-то недопонял, или же Вы меня неверно поняли. Допустим, в текущем раунде стороны получили друг от друга новые X и Y. В этом раунде они их никак не аутентифицируют (не считая MDC). В следующем раунде кто-то первый должен написать сообщение, выводя из них секрет и аутентифицируя им параметры. Но он не может быть уверен на этом этапе, что получил X от участника, а не кого-то другого (опять же, MDC не берем пока во внимание). Может, есть смысл вновь вводимые ID включать под MAC вместе с текущими уже на этапе (раунде) их введения?

копипастить текст исходников и заливать отдельно рендеринг формул на сайт — тоже достаточно неудобно

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

— unknown (26/08/2014 23:25, исправлен 27/08/2014 00:06)   

Теперь согласен с вами. Всё, что пошифровано, должно быть и аутентифицировано по месту.

А вот в этом я смысла не понимаю. SPRFDID вычисляются из уже аутентифицированных параметров на месте и никуда не отправляются до следующего сеанса.

Предполагаю в следующей версии обозвать их для краткости Sid (Synthetic ID), а полное название SPRFDID оставить только где-нибудь в описании протокола. Пожалуй, есть смысл не запариваться над s и убрать s'. Там логичная и сочетающаяся перестановка параметров для Sid будет. Нельзя, есть золотое правило — для шифрования и аутентификации — разные ключи, пусть даже выведенные из одного общего. За исключением случаев режимов аутентифицированного шифрования за один проход (как в Keccak).

— gegel (27/08/2014 00:00)   

Хуже того, так же как Perfect Forward Secrecy, так и Perfect Forward Deniability ломается для последующих сеансов после одного скомпрометированного.

Это важно для протокола. Не хотел Вас сбивать, но лучше будет смотреть в сравнении, чтобы выдержать хотя-бы качества Axolotl.
Вот мой вариант (выпилил все лишнее, оставил саму суть; также можно считать, что все сообщения завернуты в PKE). Попробую тщательно сравнить с вашим на предмет утечки PFS/PFD при компроментации.

H: Keccak
s_ij – секрет, выведенный с X_i и Y_j

IKE:

A:
генерирует x₀ X ₀
A->B: MDC PKE_B (id_A, X ₀)

B:
генерирует y₀ Y ₀
B->A: MDC PKE_A (Y ₀, H(id_B | s₀₀))

Обмен:

A:
генерирует x₁ X ₁
k_enc = H(s₀₀ | s₁₀)
A->B: SE k_enc (PlaneText), MAC k_enc (CiferText), X ₁

B:
k_dec = H(s₀₀ | s₁₀)
проверяем MAC, дешифруем
генерируем y₁ Y ₁

k_enc = H(s₁₀ | s₁₁)
В->A: SE k_enc (PlaneText), MAC k_enc (CiferText), Y ₁

A:
k_dec = H(s₁₀ | s₁₁)
проверяем MAC, дешифруем
генерируем x₂ X ₂

k_enc = H(s₁₁ | s₂₁)
A->B: SE k_enc (PlaneText), MAC k_enc (CiferText), X ₂

— unknown (27/08/2014 00:07, исправлен 27/08/2014 00:12)   

[граммарнаци]
Plain и Cipher
[/граммарнаци]

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

— Гость (27/08/2014 01:40)   

Лёгки на помине^[link158]. А это^[link159] тогда не вы ли были, случаем? ☺ Прочитал 14.01.02 как 01.04.02^[link160]. Подумал, при чём тут сертификат на семейную практику (там разве что сертификат на отстрел охоту на фриков выдают, как Луговскому в своё время). Интересно, в ныне висящем опросе на главной странице вы к кому^[link161] себя отнесли — технарям или гумманитариям? В любом случае, когда вы сюда заходите, здесь играет ваше второе нутро — электронщика-любителя (или даже электронщика-профессионала — ведь никто не говорил, что у вас нет второго в/о в какой-нибудь иной области).


К своему стыду, должен признаться, что никогда не читал медицинских работ (или глядел настолько быстро и поверхностно, что этот факт в голове не отложился). Мне всегда казалось, что если факты можно достоверно подтвердить и объяснить, то это биология, а если «мы не знаем, но надо же что-то делать!», то это медицина. Последняя была официально отделена от «науки» (естествознания) ещё с античных времён, как и право с музыкой, и эта ситуация сохраняется до сих пор. У них вместо arXiv'а/IACR'а PubMed^[link162], но это ещё пол беды... По ссылке пишут, что у них даже собственные индексаторы! Т.е. Web of science и скопус их типа не касаются(?). Впрочем, в биофизике^[link163] есть подраздел

Медицинская физика (методы диагностики, физиотерапии и патогенез)

И у этой медфизики кафедры по всей стране. Чем они там занимаются — без понятия. Мне всегда казалось, что разрабатывают приборы для медицинской диагностики.


14.01.02 — это не по-гусарски, немножко переборщили, надо было 14.01.01. Впрочем, случаи «у меня ЗПР/ППР, помогите разобраться в себе» — это тоже неплохо. Если ребёнок в 10 лет пишет программы на C — это ППР или норма? Короче, изучайте LaTeX — достаточно взять файл-заготовку из сети и потом редактировать её под себя, есть очень хорошие стилевые файлы. А иначе unknown'у придётся поставить вам страшный диагноз «задержка CS-развития» и прописать гормоны CS-роста. Они опасны и могут привести к непредсказуемым результатам (ссылку на анастезиолога уже привели).


А всё равно некрасиво смотрится. Главное ведь — это форма, а не содержание^[link164]. Внешний эстетизм очень важен, он отражает эстетизм внутренний, содержательный. Без него в криптографии никуда — даже пароли не сможете запомнить^[link165].

п^[link166]ривлекали «магические» математические значки, которые «что-то значат», которыми можно «магически» предсказать результат измерения, не осуществляя эксперимент

Рисование и черчение значков надо любить.

В вики LaTeX-разметка тоже часто ужасно выглядит, хотя на некоторых сайтах (и даже страницах вики) находят способы сделать всё хорошим. Шрифты крупные, например, формулы поэтому на фоне основного текста смотрятся вычурно, как с другой планеты. Сразу скажу, что шрифт для формул в LeTeX'е связан со шрифтом основного текста, чтобы всё смотрелось органично (можно переопределить руками, но так обычно не делают). Т.е. если я в преамбуле сказал \usepackage{palatino} или \usepackage{times}, мне это поменяет и шрифт текста, и шрифт формул, чтобы всё было консистентно. Размер шрифтов текста и формул тоже, конечно, связан. Если по-хорошему, то LaTeX должен быть не в довесок к движку, а вместо него, т.е. и текст комментариев, и текст самих страниц wiki должен форматироваться LeTeX'ом. Понятно, что это слишком, SATtva упадёт в обморок от таких запросов на это не пойдёт. ☺


Вопрос, что делать с формулами и LaTeX'ом тут обсуждается уже 7 лет [1]^[link167], [2]^[link168]. ☺


Речь поди о флудере из этого поста? Я уже привык обходиться html- и wiki-разметкой. В сорсе выглядит коряво, но на печати получается намного лучше, чем присобаченный непонятно с какого боку (см. выше) LaTeX. Однако, другое дело, что тут разметка неполная — иногда надо лишние пробелы доставлять, нельзя поставить индекс один под другим и т.д. Всё это в новом движке можно было бы пофиксить. Ну, и, чтоб совсем трудно набирать не было, лучше имплементировать сабсет возожностей LeTeX'а в движке, совместимый с ним по синтаксису. Прежде всего, нужна умная экранировка^[link169], потому что (в CS это меньше, но, в принципе, тоже так) шрифт букв в формулах по умолчанию — курсив, а шрифт букв в основном тексте — по умолчанию прямой.


А меня в 5 лет на балет водили. Руководитель не смог замотивировать, поэтому быстро расхотелось и бросил (не без крови, синяков и скандалов, конечно, т.к. родители были против). Почему это было бы круто, понял лет 10 спустя, да поздно уже было.

— Гость (27/08/2014 01:52)   

Лучше пишите так: A&rarr;B, или так: A &rarr; B. На печати будет: A→B или A → B.


i и j — переменные, а все переменные по конвенции пишутся курсивом, поэтому, если опускаться до буквоедства, то должно быть s_ij. Разметка:

— Гость (27/08/2014 01:56)   

Блин. Вообще, в LaTeX есть 3 стандартных шрифта: прямой, наклонный (\textsl{}) и курсив (\textit{}), т.е. италик/oblique. На pgpru.com курсива нет, но есть наклонный шрифт, поэтому местами получается чушь, но вы, думаю, поняли, к чему я (используем наклонный вместо курсива за неимением лучшего).

— unknown (27/08/2014 09:39, исправлен 27/08/2014 10:45)   

[искромётная ирония и тонкий юмор]
Идея с веб-эмулятором Linux сразу понравилась: так начинающим было бы гораздо легче освоить. Не знаю, на сколько это реально (не специалист в web), но если реально раздать всем шелл-доступ к серверу (лучше сразу рутовый) в javascript-эмуляторе терминала прямо в браузере, то оно того стоит.
[/искромётная ирония и тонкий юмор]

Сегодня (и уже давно вчера) все хотят LaTeX-движок, завтра заходят диаграммы, блок-схемы, графики и пр. Чтобы обойтись малой кровью предлагается пока рендерить это самостоятельно в PNG или SVG, а на сайт вместе с картинкой заливать исходник, только чтобы в будущем его можно было компактно убрать под кат, чтобы глаза не мозолил. Внёс такое пожелание^[link171].

— unknown (27/08/2014 12:20)   
V.0.02^[link156], перезагружайте картинки, если они у вас в браузере кэшируются.

— Гость (27/08/2014 16:39)   

Вы не поверите, но латеховские пакеты позволяют делать всё вами перечисленное. Блок-схемы и картинки — откройте для себя tikz. Графики — забыл название, но тоже есть пакет, который можно подключить, ты ему набор точек (x,y), он тебе — график. Я обычно использую overpic — это позволяет нарисовать поверх графика всё, что угодно, как в тексте (формулы, стрелки, линии, пометки).

— unknown (27/08/2014 16:48, исправлен 27/08/2014 21:24)   

Я знаю, но не стоит это всё прикручивать к движку. Веб-версия SAGE тоже существует.

V.0.021^[link156]. Убрал KDF после MAC в выводе Sid.
V.0.022^[link156]. В нулевом раунде каждый Sid считается через R_a и R_b, также как и в последующих

— gegel (27/08/2014 21:32, исправлен 27/08/2014 21:35)   

надо было 14.01.01

все из-за близорукости: нос был постоянно мокрый

А это тогда не вы ли были, случаем?

Прикольно: оказывается, я тут не одинок. Действительно, ЭхоКС также входила в инструментальные методы исследования в моей старой работе, и трактовать показатели КДО и КСО, конечно, могу. Но и отвязанный от TBB Tor тоже, вроде, настроить могу (судя по отывам педофилов, успешно пользующих Торфон).

V.0.022

Красиво: под МАС-ами вроде все параметры неповторяемо переставляются как для аутентификатора сообщения, так и для SID-ов.
Я не смог интуитивно на вскидку уловить, какие параметры стороны хранят между раундами и в течение раунда между запросом и ответом. От этого зависят последствия одномоментного компроментирования.
В моем варианте старые и новые DH-параметры (приватные ключи) одновременно существуют лишь в момент выведения ключей зашифровки и расшифровки (нужны и старые, и новые, чтобы вывести ключи раунда), поэтому последствия одномоментной утечки данных с диска сведены к минимуму.

— unknown (27/08/2014 21:37, исправлен 27/08/2014 21:58)   

Вопрос: можно ли вообще выкинуть R_A и R_B? Раз уж под SE вместе с Message передаётся X_i+1 и Y_i+1, то он и сам по себе играет роль такого R. В ранней версии дискуссии похожие R я уже выкидывал. Тогда сообщения с предыдущих раундов можно безопасно сохранять и безо всяких манипуляций с R. По ним всё равно нельзя будет восстановить аутентификацию, т.к. X и Y меняются от раунда к раунду.

Ответ: нельзя. R_A и R_B нужно сохранять в пределах текущего раунда, а для следующего надо хранить: X_i+1 и Y_i+1, Sid_Ai+1, Sid_Bi+1. Так что сохранённые сообщения уже безопасно хранить по завершении текущего i-ого раунда, а если бы не было R, то безопасность хранения возникала бы только при завершении i+1 раунда.

— gegel (27/08/2014 22:02, исправлен 27/08/2014 22:11)   

Именно. Вот поэтому я и поднял вопрос о данных, хранимых между сеансами. В моем варианте просто данных меньше (в ущерб стойкости?), поэтому легче оценить.
Еще надо бы просмотреть не только в плане отрицаемости, но и в плане возможности получения предыдущего ключа и расшифровки дампа (как на стороне отправителя, так и получателя; пока без навешенного костыля в виде KDF).

— unknown (27/08/2014 22:37)   
В текущей версии "Flat Spheroid" нельзя расшифровать Message c предыдущего раунда, при условии, что долговременный закрытый асимметричный ключ утёк и всё под PKE расшифровывается.

Во первых, стираются X_i-1 и Y_i-1, в текущем раунде есть только X_i и Y_i, выведенные в т.ч. и с их помощью. Из под текущих Sid предыдущие параметры тоже нельзя узнать. Наконец, секретные DH-параметры a_i-1 и b_i-1 с предыдущего раунда тоже стёрты. Т.е. s_i-1 и s'_i-1 выводить после завершения того раунда уже не из чего.

Единственно, что незавершённый раунд даёт окно безопасности на два сообщения. М.б., если приделать к этому две пары DH с каждой стороны и ratcheting, как в Axolotl, то что-нибудь и получится. Но пока, можно остановиться на этом варианте и считать раунд с безопасным окном в два сообщения — приемлемым. Хотя это не снимает проблему подтверждения аутентификации при захвате параметров, как внутри раунда, так и при последующем раунде при поступлении новых сообщений с другой стороны.

— gegel (27/08/2014 22:39, исправлен 27/08/2014 22:43)   

Хм, у Вас в этом плане ситауция даже лучше, чем у Axolotl: инициатор хранит раундовый приватный ключ с момента отправки запроса до момента получения ответа, а ответчик вообще не хранит. Доверие передается через отрицаемые Sid-ы, защищенные R.
Только вот асимметрично получается, как-то не изящно смотрится. Может, потом будет смысл подумать на счет спаривания типа 01, 12, 23...
И еще: я уже задавал этот вопрос, но так до конца и не понял мотивацию: какой смысл прятать вводимый X_n под MDC SE? Ведь это публичный параметр, может быть передан и открыто. А MDC лишний раз связывает его с Message. Хотя, конечно, в вашем варианте с перманентной PKE-оберткой это же все равно делает MDC PKE.

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

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

— unknown (27/08/2014 23:03)   
Можно сократить Sid'ы: пусть сторона B считает Sid также как и отправляемый в сообщении MAC (только со своим R_B и Y_i+1), но без Message, аналогично и для стороны A: с обычными параметрами, затем с R_A и X_i+1, но без параметров ответной стороны. Тогда отправитель может посчитать Sid сразу после отправки и удалить R, получатель — сразу после получения и тоже сразу же удалить R. Вот только сходу не пойму, хорошо ли иметь такой половинчатый Sid, в который включены не все параметры второй стороны, которые передаются в раунде.

Другой вариант: раз инициатор менее защищён — он считает половинчатый Sid, а отправитель может посчитать и полный. Поскольку в аутентификации следующего раунда будут использованы оба Sid'a, то это даст отрицаемое связывание по параметрам ообеих сторон предыдущего сеанса.

— gegel (27/08/2014 23:31)   

но без параметров ответной стороны.

Поскольку в аутентификации следующего раунда будут использованы оба Sid'a

Я вообще не пойму, зачем в Sid включать параметры ответной стороны – это ведь мой Sid. Хотя, действительно, с ходу оценить последствия такого решения трудно.

Другой вариант: раз инициатор менее защищён — он считает половинчатый Sid, а отправитель может посчитать и полный.

Брр, жуткая асимметрия... У Эркюля Пуарро усы бы бубликом от такого подхода свернулись.

— unknown (27/08/2014 23:59)   
Может обеим сторонам вообще считать половинчатый Sid, главное что он заверен посредством текущего s'. Тогда можно не дожидаться ответной половины DH для своего Sid и сразу отбрасывать R, вычисляя Sid в момент отправки-получения. Тогда получатель может сразу отрицать аутентификацию сохранённого сообщения в одном шаге уже внутри раунда: проверил аутентификацию по MAC, посчитал похожий MAC без Message для Sid, сохранил что есть из половинок DH, а полученный R — сразу стёр. Так что, при захвате текущих параметров, Message уже нельзя будет аутентифицировать даже внутри раунда после того как это первым сделал пользователь. И отрицание аутентификации симметричное для каждой стороны внутри раунда, и формулы проще, и опять симметрия не нарушается.

А для передачи отрицаемой аутентификации на следующий раунд достаточно двух половинчатых, но взаимодополняющих Sid.

— gegel (28/08/2014 00:13)   
Да, по идее смотрится привлекательно, но надо подумать, как бы чего по ходу не опустили. Похоже, мы уверенно двигаемся в сторону того же минимализма.

— unknown (28/08/2014 09:41, исправлен 28/08/2014 09:42)   

Более того, в текущем ненулевом раунде не надо закатывать под MAC текущие X и Y — они уже содержатся в Sid. А текущие s и s' уже выведены на предыдущем раунде.

Предполагается много чего ещё поменять, пока даже не собрался с мыслями, чего написать в TODO. И это только очередной этап. В дальнейшем можно будет и подумать над раздельными s_A→B, s_B→A, s'_A→B и s'_B→A через KDF или даже с дополнительной DH-парой.

К вопросу о том, почему открытые параметры DH передаются под SE. Допустим, противник когда-нибудь построит квантовый компьютер и будет ломать DH и PKE. Тогда он всё равно не сможет взломать записанную переписку если у него не записаны сообщения нулевого раунда.

— gegel (28/08/2014 10:32)   
Может, тогда хоть включать X и Message под разные SE? Так смотрится лучше в плане отрицаемости: все же MDC как-то их связывает. Это перестраховка, конечно, но не больше, чем квантовый компьютер.

— unknown (28/08/2014 11:13, исправлен 28/08/2014 11:53)   

Никак не связывает, если противнику неизвестен совместно выведенный ключ s.

С учётом текущих упрощений V.0.023^[link156].

— gegel (28/08/2014 19:19, исправлен 28/08/2014 19:21)   

V.

0.023.

Все таки решили оставить в выведении Sid параметры противоположной стороны от предыдущего раунда (Id / Sid _i-1 и X_i-1) ?

Никак не связывает, если противнику неизвестен совместно выведенный ключ s.

Убедили. Случай единичного брутфорса пока не принимаем во внимание.

— unknown (28/08/2014 20:57)   

С нулевым раундом — точно да, иначе как протянуть доверие от первой аутентификации?

А вот в последующих — есть смысл подумать, может оставить только

Sid_Bi+1 = MAC_s'i (R_B, Y_i+1);
Sid_Ai+1 = MAC_s'i (R_A, X_i+1).

Судя по приведённой вами работе итальянцев, такие протоколы создавать-то несложно: они все дают слабую наперёд заданную отрицаемость. Они беззащитны в сценарии, если Боб отрицает переписку с Алисой, но Алиса является злонамеренной и сохраняет все s и прочие параметры, чтобы затем передать их стороне, которая знает параметры Боба, чтобы та убедилась, что Message, полученные Бобом, действительно исходили от Алисы. Более того, сторона, перехватывающая письма Боба, но захватившая его закрытый ключ, сможет расшифровать и прочесть все сообщения, которые он у себя удалил после расшифровки, если Алиса злонамеренно сохраняла все параметры сеансов, чтобы подставить Боба.

— gegel (29/08/2014 00:52, исправлен 29/08/2014 01:10)   

У них весьма строгая модель, требующая дополнительного шага в протоколе (коммитмента). Я разбирал их DDH-вариант, стр.29 (хотя остальные тоже интересны), примеряя к нашей задаче. На С я это закодирую, но скриптом – вряд-ли (там нужна элементарная математика над группой, я сам добавлял нужные функции в ядро библиотеки подписи DH25519, немного разобравшись с уже имеющимися функциями).
Еще есть однопроходные отрицаемые аутентификаторы (например, NIDA^[link99] на основе сочетания подписи Шнорра и шифрования Эль-Гамаля, ссылку на который я уже приводил когда-то), позволяющие одновременно отрицаемо аутентифицировать и отправителя, и само сообщение (в нашем случае – вводимый ключ), но у них проблемы с безопасностью, и это уж совсем модерн.

PS: вот, кстати, еще одно простое китайское решение с обычной DH.^[link172]

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

Понятно, что в такой ситауции Алиса сможет показать третьей стороне, что она может создать сообщение, которое можно расшифровать имеющимися у Боба ключами (т.е. что она с ним в контакте). Но вот сможет ли она связать предыдущие сообщения с тем, что изъято у Боба (его секретным PGP-ключом и хранимыми параметры текущего сеанса)? Наверное, нет: Алиса не может убедить третью сторону, что отсылала первый запрос Бобу, а не себе самой, и что получила ответ именно от него. Завтра еще подумаю на свежую голову: ваша перманентная обертка может вызывать непредсказуемые эффекты.

— unknown (29/08/2014 21:31, исправлен 29/08/2014 21:47)   

А наверное, да. Алиса скажет: вот такого-то числа на его PKE_B был отправлен такой-то шифртекст под SE_s. Алиса даёт s для этого письма и указывает, какой из этого шифртекста должен извлечься R_A, X и Message. Алиса может просто запоминать все s и предъявить их, а захватившая Боба сторона подберёт, чтобы хоть какое-то из них совпало с каким-то перехваченным сообщением и давало осмысленный Message при расшифровке, что уже будет достаточно.

Если сильный противник узнал весь ключевой материал Боба и получил сохранённые параметры сеанса от Алисы, то наверняка он перехватывал и то, что Боб отправлял Алисе под PKE_A. Если Алиса сдаст ради компрометации Боба и свой закрытый ключ, то противник может расшифровать то, что Боб отправлял ей, и неважно, общий у них был s в раунде или раздельный: Алиса сдаёт все s и секретные параметры DH всех раундов, противник убеждается, что они подходят и расшифровывает открытый текст Message, отправляемых Бобом для Алисы.

Так-что итальянцы, скорее всего, правы: стойкой отрицаемой аутентификации не существует, если есть сильный противник и злонамеренный второй участник протокола. Все протоколы, которые мы можем обсудить — дают лишь слабую отрицаемость. Поэтому я изначально и не хотел вообще сильно с ней заморачиваться. А то, что хотите вы, получилось ненамного лучше того же Axolotl, SKEME и пр. В моём варианте (и других аналогичных) вообще не важно, что вносить под MAC для выработки id следующего сеанса: хоть все параметры проведённого раунда (это лишь заверит правильность его проведения для участников), хоть вообще пустую строку (константу). MAC_s' для вывода Sid заверяет лишь факт знания секретного ключа предыдущего сеанса s', который не передавался в открытую, а выводился из DH-обмена. С таким же успехом вместо такого Sid могли бы использоваться и половинки хэша от s для предъявления в следующем раунде, как вы приводили в примерах и др.

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

— gegel (29/08/2014 22:42, исправлен 29/08/2014 22:59)   

Если сильный противник узнал весь ключевой материал Боба и получил сохранённые параметры сеанса от Алисы, то наверняка он перехватывал и то, что Боб отправлял Алисе под PKE

К слову: из работы Крачика^[link138] (стр. 4, 3-й абзац):

Thus, the most important component for the deniability of electronic communications is the deniability of KE protocols. If the parties can deny having exchanged a key with the other party, then the rest of the communication can also be denied.

И тут же сноска:

Needless to say, we limit ourselves to avoiding “algorithmic” proofs of communication, and ignore other means that courts, or other entities, may accept as evidence such as physical tapping (or just the word of a gentleman...).

Так что с Вами нельзя не согласиться. Как я уже говорил, отрицаемость в таком рафинированном виде может быть интересна нам с Вами, но никак не той аудитории, которой она действительно нужна. Наверное, PFS и надежность аутентификации куда важнее, и лучше концентрироваться именно на ней. Например, критика OTR^[link79] за публикацию использованных MAC-ключей (концепция: "после проверки MAС получателем любой, знающий содержание сообщения, может его изменить (CTR-mode) и снова аутентифицировать"). Звучит интересно, но на практике еще никому не понадобилось.

PS: если Вас не затруднит, ткните меня в какую-нибудь подходящую LaTeX-заготовку, на досуге перепишу доку на OnionPhone к альфа-релизу.

По ходу реализовал еще одну идею в коде OnionPhone: возможность проброса выбранного UDP-порта через TCP-Tor. Попробовал с VLC-потоковой трансляцией: даже сносную картинку (на низком фрейм-рейте с H264) удалось получить.

— unknown (29/08/2014 23:55, исправлен 30/08/2014 00:06)   

Идёте на http://arxiv.org, смотрите работы. Например эту^[link173]. Справа там предлагается скачать в PDF, Postscript и Other formats^[link174]. Дополнительные форматы есть не у всех работ. Но если они есть, то среди них для многих работ есть и формат Source. В Source может быть tar.gz со всеми картинками, вставленными отдельными файлами и LaTeX (типа такого^[link175]), может быть простой LaTeX или сжатый tex.gz.

— Гость (30/08/2014 05:03)   

Хреновое заводское оформление. Вот тут^[link176] хоть что-то для приличия подкрутили. Попадались работы ещё лучше оформленные, но лень искать.

— unknown (31/08/2014 22:13, исправлен 31/08/2014 22:20)   

Поменял до v.0.024^[link156].

От R избавился, они были нужны для улучшения отрицаемости внутри раунда. Теперь отрицаемость и PFS внутри раунда достигается без R и при этом эффективнее.

При помощи KDF из текущего DH-секрета раунда для следующего раунда вычисляются два Sid, как и раньше. А вот симметричных ключей вычисляется четыре: одна пара — для шифрования и аутентификации в одну сторону, другая — соответственно в другую.

Теперь сторона B может отправить сообщение стороне A, вычислить Sid для следующего раунда и сразу же стереть свой симметричный ключ, получив отрицаемость (в принятом нами ограниченном понятии этого свойства) и PFS уже внутри раунда. Получатель A также может после расшифровки и проверки сообщения вычислить аналогичный Sid и сразу же удалять этот симметричный ключ текущего раунда.

— gegel (01/09/2014 11:10, исправлен 01/09/2014 11:17)   

Поменял до v.0.024

Все выглядит идеально. Но сегодня утром я неожиданно увидел то же под другим углом. Наверное, это Вам не совсем понравится, но и тем не менее выскажу свои соображения хотя-бы в качестве альтернативы для сравнения.
Дело в том, что Вы рассматриваете каждый раунд как независимое ключевое согласование, аутентифицированное с помощью имеющихся от предыдущего раунда Sid-ов. Я представил то же иначе.
Допустим, после раунда n (в частном случае n=0) стороны выводят доверяемый общий секрет s. Это эквивалентно наличию у них пред-расшаренного секрета. В раунде n+1 стороны обмениваются сообщениями под симметричным шифрованием с MDC, используя имеющийся пред-расшаренный секрет. При этом аутентификация данных как бы и не нужна (эту функцию выполняет MDC). Вводимые ключи являются частью сообщений, и стороны им доверяют, как и остальному содержимому. Таким образом, из них можно сразу выводить секрет для следующего раунда, без никакого дополнительного подписывания параметров DH.
В итоге протокол редуцируется до смешного минимума:

Раунд 0 (IKE):

A→B: MDC PKE_B (Id _A, X ₀)

B→A: MDC PKE_A (Y ₀, HMACs₀ (Id _B) )

Раунд n:

A→B: MDC SEs_n-1 (Message, X_n)

B→A: MDC SEs'_n-1 (Message, Y_n)

Конечно, я мог на вскидку опустить что-то важное, но под описанным выше углом зрения вроде выглядит приемлемо.

— unknown (01/09/2014 11:51, исправлен 01/09/2014 12:28)   

Я тоже об этом думал. Но делал протокол уже так, как будто MDC ненадёжен, может быть взломан и его просто нет. Т.е. MDC — это просто довесок, перестраховка, которая раз есть в OpenPGP, то почему бы ей не воспользоваться. Сомнения по поводу MDC уже были ранее в теме, потому как это шифрпанковское внутреннее специфичное изобретение OpenPGP RFC4880^[link177] теоретически нигде не описанное и формально недоказанное. В самом RFC он описывается как готовое решение для отрицаемости и отказа от подписей, можете почитать.

Но если попытка создать очередной протокол, наподобие "Flat Spheroid" будет когда-то формализована, то его стойкость можно будет рассмотреть без MDC и провести сравнительный анализ с другими протоколами. Ваши идеи по заземлению протокола мне нравились и существенно повлияли на его текущую версию.

Более того, может быть подумаю о том, чтобы описать его в двух вариантах: полном, не опирающемся на стойкость MDC; и вашем сокращённом, основанном на том, что MDC — стойкая конструкция, которая когда-нибудь может быть формализована и признана академическим сообществом.

P.S.: Flat Spheroid v.0.025^[link156] в двух вариантах, готово.

— unknown (03/09/2014 17:41)   
Подумалось, а зачем в сокращённой версии протокола вообще HMAC, даже в нулевом раунде, если везде полагаемся на MDC и специфические свойства HMAC вроде как не нужны?

Может там сделать:

B → A: MDC PKE_B (Y₀, MDC SE_B→A (Id_B, Y₁))

— gegel (03/09/2014 20:06)   
Да, действительно. Я сразу и не заметил такую возможность. Т.о. для реализации скриптом нужны только pow и KDF.
Еще вопрос: в раунде n обе стороны вводят ключи n+1 и соответственно выводят секреты n+1 (все симметрично). Но в раунде 0 только одна сторона вводит ключ 1. Таким образом, не совсем понятно происхождение секретов s₁.
Может, попробовать перейти на "последовательное спаривание" (0-1, 1-2, 2-3) ключей в стиле OTR?

— unknown (03/09/2014 21:26)   

Подправил этот вариант.

Помимо очень простой практичной реализации, это интересно с т.з. дальнейшего изучения MDC в плане его сводимости к т.н. non-malleability^[link178]. Судя по описанию и полному отсутствию теоретических работ, MDC в GnuPG — это самопальный (в плане того, что разработчики GnuPG его взяли не из публикаций) non-malleable encryption mode. Возможно, что он даже стойкий, но имеет какие-то ограничения в плане своей полноценности. Помимо привязки к GnuPG есть смысл держать на рассмотрении такой вариант в случае замены MDC на более проверенный non-malleable mode.


Я как-то традиционно привык обозначать раунды через i от слова итерация, а не n — number. Это непринципиально, естественно. Но как-то чаще попадается, вот даже в Стрибог^[link179].

А по сути, верно замечено. Подразумевается, что в нулевом раунде стороны согласуют первый секрет и тут же одна сторона уже может его использовать. Но при этом получается, что в первом раунде (после нулевого) используется этот же совместно выведенный секрет и т.о. получается равентство ключей s₀ = s₁. Как бы, некритично, но лучше исправить. Дальше все раунды идут стандартно, последующие симметричные ключи выводятся один раз из общего секрета предыдущего раунда.

Частично исправил это недоразумение указанием номера раунда i в KDF. Так что, DH между нулевым и первым раундом остаётся общим, а s — гарантированно разные.


Если «последовательные спариватели» не удосужились разместить на своей wiki-странице вменяемые формулы к формальному описанию протокола, то придёться когда-то добраться до их протокола и сделать это за них. Хотя бы для себя. Иначе, не видя перед глазами чётко формализованной картины, не понять преимущества, недостатки и пути развития того или иного решения.

Вообще, времена, когда протоколы придумываются в почтовых рассылках — ужас. Это же не патч к коду, который не требует ничего специфического, читается и без подсветки. Можно кончено и LaTeX-подстрочник текстом постить, но это неудобно. В итоге, в рассылках посылают урезанные до простого текста формулы и их же потом вешают на сайт того же Axolotl. Была бы хоть pdf, как для OTR.

Текущая версия v.0.026^[link156].

— gegel (03/09/2014 22:20, исправлен 03/09/2014 22:31)   

вменяемые формулы к формальному описанию протокола

Кстати, я именно с описания OTR-протокола^[link23] брал пример. Наверное, не лучший подход оказался. Более приемлемо раунды описаны в их первой работе^[link27], стр.4.
Уязвимость этой версии касалась IKE и была исправлена позже, принцип "спаривания" остался тот же.

это самопальный ... non-malleable encryption mode.

Да, я просмотрел RFC по Вашей ссылке. Используется CFB с добавленным (обязательно в конце) хешем от предыдущего открытого текста. Как-то пытася читать Rogaway по поводу его OCB, так он критикует подобные решения.

— unknown (04/09/2014 17:26, исправлен 04/09/2014 17:37)   

Протокол радикально переработан до v.0.03^[link156]. Скорее всего, не в последний раз.

1. Идея со счётчиком раундов — неудачная. Если, например, от Алисы перехвачено i сообщений на какой-то адрес и при захвате её счётчик будет равен i, то это её лишний раз демаскирует. Лучше не хранить в параметрах количество проведённых раундов.
2. В нулевом раунде нужно ответить под MAC какой id отвечает какому id и параметрами первого раунда X₁ и Y₁, чтобы избежать UKS-атаки. Вопрос, насколько надёжен такой ответ под SE MDC, остаётся открытым.
3. Поскольку попарное зацепление выводимых через DH-ключей (key ratcheting как в OTR или Axolotl), не используется, то после нулевого раунда никакие synthetic id не нужны. Сами производные ключи s выполняют функцию id.
4. Key ratchting отвергнут намеренно. При совместном выведении ключа по Диффи-Хеллману обе DH-половинки (как секретную, так и открытую) нужно использовать один раз, после чего отбросить. При попарном же зацеплении одна и та же DH-половинка образует пару выведения секрета сначала с одной, задем с другой половинкой. Может быть это даже где-то широко используется на практике (в VPN, SSL), но я не видел теоретического обоснования такого использования. Неизвестно, точно ли так можно делать, по крайней мере это отход от классического представления DH-протокола. Даже если это в общем безопасно, ещё неизвестно, насколько это безопасно в каких-то частных протоколах и при замене стандартного DH, например, на эллиптику. Особенно, когда вторая не вполне доверяемая сторона может посылать некоторое подобранное значение новой DH-половины к уже ранее использованной DH-половине, т.к. точно знает, когда такая половина повторяется для выведения нового секрета.

— gegel (04/09/2014 21:18, исправлен 04/09/2014 21:52)   

Идея со счётчиком раундов — неудачная.

Только хотел об этом написать, думал, как корректнее это сделать. Естественно, при захвате компьютера будет сразу видно объем предыдущей переписки. В то же время острой необходимости в счетчике вроде и нет, т.к. replay-атака исключается, ведь обе стороны участвуют в выведении секрета.

какой id отвечает какому id и параметрами первого раунда X1 и Y1, чтобы избежать UKS-атаки.

В идеале – да. Но я очень долго по всякому крутил IKE сокращенного варианта протокола на предмет UKS:

A→B: MDC_PKE_B (id_A, X ₀, X ₁)
B→A: MDC_PKE_B ( Y ₀, MDC_SEs₀ (id _B, X ₁, Y ₁) )

Я понимаю, что это не академично (по уму доказывают стойкость, а не пытаются найти атаку). Но потом я тщательно просмотрел Abadi^[link180], слайд 4: в ответ под MAC включается только свой Id. Как я и предполагал, этого достаточно для блокирования UKS. И, кстати, может, есть смысл заменить в ответе под MDC X ₁ хешем (с целью экономии места)?

Особенно, когда вторая не вполне доверяемая сторона может посылать некоторое подобранное значение новой DH-половины к уже ранее использованной DH-половине

Согласен, это напоминает проблему полустатической DH. Причем в каких-то описаниях протоколов даже встречалась оценка уменьшения стойкости при многократном выполнении. Новизна Вашего варианта неоспорима, да. Интересно, почему в свое время OTR так не сделали, ведь пораундово по идее проще как в понимании, так и в реализации.

---

PS: чем дольше смотрю на вышеприведенный IKE, тем больше не нравится идея вводить X ₁ и Y ₁ в нулевом раунде. Получается, секрет s₀ используется исключительно для MDC_SE ответа. Это для лучшей отрицаемости? Может, вернуть так, как было в предыдущих версиях: из него же вывести и рабочие ключи для следующего раунда? Дело в том, что с этим X ₁ – сплошной геморрой: его обязательно надо возвращать инициатору (под MDC (в виде хеша) или под MAC), иначе можно замонтировать UKS. А аргументов в пользу выведения s₁ уже в нулевом раунде вроде как пока и нет.

— unknown (04/09/2014 22:41)   

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


Очевидно, да, можно хоть оба id с ним вместе похэшировать, если бороться за экономию места. В расширенном варианте протокола, когда ответ даётся под MAC, такой проблемы не возникает, поэтому машинально и перенёс в MDC SE, не подумав.


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


Под MAC проблемы места нет, сколько бы параметров туда не пихали, поэтому в первых версиях протокола я вообще не экономил.


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

— gegel (05/09/2014 01:03, исправлен 05/09/2014 01:03)   

Пусть нулевой и первый раунды будут максимально разделены. Так выглядит логичнее и аккуратнее.

Да, это разумно. С точки зрения той же отрицаемости лучше использовать полученный в IKE секрет только для подписывания параметров, но не в качестве рабочего ключа.

Но хочу обратить Ваше внимание на один нюанс: по сути, у нас нулевой раунд не завершает IKE. После него Алиса (инициатор) уверена в идентичности Боба (она получила подписанные параметры). Но Боб уверен в идентичности Алисы, только когда получает от нее первое сообщение (т.е. уже в первом раунде). После нулевого раунда, даже имея s₁, Боб не должен писать первым.
Я не могу на вскидку оценить последствия, просто констатирую факт.

— unknown (05/09/2014 21:34)   

Здесь никаких последствий, изначально задумывалось строгое пошаговое чередование. В плане особенностей реализации, Боб может ставить на согласованный на нулевом раунде ключ некий блокирующий флаг "unverified", а затем удалять этот флаг с ключа после прихода корректного ответа Алисы на первом раунде.

Другое дело, что в обобщённом описании протокола вообще не предусмотрена система отправки сообщений в нарушение очереди или нескольких сообщений от одной стороны без получения завершающего ответа от другой, контроль рассогласований и пр. Вроде это и так логично, без строго очерёдных попарных ответов не завершить пересогласование для следующего раунда. Но если очень хочется, то в некоторых случаях можно делать то, что предлагают авторы Axolotl — окно безопасности на цепочке производных ключей s, вырабатываемых через KDF от текущего ключа раунда.

Хэш добавил^[link156].

— gegel (05/09/2014 22:54, исправлен 05/09/2014 22:58)   

Но если очень хочется, то в некоторых случаях можно делать то, что предлагают авторы Axolotl

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

Боб может ставить на согласованный на нулевом раунде ключ некий блокирующий флаг "unverified"

Собственно, Боб может и первым отсылать сообщение, если используется перманентная PGP-обертка. Но оно будет подвержено сильной wPFS-атаке (с активным атакующим). Допустим, Ева инициирует беседу с Бобом от имени Алисы. Боб выполняет раунд 0, отсылая Алисе ответ, а затем сразу же отсылает ей сообщение. Ни Алиса, ни Ева не могут согласовать секрет с Бобом и прочитать сообщение, сеанс завершается. Но позже Ева, завладев PGP-ключом Алисы, выводит секрет и читает сообщение Боба.

в ответ под MAC включается только свой Id

Вот у меня ни доказательств, ни даже интуитивной уверенности в этом нет.

Я попытался взглянуть на это под другим углом:
B→A: MDC_PKE_A (Y ₀, HMACs₀ (Id _B))
уже инкапсулирует в себе Id _A в неявном виде в PKE (даже глядя на формулу). Я не встречал описания протоколов с DH под PKE, сравнить не с чем. А без PKE, конечно, оба Id должны быть под MAC (например, тот же SKEME). Это, наверное, слишком смелая идея, и обоснованная не более чем интуитивно, но если удастся это как-то доказать, то отрицаемость только выиграет.

— Гость (08/09/2014 02:44)   

Как вы собираетесь доказывать? Написать статью, потом положить её в IACR/arXiv, сабмитнуть в J. of Crypt. или FOCS/STOC, провести через процедуру рецензирования независимыми оппонентами, и в итоге получить публикацию в реферируемом научном издании, индексируемом такими базами как Web of Science и/или scoups? Если что, это тот минимум, после которого хоть кто-то будет говорить, что «доказательство безопасности протокола в рамках таких-то допущений было дано». Т.е. это будет состоявшийся факт, на который смогут ссылаться люди, причём нахождение ошибок в вашей работе можно будет оформить как другую работу, и точно так же провести её через архив и журналы/конференции. Это даёт повод вашим потенциальным критикам внимательно читать вашу работу. Т.е. на нахождении в ней ошибок можно срубить новую публикацию.

Всё остальное — это как надписи на заборах, «кто-то написал». Кстати, описанный процесс вообще не дружит с анонимностью. Т.е., совсем никак.

— Гость (08/09/2014 09:16)   

Pond больше для почты, чем для IM, как я понял (для часто отправляемых сообщений не подходит), но всё же интересный проект, недавно его обсуждали^[link182]. Он уже может претендовать на заменителя TorChat или нет? Судя по словам про случайно выбираемое время для контакта с серверами — нет. К тому же, идея использования серверов, когда оба юзера в онлайне, мне не очень нравится. Т.е. для доверенных контактов лучше прямое соединение, а для недоверенных — через сервер.

— gegel (08/09/2014 10:02, исправлен 08/09/2014 10:26)   

Как вы собираетесь доказывать?

Я усвоил то, о чем вы писали, еще с предыдущего, почти дословного, вашего поста по поводу публикаций в CS. Поэтому я ничего доказывать и не собираюсь, Вы неверно поняли. Я понимаю, что выполнить полноценное академическое доказательство практически нереально в моем случае.

Pond

Я когда-то очень бегло просмотрел этот проект, поэтому не могу ничего сказать об используемом транспорте. Но, как Вы сами указали, это почтовое решение, предполагающее, что получатель не все время онлайн. Поэтому сравнивать Pond и TorChat, наверное, не совсем корректно.TorChat прекрасно справляется со своей задачей анонимного мессенжера, его нет смысла на что-то менять (разве что добавить независимый слой шифрования/аутентификации плюс всякие довески типа проброса портов и т.п.).
Что же касается почты, то без онлайн-сервера тут не обойтись. Но, во первых, этот сервер должен быть на HS, а во вторых – лишь хранить и пересылать рандомно выглядящие данные указанному onion-адресату по его запросу, не требуя регистрации и аутентификации ни отправителя (при отправке почты на сервер), ни получателя (при запросе получателя на пересылку ему его почты). Естественно, почтовые клиенты должны обеспечивать оконечное PFS-шифрование и отрицаемую аутентификацию, например, используя протокол Axolotl.
Сразу как доделаю OnionPhone, по быстрому нацарапаю тестовый прототип такого сервера и клиента на С, алгоритмической сложности там абсолютно никакой нет.

Цитата от Гость (13/06/2013 23:37^[link183]) из темы Pong:

Как известно, посылка в оффлайн без доверия третьей стороне невозможна

Не могу согласиться. Оффлайн ничем не отличается от онлайн, кроме времени доставки. В любом случае ваш пакет проходит через множество узлов и так или иначе содержит адрес получателя.
Другое дело, что выходной узел может периодически проверять надичие получателя онлайн, а может дождаться от него сигнала (анонимно через Tor, с указанием своего онион-адреса). Если на сервере имеются письма для данного онион-адреса, сервер сам подключается к получателю и отсылает ему его письма. Таким образом, сервер может собирать информацию, сколько писем он переслал определенному псевдониму, но не знает, от кого. Кроме того, стороны могут периодически согласованно менять псевдонимы (онион-адреса), оставляя за собой ранее согласованное оконечное шифрование/аутентификацию.

— gegel (08/09/2014 18:47, исправлен 08/09/2014 18:49)   

> чем дольше смотрю на вышеприведенный IKE, тем больше не нравится идея вводить
X ₁ и Y ₁ в нулевом раунде.

< Т.е. никакой лишней информации с нулевого раунда в первый пусть не протекает.

> Но хочу обратить Ваше внимание на один нюанс: по сути, у нас нулевой раунд не завершает IKE.
...
Я не могу на вскидку оценить последствия, просто констатирую факт.

< Здесь никаких последствий, изначально задумывалось строгое пошаговое чередование.

И таки чутье меня не подвело: последний вариант протокола уязвим, т.к. злонамеренный Боб может замонтировать UKS.

Reduced version:

A→B: MDC_PKE _B(id _A, X ₀, X ₁)

E→B: MDC_PKE _B(Y ₀, MDC_SEs₀(Y ₁, H(id _E, id _B, X ₁)))

В результате Алиса и Ева расшаривают s ₁ между собой, хотя обе считают, что с Бобом.

В предыдущих вариантах протокола с одним DH-ключом в сообщениях нулевого раунда (а также и в моем редуцированном варианте^[link184]) это невозможно, т.к. Боб не знает s ₁, который одновременно выполняет и функцию вашего s ₀.
Т.к. нулевой раунд по сути не завершает IKE, то информация с него так или иначе должна протекать в следующий раунд для завершения аутентификации.

— unknown (08/09/2014 21:30)   

Недавно удалил локальные записи предыдущих вариантов, не могу теперь понять какая редакция wiki соответствовала последнему неуязвимому варианту.

Удачно заметили. У меня было подозрение, что нельзя отказываться от MAC, т.к. MDC SE позволяет произвольно перешифровывать ответ. А в MAC надо загонять максимум параметров ответа, очень тщательно думая над отбрасыванием якобы лишнего. А то вот можно так доредуцироваться. И особого смысла балансировать в сторону большей отрицаемости за счёт общей безопасности нет.

— gegel (08/09/2014 22:21)   

У меня было подозрение, что нельзя отказываться от MAC

В данной ситуации MAC не поможет: Боб, зная s ₀ и s' ₀, точно так же пересчитает МАС. Но пока не удаляйте последнюю версию: возможно, это была паранойя с моей стороны. Я внимательно перечитал определение UKS (например, в Wiki^[link185]), и оно не совсем совпадает ситуацией выше: классически Алиса должна расшаривать ключ с Евой и думать так же, а Ева должна расшаривать с Бобом, но думать, что с Алисой. В нашем случае ошибаются обе стороны. Возможно, это не считается за UKS, потому что я с удивлением обнаружил, что с трехпроходной SKEME^[link186] (стр. 9) аналогичное тоже легко проделывается.

— unknown (09/09/2014 20:56, исправлен 09/09/2014 20:58)   

Perfect Forward, что Security, что Deniability. Если Боб, с которым связывается Алиса, злонамерен уже в самом начале, то тут мало что поможет.

Правда, вы сами приводили работу "Deniable Authentication and Key Exchange", Mario Di Raimondo, Rosario Gennaro and Hugo Krawczyk, где разобраны и сложные случаи Боба, сотрудничающего с неким судьёй.

Оригинальная работа Кравчика очень старомодно выглядит, сложно её читать. Дело даже не в том, что MD5 там ещё считается стойкой функцией. Сейчас в работах вводят некую абстрактную h про которую говорят, что h — это случайный оракул или дают какое-то определяющее свойство и т.д.

Так вот, в вышеупомянутой более свежей работе, SKEME изложен несколько иначе. Пока не нашёл, у самого Кравчика есть более свежее переизложение конкретно самого SKEME? Поскольку в работе, где он разбирается, там уменьшена универсальность (по крайнее мере не рассматривается все 4 случая с разным уровнем отрицаемости и «вперёдсекретности»), количество шагов сокращено, сессионый ключ из секрета выводится иначе.

— Гость (11/09/2014 01:53)   

Если делать навороченный протокол и посылать через сеть серверов. Когда оба онлайн, самый рабочий вариант — p2p как hs2hs. Пересылающие вообще ничего не видят кроме того, что кто-то стучится на какой-то адрес. Что идёт внутри шифрованного тунеля — скрыто. Двусторонняя ли это связь — тоже скрыто. Почта ли это, IM или просто пересылка файлов — тоже скрыто. И даже адрес onion будет неизвестен, если стороны готовы у себя в torrc прописать соответствующие опции. А вот с оффлайном так легко не сделать...

— unknown (11/09/2014 21:09, исправлен 11/09/2014 21:11)   

Это не входит в ядро протокола. Чтобы было легче рассматривать, оттуда уже даже выкинуто прикрытие почтового сообщения через PKE после нулевого раунда. Эта обёртка может и должна использоваться для неприметности сообщения по сравнению с обычным PGP и чтобы стойкость протокола гарантирована не была хуже обычной PGP-переписки. Но для наглядности рассмотрения это убрано из формализации. А передача через HS-2-HS, файлообменники, прикручивание анонимных коммуникаций^[link108] — на совести пользователя. Это вынесено за рамки минимальной формализации. Также как возможная внутренняя замена Диффи-Хеллмана на эллиптику и более нестандартные^[link187], и совсем экзотические^[link188] варианты.

— ZAS (03/10/2014 17:28)   

Вначале инициатор связи создает временную PGP-связкy ключей для согласования аутентификационной фразы (тот час удаляя связку после использования)

Именно.

Инициатор A генерирует одноразовую пару ключей, отвечающая сторона B генерирует общий ключ K для симметрики. Начальная аутентификация средствами PGP. Вся дальнейшая связь и аутентификация A и B осуществляется на ключе K. При каждой транзакции ключ K модифицируется функцией, идущей только вперед (Keccak sponge wrap, как вы предлагаете, или что-то аналогичное). Также K модифицируется по времени.
Такая структура совместимо вписывается в систему PGP c минимальными дополнениями (ключехранилище для K). Оверхед +1 проход на установление связи (по сравнению с обычной PGP). Удобно, практично, просто.

Почтенный gegel, может стоит взять и сделать как дополнительную полезную фичу к PGP.

— gegel (03/10/2014 20:23, исправлен 03/10/2014 20:28)   

Инициатор A генерирует одноразовую пару ключей, отвечающая сторона B генерирует общий ключ K для симметрики. Начальная аутентификация средствами PGP. Вся дальнейшая связь и аутентификация A и B осуществляется на ключе K.

Очень абстрактно. На вскидку атака:

– Инициатор A генерирует одноразовую пару ключей;
– Подписывает временный публичный ключ и отсылает его B
– Ева перехватывает, переподписывает, и отсылает его B, выдавая за свой;
– B получает, генерирует K, шифрует с помощью полученного ключа и отсылает E. E в неизменном виде пересылает А.
В итоге классическая UKS: А считает, что общается с B, и общается с ним на самом деле. B считает, что общается с E, но общается с А.

Про отрицаемость в предложенной схеме вообще речь не идет. Об самоизлечении – тоже (при утечке симметричного ключа на каком-то этапе все последующие сообщения будут скомпрометированы даже для пассивного атакующего).
Хотя похожий протокол (на однонаправленной хеш-функции) используется в Циммермановском SilentCircle.

PS: Keccak sponge wrap – это режим аутентифицируемого шифрования с использованием Keccak Sponge. Хеш-функция – просто Keccak.

— ZAS_ (03/10/2014 21:06)   

Инициатор A генерирует одноразовую пару ключей, отвечающая сторона B генерирует общий ключ K для симметрики. Начальная аутентификация средствами PGP. Вся дальнейшая связь и аутентификация A и B осуществляется на ключе K.

– Инициатор A генерирует одноразовую пару ключей;
– Подписывает временный публичный ключ и отсылает его B
– Ева перехватывает, переподписывает, и отсылает его B, выдавая за свой;

Начальный обмен одноразовой парой закрыт и аутентифицирован долговременными PGP ключами A и B. Последующий обмен на ключе K тоже может быть инкапсулирован в PGP почту.

(при утечке симметричного ключа на каком-то этапе все последующие сообщения будут скомпрометированы даже для пассивного атакующего).

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

Про отрицаемость в предложенной схеме вообще речь не идет. Об самоизлечении – тоже

После того как установлен начальный контакт на ключе K, мы можем периодически переустанавливать ключ с помощью той же процедуры с одноразовой парой ключей. Причем делать это автоматически, на фоне идущей переписки.

Вспоминается популярная песня из детства с припевом "Пусть лучше будет хуже чем не будет совсем" (не помню кто пел).

— unknown (19/01/2015 11:22, исправлен 19/01/2015 11:25)   

Здесь^[link189] авторы интересно рассматривают One-Round Key Exchange (ORKE) и Non-Interactive Key Exchange (NIKE) сверяясь с моделями Bellare and Rogaway (the BR model) и Canetti and Krawczyk (the CK model). Им удалось доказать PFS для достаточно универсального протокола (м.б. не завязан на DH) — так там ещё разные PFS бывают, они отдельно рассматривают weak PFS, а на отрицаемость они даже не замахивались.

В очередной раз убеждаюсь: единственное, что приходит в голову после чтения таких работ — самопальные протоколы сразу в топку, нечего страдать NIH и изобретать своё, особенно если такая тема так сложно идёт даже у продвинутых теоретиков.

— ZAS (20/01/2015 20:24)   

Вспоминается популярная песня из детства с припевом "Пусть лучше будет хуже чем не будет совсем" (не помню кто пел).

авторы интересно рассматривают One-Round Key Exchange (ORKE) и Non-Interactive Key Exchange (NIKE)

Они рассматривают другой класс протоколов; а у Вас, как всегда, нет аргументов по сути дела.

В очередной раз убеждаюсь: единственное, что приходит в голову после чтения таких работ — самопальные протоколы сразу в топку, нечего страдать NIH и изобретать своё,

Когда-то был большой проект, в котором, помимо многого прочего, нужно было разработать схему помехоустойчивого кодирования. На соседней кафедре был профессор с мировым именем в теории кодов. Обратились к нему. Ничего они не сделали, в результате пришлось все делать самим. Получилось довольно коряво, однако работоспособно. C позиции нынешних знаний, конечно, следовало бы сделать не то и не так, но Карла Маркс нас учил что практика – критерий истины. Такие дела.

http://www.zas-comm.ru

— Гость (20/01/2015 20:42)   

Как определили работоспособность? Слили схему кодирования противнику и в реальной войне он не смог заглушить канал? Да даже если и так, означает ли это, что в следующей войне он не заглушит?

Когда практика столкнётся с неумолимой теорией, стелить соломку будет поздно. В таком темпе можно и вечные двигатели изобретать, пока лох деньги несёт, и защиту от копирования (пока её не сломали) и всё остальное. У ZAS'а промытые мозги по самое нехочу. Понимания нет, а гонора выше крыши.

— ZAS (20/01/2015 21:25)   

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

Как определили работоспособность?

Обеспечивает запас С/Ш, превосходящий требования T.З.

Слили схему кодирования противнику и в реальной войне он не смог заглушить канал? Да даже если и так, означает ли это, что в следующей войне он не заглушит?

"Мне не нужна вечная игла для примуса. Я не собираюсь жить вечно." © Остап Бендер

У ZAS'а промытые мозги по самое нехочу. Понимания нет, а гонора выше крыши.

Слова, слова, одно бла-бла-бла.

Может, есть какие-то возражения по сути предлагаемого протокола – минимальной надстройки над PGP ?

http://www.zas-comm.ru

— Гость (20/01/2015 21:51)   

SNR — это ни о чём в данном случае. По всему диапазону не заглушишь.


/comment81439^[link190]. Тогда завязывай с научным подходом, доказательствами, страховками, планированием и давай вперёд в средневековье, где практика — критерий истины.


Практика — критерий истины. Я ничего не шифровал и меня не прослушали, значит, моё шифрование идеально.

— ZAS (20/01/2015 22:21)   
Eсть какие-то возражения по сути предлагаемого протокола – минимальной надстройки над PGP ?

Нет замечаний/предложений – не о чем говорить.

Тогда завязывай с научным подходом, доказательствами, страховками, планированием и давай вперёд в средневековье, где практика — критерий истины. Я ничего не шифровал и меня не прослушали, значит, моё шифрование идеально.

Болтун.

— Гость (20/01/2015 22:27)   

Будет оформленная научная работа по протоколу, прошешедшая реферирование, — будет, о чём говорить. Без этого говорить не о чем.

— ZAS (21/01/2015 20:32)   

> Eсть какие-то возражения по сути предлагаемого протокола – минимальной надстройки над PGP ?

Будет оформленная научная работа по протоколу, прошешедшая реферирование, — будет, о чём говорить.

Разница подходов: одним интересно прочтение/написание статей, другим нужны рабочие приложения. Как писал unknown, security как таковая ему лично не нужна ни в каком виде. В результате, когда предлагается доделать простую практически полезную фичу к PGP, обсуждение сьезжает к проблемам сферических коней в вакууме.

http://www.zas-comm.ru

— Гость (21/01/2015 22:50)   
А не хочется браться за практику, когда заранее понятно, что с вероятностью 99% через какое-то время станет понятно, что вся эта практика даёт лишь иллюзию безопасности и элементарно ломается. Вспоминается PGP Phone Циммермана: несмотря на его популярность в своё время, сейчас там обнаружена масса дыр и того, как делать не стоило бы. Отсюда идёт вкус к правильному проектированию: теория → инженерия → образец → практика. Если теории нет, инженерия превращается в самоуспокоение. Но у нас же не форум по психологическому самоуспокоению и достижению комфорта чувств, зачем себя обманывать.


Тут уже 14 страниц обсуждений, как это сделать. Вы их все прочитали и осилили? Поняли все проблемы и трудности, осознали их? Я, например, нет. Как говорят, не освоив «А», браться за «Б» нет смысла.

Если мне лично интересная какая-то тема, я не ленюсь разобрать её полностью и все ранее высказанные аргументы^[link191], прежде чем настаивать на своей правоте. Того же требую и от других.

— unknown (22/01/2015 09:33)   

Иногда всё-таки полезно иметь какую-то штуку реализованной. Вдруг раз в жизни срочно понадобится?


Да пожалуйста, я не против подхода «пусть будет сделано хоть из говна и палок, лишь бы работало». Но только в мелких некритичных решениях на уровне быдлокодинга, где теоретизирование и грамотное проектирование само по себе смешно. А как применить принцип "Just works" к безопасности — не представляю. Может быть сильное или слабое доказательство безопасности, но вот чтобы вообще никакого…

— ZAS (22/01/2015 18:32)   

Тут уже 14 страниц обсуждений, как это сделать. Вы их все прочитали и осилили?

В меру своей ограниченности.

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

unknown, спасибо за ccылку на статью по ORKE. Красиво.

я не против подхода «пусть будет сделано хоть из говна и палок, лишь бы работало».

Пожалуйста. Kорреспонденты переписываются по PGP, и в каждое письмо вкладывают новый открытый ключ. На котором другая сторона шифрует контент ответного письма. Этот вариант прост, и предлагался вначале треда. PFS против пассивной атаки обеспечивается.

http://www.zas-comm.ru

— gegel (22/01/2015 20:31, исправлен 22/01/2015 20:36)   

unknown, спасибо за ccылку на статью по ORKE.

Присоединяюсь. А работы по теме все идут и идут...
В статье есть интересная ссылка [21]^[link192]
Прослеживается сходство с элементами IKE Онионфона^[link193]. Кстати, если будет возможность, посмотрите и мой протокол свежим взглядом (раздел 7.4). Понимаю, что подход в виде ревью не совсем корректный, но пока без вариантов.

Kорреспонденты переписываются по PGP, и в каждое письмо вкладывают новый открытый ключ.

PFS – да. Но вопрос отрицаемой аутентификации остается открытым: или вы оставляете доказательство владения корневым ключом, или ваш корреспондент не уверен, что переписывается именно с вами. А на фоне попыток аутентификации неизбежно появляются вопросы: уязвимость к UKS, к KCI, а также защиты идентификаторов от пассивного и активного атакующего.
В многопроходных конструкциях решить это легче (я пытался это сделать в своем 6-проходном протоколе Онионфона), но через почту это практически нереально. А красивые одно- и двух-проходные протоколы (включая ранее упоминаемый в теме и симпатичный мне NIDA^[link99]) реально bleeding edge – публикаций масса, но ноль практических применений.

— Гость (23/01/2015 05:07)   

Хочу обратить внимание на протокол Tor'а. Его создавали правильно: от теории к практике, а не через "just works", поэтому когда дошло дело до реальных атак и серьёзных атакующих, всё оказалось не так плохо — АНБ до сих пор ломает голову. А есть I2P, за который как только взялись исследователи, так сразу же обнаружили массу тривиальных атак с полным разрушением анонимности, его безопасность стоит на одном честном слове.


Можно и что-то промежуточное: периодически время от времени по желанию сверять текущие сеансовые ключи по доверенному каналу.

— unknown (23/01/2015 09:39)   

Не совсем. Его делали на основе самых консервативных протоколов обмена ключей, но Provable Security для базового криптопротокола была получена от других авторов уже задним числом. Поэтому атаку на навязывание слабых DH-модулей в самом начале они всё-таки пропустили.

— gegel (23/01/2015 09:46)   

по доверенному каналу

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

— unknown (23/01/2015 11:09)   

Пока не разбирал. Режет глаза то, что конкатенация (объединение) у вас обозначены через | вместо ||. Там \parallel надо или что-то такое.

— gegel (23/01/2015 11:43)   

Там \parallel надо или что-то такое.

Спасибо, поправлю. И уважаемого Гостя^[link194] учту.

— ZAS (23/01/2015 19:16)   

Хочу обратить внимание на протокол Tor'а. Его создавали правильно: от теории к практике, а не через "just works", поэтому когда дошло дело до реальных атак и серьёзных атакующих, всё оказалось не так плохо — АНБ до сих пор ломает голову. А есть I2P, за который как только взялись исследователи, так сразу же обнаружили массу тривиальных атак с полным разрушением анонимности, его безопасность стоит на одном честном слове.

Оставьте протоколы; не в них дело. Иллюзия безопастности TOR основана на вере в некомпрометированность DA. Весьма наивная точка зрения, учитывая силы и интересы, которые за этим стоят. DA – гвоздь всей концепции. Плюс к тому атаки на клиента, как со стороны выхода из TOR, так и cо стороны входа.

— ZAS (23/01/2015 19:57)   

Kорреспонденты переписываются по PGP, и в каждое письмо вкладывают новый открытый ключ. Этот вариант прост, и предлагался вначале треда. PFS против пассивной атаки обеспечивается.

PFS – да.

Большое преимущество, к тому же реализуемое при минимальных переделках и без потери совместимости.

Но вопрос отрицаемой аутентификации остается открытым:

Да и пусть остается. Будет чем заняться.

http://www.zas-comm.ru

— Гость (24/01/2015 00:31)   

На выходе основная атака — эксплоиты, а на входе что? Атаки пересечения и подтерждения? Так это принципиально неустранимо в сетях с минимальной задержкой.

— unknown (18/03/2015 10:25)   
В рассылке хвалили обзор по Tor'у — Performance and Security Improvements for Tor: A Survey^[link195]. Читать его весь не надо, полезно иметь перед глазами.

По теме топика. Старый Tor-протокол был уязвим к MitM (см. стр. 23 — 24). Сейчас там используется выработка ключа ntor. Разумеется, там только PFS, но не отрицаемость. Тем не менее, оно м.б. полезно для этой темы и смежных.

Тор-узел публикует в статистике постоянный (общий для многих клиентов, длительно не меняющийся) g^b. Клиент посылает (g^x₁, g^x₂) в качестве эфемерного запроса. Узел посылает в ответ эфемерный g^y.

Клиент вычисляет сессионный эфемерный ключ как хэш от: (g^b)^x₁ (g^y)^x₂
Узел тор: (g^x₁)^b (g^x₂)^y

В принципе, g^b можно и UID'ом на PGP-ключ повесить, там ограничение в 4кБ.

— gegel (18/03/2015 11:41)   

Клиент вычисляет сессионный эфемерный ключ как хэш от: (gb)x1 (gy)x2

Имелась в виду конкатенация, я так понимаю. Созвучно с обсуждавшимся в теме TripleDH, но с односторонней аутентификцией (сервера перед клиентом).

gb можно и UID'ом на PGP-ключ повесить

Это вообще интересный поворот. Я так понимаю, доверие к UIDу эквивалентно доверию к самому ключу. Тогда можно прилепить 256-битный EC25519 ключ в виде UIDа и отрабатывать любой доказуемо надежный и отрицаемый IKE. А дальше – правило: если стороны могут отрицать IKE, то вся остальная переписка на базе выработанного ключа – тоже отрицаема.

— unknown (18/03/2015 11:59, исправлен 18/03/2015 12:06)   

По идее да, странно, что в самой работе это не уточнено и не написано, что-то вида:
H ( (g^b)^x₁ ║ (g^y)^x₂ ) = H ( (g^x₁)^b ║ (g^x₂)^y )

Абсолютно — никто кроме владельца закрытой сертифицирующей части не может его добавлять/менять/отзывать.

Это да, главное помнить, что g^b в виде UID'а выкладывается в паблик, неотрицаемо связанный с ключом владельца. Останется отвязать от него остальной протокол если помимо PFS нужна и отрицаемость.

Кстати, на PGP ключ в качестве UID'а можно вместо самих посторонних ключей можно вешать их хэш-отпечатки: H (имя сайта, TLS-сертификата), хоть H(g^b), хоть H(OTR), хоть H(чего-угодно) и т.д. При первом запросе по открытому каналу владелец ключа вышлет в ответ на H(g^b), извлечённый с ключа — свой g^b вместе с сеансовым g^y. Сам g^b даже не надо будет подписывать — он достоверен по хэшу. А пользователю достаточно его у себя один раз сохранить для всего последующего окна переписок.

— gegel (18/03/2015 21:38, исправлен 18/03/2015 21:39)   

на PGP ключ в качестве UID'а можно вместо самих посторонних ключей можно вешать их хэш-отпечатки

Да, это открывает интересные перспективы, надо обдумать. Просто на это раньше мы как то не обратили внимание.

Клиент посылает (gx1, gx2) в качестве эфемерного запроса.

Вот только я в упор не могу понять смысл использования двух ефемеральных ключей в запросе. Я так понимаю, они независимы и на этапе генерации, и на этапе передачи (т.е. каждый их них может быть подменен отдельно при MitM). Т.о. явно не просматривается никаких преимуществ перед вариантом:
H ( ( g^b )^x1 ║ ( g^y )^x1 ) = H ( ( g^x1 )^b ║(g^x1 ) ^y )
разве что перестраховка неидеальности хеш-функции. Но, конечно, авторам виднее.

— unknown (19/03/2015 09:57, исправлен 19/03/2015 10:02)   

g^b — не эфемерный, он неделями и месяцами не меняется в Tor-статистике, он уникальный для узла, но общий для уставноления соединения с тысячами разных пользователей.

Верно.

g^b и g^y заверены электронной подписью тор-узла, а g^b заверен ещё и статистикой всей тор-сети.

Идея в том, что g^b подписывается узлом, заверяется подписью статистики всей сети и проверяется по подписи на стороне клиента один раз, а используется многократно и с разными пользователями (это постоянный или долговременный ключ узла, который могут закэшировать клиенты), а g^y — одноразовый параметр для каждого сеанса, который уничтожается сразу после использования и не является общим ни с кем, кроме конкретного пользователя (соединения, тор-цепочки и т.д.).

Оно как бы известно, что OpenPGP UID'ы — некий «клей», которым можно объединять доверие между разными адресами, параметрами и протоколами, просто это почему то широко не используется, хотя смену адресов сайта и OTR-отпечатков для Jabber некоторые вешают на свой ключ именно UID'ами. У кого-то может поменяться имя сайта, адрес e-mail, адрес для связи через onionphone, но считается, что PGP-ключ просто так отобрать не могут.

— SATtva (19/03/2015 10:05)   

На самом деле, для таких целей есть более каноничный контейнер — OpenPGP notations. Это произвольные метаданные, привязываемые к UID и не засирзагаживающие при этом вывод --list-keys. См. man gpg ⟶ --cert-notation и --edit-key notation.

— unknown (19/03/2015 10:18, исправлен 19/03/2015 12:48)   

Спасибо за уточнение, надо будет поэкспериментировать^[link196]. М.б. полезная штука для такого рода целей.

---

Насчёт разницы между:

H ( (g^b)^x₁ ║ (g^y)^x₂ ) = H ( (g^x₁)^b ║ (g^x₂)^y )

и

H ( (g^b)^x₁ ║ (g^y)^x₁ ) = H ( (g^x₁)^b ║ (g^x₁)^y )

В ходе прослушивания сеанса вывода совместного ключа противник не знает b, но также как и пользователь знает g^b; не знает y, но знает g^y.

Оно как-то неканонично показывать противнику результат возведения в степень одного и того же числа по разным основаниям. Как бы это число x₁ не вычислилось упрощённым способом или в отношении него не возникло хотя бы частичной утечки битов. А тем более если мы начинаем DH переносить в разные группы эллиптики.

— gegel (19/03/2015 10:22)   
Вы неверно меня поняли: я имел в виду, что вместо двух ефемеральных ключей x1 и x2, генерируемых клиентов для каждого сеанса, можно генерировать всего один, и возносить в его степень и g^b, и g^y.
По идее, от этого ничего не изменится в плане безопасности, по крайней мере в той интерпретации протокола, как Вы его описали.

— unknown (19/03/2015 10:23)   

Это даже с учётом уточнения в /comment90539^[link197]?

— gegel (19/03/2015 10:24)   
Опоздал и с ответом, и с правкой. У нас прямо онлайн :)
Сейчас осмыслю...

— gegel (19/03/2015 10:29)   

Как бы это число x1 не вычислилось упрощённым способом или в отношении него не возникло хотя бы частичной утечки битов.

Это да, но, мне кажется, только до хеширования. Я специально уточнил, что это может быть перестраховка от недостатков хеш-функции.
Если хеш (суб-)идеален (тот же Kecсak), то невооруженным глазом разница с одним и двумя разными эфемералами не просматривается явно ИМХО. Хотя, конечно, авторам виднее, и я вполне могу жестко ошибаться.

— unknown (19/03/2015 11:26, исправлен 19/03/2015 11:29)   

Пусть Алиса отправила g^x₁ и получила g^y. В процессе согласования это же не под хэшем отправляется.

Пусть MitM невозможен (всё подписано), но Ева записывает согласование.

Может ли Ева повторно инициировать сеансы с этим узлом и повторно отправлять некоторые сочетания параметров Алисы и своих новых, чтобы пытаться как-то различать: (g^b)^x₁, (g^b)^x'₁, (g^y')^x₁, (g^y')^x'₁ так, чтобы на основании своих x'₁ и новых ответов узла с g^y' как-то порушить PFS, что-то узнать о изначальных x₁, получить доступ к какому-то оракулу?

— gegel (19/03/2015 11:40, исправлен 19/03/2015 11:48)   

Может ли Ева

Это хорошие вопросы, но теперь представьте то же, только с x1 и x2.
В чем существенная разница? (помним, что результирующий секрет – результат хеширования, и его утечка в идеале не дает информации об компонентах под хешем).
Разве что вместо 128 бит энтропии одного ключа используется 256 в двух...

— unknown (19/03/2015 12:33, исправлен 19/03/2015 12:51)   

Пока делаю себе (а также — gegel'ю и всем желающим)) заметку на две работы:

[1] Anonymity and one-way authentication in key exchange protocols^[link198].
[2] Ace: An Efficient Key-Exchange Protocol for Onion Routing^[link199].

После их осмысления, подумать над:

1. Почему используется два разных параметра x₁ и x₂?
2. Можно ли эффективно использовать односторонне-аутентифицированный обмен ключами (1W-AKE) для параметров, висящих в notations-контейнере на OpenPGP ключе?
3. Если п.2 — «да», то что из этого можно получить? Например:
   1. Аноним (псевдоним) переписывается с известным владельцем ключа без мозможности MitM. Владелец неотрицаем, PFS есть.
   2. Возможен переход к взаимной отрицаемости с PFS.
   3. Что-то ещё?
4. Если из п.3 следует что-то полезное, то как это эффективно реализовать?

P.S. По поводу OpenPGP notations^[link200] завёл отдельную тему^[link196].

— gegel (19/03/2015 12:58)   

Оно как бы известно, что OpenPGP UID'ы — некий «клей», которым можно объединять доверие между разными адресами, параметрами и протоколами

У кого-то может поменяться имя сайта, адрес e-mail, адрес для связи через onionphone

Вот если бы я, балбес, подумал об этом раньше, то не стал бы включать PGP-подпись в долговременый ECDH-ключ onionphone (раздувая его размер), а просто рекомендовал бы вешать его отпечаток на свой PGP в качестве UIDа (можно даже автоматизировать).
Ничего, век живи – век учись, использую в криптофоне, там размеры ключей весьма критичны, т.к. скорость канала всего 1200 bps.

— gegel (19/03/2015 13:05, исправлен 19/03/2015 13:40)   

После их осмысления, подумать

Обязательно подумаю. И вспомнился NIDA^[link99]: без PFS, но отрицаемость сообщения будет даже в не-интерактивном режиме.

PS: бегло просмотрел оба документа по ссылкам выше. По первой ссылке (стр.18) описан ntor, использующий хеш-функцию для выведения секрета. И используется по одному эфемералу с каждой стороны (как я и предлагал).
По второй ссылке в протоколе ACE (стр. 3) авторы заморочились на перфомансе сервера, и для его улучшения отказались от хеша за счет двух эфемаралов от клиента (см. в аннотации). Секрет выводится за счет умножения элементов группы, по типу HMQV и т.п. протоколов, так что там таки не конкатенация была. Так что все стало на свои места.
Робко выскажу свое мнение: имея хорошие доказуемо стойкие современные RO-PRF, использовать эту математику на кривых только ради перфоманса не совсем хорошо, даже как-бы доказав стойкость. Прецеденты типа "Менезис vs Кравчик" ничему не научили.

— unknown (19/03/2015 13:41, исправлен 19/03/2015 13:45)   

Хоть какая-то польза. Но не торопитесь. Всё-таки SATtva посоветовал notations^[link200], а не UID. В этом есть очевидные плюсы, но приходят в голову и сомнения насчёт минусов. Здесь озвучивать не буду, лучше там^[link196].

Только не навязывать. Я бы не доверил чужой программе лазать в мой кейринг. А у некоторых он ещё хитро разобран и упрятан как кащеева смерть^[link201]. Кстати, идея с UID'ом с той темы и возникла.

— gegel (14/09/2015 21:10)   
Интересная публикация по сабжу:

http://www.ieee-security.org/T.....rchived/6949a305.pdf^[link202]

Предложена FS-PKE схема на основе билинейных спариваний на эллиптике, с выкалыванием, пригодная для обеспечения PFS в email. Публикуется небольшой долговременный публичный ключ. При создании письма отправитель использует таг, содержащий, например, таймстемп или идентификатор отправителя. Получатель, дешифровав сообщение, обрабатывает свой приватный ключ, "выкалывая" информацию соответственно использованному тагу, т.о. после обработки этим ключом можно декриптовать все сообщения, кроме использующих данный таг (включая прочитанное).
Данная схема обеспечивает PFS без интеракций, в отличие от стандартных протоколов c DH-материалом в каждом сообщении, типа OTR или Axolotl. Единственное ограничение – вычислительная сложность выкалывания, поэтому рекомендуется использовать данную схему для инициализации (или переинициализации при сбое) переписки, а затем – OTR или Axolotl.

— unknown (16/09/2015 17:33)   

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


Не хотел в своё время в этом разбираться, но похоже это неизбежное зло перспективное направление для всех протоколов.

— gegel (16/09/2015 21:35, исправлен 16/09/2015 21:56)   

после каждой итерации размер секретного ключа растёт, а не уменьшается

Авторы это осознают, поэтому используют "выкалывание" только в пределах установленного временного интервала ("окна"), а между окнами возвращаются к исходному приватному ключу, обновляя его посредством HIBE, причем с возможностью сохранять "стерилизованные" мастер-ключи прошлых окон (декриптовать ими все-еще можно, но вывести из них мастер-ключи для последующих окон – нет).
Некоторое обсуждение с долей критики – в рассылке Messaging:
http://moderncrypto.org/mail-a.....essaging/2015.txt.gz^[link203]
тема libforwardsec: forward secure encryption for email and asynchronous messaging

Библиотека на С++ доступна на github^[link204] и уже пригодна для работы с gpg

похоже это неизбежное зло

Обычный диплом^[link205] типичной русской девушки. И более обобщающий^[link206], той же школы.

— unknown (16/09/2015 22:12, исправлен 16/09/2015 22:13)   

Возможно, что они предложили более модный костыль, но всё равно костыль.

Забавно, там рассматривается IBE, перевод мнения Дж. Калласа по которому был одним из моих первых материалов на сайте^[link207] ;)

— pgprubot (27/09/2015 06:22, исправлен 27/09/2015 06:26)   

Внешне статья смотрится солидной, хорошо проработанной и тщательно написанной. Общий смысл, похоже, неплохо описан в окрестности абзаца «Combining FS-PKE and Puncturable encryption» на стр. 312. Они предлагают нечто более общее и универсальное, чем forward secrecy: puncturable encryption. Оно более общее, может быть применено много для чего (см. § Secure deletion, стр. 316).

Общий смысл, кажется, восходит к довольно тривиальной идее: на каждый момент времени вешать/создавать свой ключ, что жутко неоптимально. Остаётся надежда, что если не нужен настолько общий случай, как выборочное выкалывание произвольных моментов времени, то можно придумать более оптимальную схему для forward secrecy.

По первой ссылке — курсовая работа, диплом — только по второй (если только это не очередное «я специально привел эту ссылку, чтобы посмотреть реакцию»^[link208]).