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

Пока делаю себе (а также — gegel'ю и всем желающим)) заметку на две работы:

[1] Anonymity and one-way authentication in key exchange protocols.
[2] Ace: An Efficient Key-Exchange Protocol for Onion Routing.

После их осмысления, подумать над:

1. Почему используется два разных параметра x₁ и x₂?
2. Можно ли эффективно использовать односторонне-аутентифицированный обмен ключами (1W-AKE) для параметров, висящих в notations-контейнере на OpenPGP ключе?
3. Если п.2 — «да», то что из этого можно получить? Например:
   1. Аноним (псевдоним) переписывается с известным владельцем ключа без мозможности MitM. Владелец неотрицаем, PFS есть.
   2. Возможен переход к взаимной отрицаемости с PFS.
   3. Что-то ещё?
4. Если из п.3 следует что-то полезное, то как это эффективно реализовать?

P.S. По поводу OpenPGP notations завёл отдельную тему.

Оно как бы известно, что OpenPGP UID'ы — некий «клей», которым можно объединять доверие между разными адресами, параметрами и протоколами

У кого-то может поменяться имя сайта, адрес e-mail, адрес для связи через onionphone

Вот если бы я, балбес, подумал об этом раньше, то не стал бы включать PGP-подпись в долговременый ECDH-ключ onionphone (раздувая его размер), а просто рекомендовал бы вешать его отпечаток на свой PGP в качестве UIDа (можно даже автоматизировать).
Ничего, век живи – век учись, использую в криптофоне, там размеры ключей весьма критичны, т.к. скорость канала всего 1200 bps.

После их осмысления, подумать

Обязательно подумаю. И вспомнился NIDA: без PFS, но отрицаемость сообщения будет даже в не-интерактивном режиме.

PS: бегло просмотрел оба документа по ссылкам выше. По первой ссылке (стр.18) описан ntor, использующий хеш-функцию для выведения секрета. И используется по одному эфемералу с каждой стороны (как я и предлагал).
По второй ссылке в протоколе ACE (стр. 3) авторы заморочились на перфомансе сервера, и для его улучшения отказались от хеша за счет двух эфемаралов от клиента (см. в аннотации). Секрет выводится за счет умножения элементов группы, по типу HMQV и т.п. протоколов, так что там таки не конкатенация была. Так что все стало на свои места.
Робко выскажу свое мнение: имея хорошие доказуемо стойкие современные RO-PRF, использовать эту математику на кривых только ради перфоманса не совсем хорошо, даже как-бы доказав стойкость. Прецеденты типа "Менезис vs Кравчик" ничему не научили.

Хоть какая-то польза. Но не торопитесь. Всё-таки SATtva посоветовал notations, а не UID. В этом есть очевидные плюсы, но приходят в голову и сомнения насчёт минусов. Здесь озвучивать не буду, лучше там.

Только не навязывать. Я бы не доверил чужой программе лазать в мой кейринг. А у некоторых он ещё хитро разобран и упрятан как кащеева смерть. Кстати, идея с UID'ом с той темы и возникла.

Интересная публикация по сабжу:

http://www.ieee-security.org/T.....rchived/6949a305.pdf

Предложена FS-PKE схема на основе билинейных спариваний на эллиптике, с выкалыванием, пригодная для обеспечения PFS в email. Публикуется небольшой долговременный публичный ключ. При создании письма отправитель использует таг, содержащий, например, таймстемп или идентификатор отправителя. Получатель, дешифровав сообщение, обрабатывает свой приватный ключ, "выкалывая" информацию соответственно использованному тагу, т.о. после обработки этим ключом можно декриптовать все сообщения, кроме использующих данный таг (включая прочитанное).
Данная схема обеспечивает PFS без интеракций, в отличие от стандартных протоколов c DH-материалом в каждом сообщении, типа OTR или Axolotl. Единственное ограничение – вычислительная сложность выкалывания, поэтому рекомендуется использовать данную схему для инициализации (или переинициализации при сбое) переписки, а затем – OTR или Axolotl.

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


Не хотел в своё время в этом разбираться, но похоже это неизбежное зло перспективное направление для всех протоколов.

после каждой итерации размер секретного ключа растёт, а не уменьшается

Авторы это осознают, поэтому используют "выкалывание" только в пределах установленного временного интервала ("окна"), а между окнами возвращаются к исходному приватному ключу, обновляя его посредством HIBE, причем с возможностью сохранять "стерилизованные" мастер-ключи прошлых окон (декриптовать ими все-еще можно, но вывести из них мастер-ключи для последующих окон – нет).
Некоторое обсуждение с долей критики – в рассылке Messaging:
http://moderncrypto.org/mail-a.....essaging/2015.txt.gz
тема libforwardsec: forward secure encryption for email and asynchronous messaging

Библиотека на С++ доступна на github и уже пригодна для работы с gpg

похоже это неизбежное зло

Обычный диплом типичной русской девушки. И более обобщающий, той же школы.

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

Забавно, там рассматривается IBE, перевод мнения Дж. Калласа по которому был одним из моих первых материалов на сайте ;)

Внешне статья смотрится солидной, хорошо проработанной и тщательно написанной. Общий смысл, похоже, неплохо описан в окрестности абзаца «Combining FS-PKE and Puncturable encryption» на стр. 312. Они предлагают нечто более общее и универсальное, чем forward secrecy: puncturable encryption. Оно более общее, может быть применено много для чего (см. § Secure deletion, стр. 316).

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

По первой ссылке — курсовая работа, диплом — только по второй (если только это не очередное «я специально привел эту ссылку, чтобы посмотреть реакцию»).