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

Kорреспонденты переписываются по PGP, и в каждое письмо вкладывают новый открытый ключ. Этот вариант прост, и предлагался вначале треда. PFS против пассивной атаки обеспечивается.

PFS – да.

Большое преимущество, к тому же реализуемое при минимальных переделках и без потери совместимости.

Но вопрос отрицаемой аутентификации остается открытым:

Да и пусть остается. Будет чем заняться.

http://www.zas-comm.ru

На выходе основная атака — эксплоиты, а на входе что? Атаки пересечения и подтерждения? Так это принципиально неустранимо в сетях с минимальной задержкой.

В рассылке хвалили обзор по Tor'у — Performance and Security Improvements for Tor: A Survey. Читать его весь не надо, полезно иметь перед глазами.

По теме топика. Старый 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кБ.

Клиент вычисляет сессионный эфемерный ключ как хэш от: (gb)x1 (gy)x2

Имелась в виду конкатенация, я так понимаю. Созвучно с обсуждавшимся в теме TripleDH, но с односторонней аутентификцией (сервера перед клиентом).

gb можно и UID'ом на PGP-ключ повесить

Это вообще интересный поворот. Я так понимаю, доверие к UIDу эквивалентно доверию к самому ключу. Тогда можно прилепить 256-битный EC25519 ключ в виде UIDа и отрабатывать любой доказуемо надежный и отрицаемый IKE. А дальше – правило: если стороны могут отрицать IKE, то вся остальная переписка на базе выработанного ключа – тоже отрицаема.

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

на PGP ключ в качестве UID'а можно вместо самих посторонних ключей можно вешать их хэш-отпечатки

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

Клиент посылает (gx1, gx2) в качестве эфемерного запроса.

Вот только я в упор не могу понять смысл использования двух ефемеральных ключей в запросе. Я так понимаю, они независимы и на этапе генерации, и на этапе передачи (т.е. каждый их них может быть подменен отдельно при MitM). Т.о. явно не просматривается никаких преимуществ перед вариантом:
H ( ( g^b )^x1 ║ ( g^y )^x1 ) = H ( ( g^x1 )^b ║(g^x1 ) ^y )
разве что перестраховка неидеальности хеш-функции. Но, конечно, авторам виднее.

g^b — не эфемерный, он неделями и месяцами не меняется в Tor-статистике, он уникальный для узла, но общий для уставноления соединения с тысячами разных пользователей.

Верно.

g^b и g^y заверены электронной подписью тор-узла, а g^b заверен ещё и статистикой всей тор-сети.

Идея в том, что g^b подписывается узлом, заверяется подписью статистики всей сети и проверяется по подписи на стороне клиента один раз, а используется многократно и с разными пользователями (это постоянный или долговременный ключ узла, который могут закэшировать клиенты), а g^y — одноразовый параметр для каждого сеанса, который уничтожается сразу после использования и не является общим ни с кем, кроме конкретного пользователя (соединения, тор-цепочки и т.д.).

Оно как бы известно, что OpenPGP UID'ы — некий «клей», которым можно объединять доверие между разными адресами, параметрами и протоколами, просто это почему то широко не используется, хотя смену адресов сайта и OTR-отпечатков для Jabber некоторые вешают на свой ключ именно UID'ами. У кого-то может поменяться имя сайта, адрес e-mail, адрес для связи через onionphone, но считается, что PGP-ключ просто так отобрать не могут.

На самом деле, для таких целей есть более каноничный контейнер — OpenPGP notations. Это произвольные метаданные, привязываемые к UID и не засирзагаживающие при этом вывод --list-keys. См. man gpg ⟶ --cert-notation и --edit-key notation.

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

---

Насчёт разницы между:

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 переносить в разные группы эллиптики.

Вы неверно меня поняли: я имел в виду, что вместо двух ефемеральных ключей x1 и x2, генерируемых клиентов для каждого сеанса, можно генерировать всего один, и возносить в его степень и g^b, и g^y.
По идее, от этого ничего не изменится в плане безопасности, по крайней мере в той интерпретации протокола, как Вы его описали.

Это даже с учётом уточнения в /comment90539?

Опоздал и с ответом, и с правкой. У нас прямо онлайн :)
Сейчас осмыслю...

Как бы это число x1 не вычислилось упрощённым способом или в отношении него не возникло хотя бы частичной утечки битов.

Это да, но, мне кажется, только до хеширования. Я специально уточнил, что это может быть перестраховка от недостатков хеш-функции.
Если хеш (суб-)идеален (тот же Kecсak), то невооруженным глазом разница с одним и двумя разными эфемералами не просматривается явно ИМХО. Хотя, конечно, авторам виднее, и я вполне могу жестко ошибаться.

Пусть Алиса отправила g^x₁ и получила g^y. В процессе согласования это же не под хэшем отправляется.

Пусть MitM невозможен (всё подписано), но Ева записывает согласование.

Может ли Ева повторно инициировать сеансы с этим узлом и повторно отправлять некоторые сочетания параметров Алисы и своих новых, чтобы пытаться как-то различать: (g^b)^x₁, (g^b)^x'₁, (g^y')^x₁, (g^y')^x'₁ так, чтобы на основании своих x'₁ и новых ответов узла с g^y' как-то порушить PFS, что-то узнать о изначальных x₁, получить доступ к какому-то оракулу?

Может ли Ева

Это хорошие вопросы, но теперь представьте то же, только с x1 и x2.
В чем существенная разница? (помним, что результирующий секрет – результат хеширования, и его утечка в идеале не дает информации об компонентах под хешем).
Разве что вместо 128 бит энтропии одного ключа используется 256 в двух...