id: Гость   вход   регистрация
текущее время 12:09 29/03/2024
Автор темы: gegel, тема открыта 20/11/2013 11:41 Печать
Категории: инфобезопасность, защита email
https://www.pgpru.com/Форум/Криптография/АналогPGPСОбеспечениемОтрицаемостиИНаперёдЗаданнойСекретностиОффлайн
создать
просмотр
ссылки

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


Обсуждение в соседней теме натолкнуло на мысль: существует ли решение, аналогичное PGP и обеспечивающее для оффлайн-сообщений конфиденциальность и аутентификацию, но плюс отрицаемость и наперед заданную секретность (PFS), ну, и, желательно, тихое уведомление о прессинге. Нашел похожий вопрос на crypto.stackexchange: похоже, что готовых решений пока нет. Возможно, где-то на pgpru это уже обсуждалось, или что-то уже появилось?



 
На страницу: 1, 2, 3, 4, 5, ... , 16, 17, 18, 19, 20 След.
Комментарии
— unknown (19/03/2015 12:33, исправлен 19/03/2015 12:51)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


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


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


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

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

— gegel (19/03/2015 12:58)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Оно как бы известно, что OpenPGP UID'ы — некий «клей», которым можно объединять доверие между разными адресами, параметрами и протоколами

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

Вот если бы я, балбес, подумал об этом раньше, то не стал бы включать PGP-подпись в долговременый ECDH-ключ onionphone (раздувая его размер), а просто рекомендовал бы вешать его отпечаток на свой PGP в качестве UIDа (можно даже автоматизировать).
Ничего, век живи – век учись, использую в криптофоне, там размеры ключей весьма критичны, т.к. скорость канала всего 1200 bps.
— gegel (19/03/2015 13:05, исправлен 19/03/2015 13:40)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
После их осмысления, подумать

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


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

— unknown (19/03/2015 13:41, исправлен 19/03/2015 13:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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



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

— gegel (14/09/2015 21:10)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Интересная публикация по сабжу:

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

Предложена FS-PKE схема на основе билинейных спариваний на эллиптике, с выкалыванием, пригодная для обеспечения PFS в email. Публикуется небольшой долговременный публичный ключ. При создании письма отправитель использует таг, содержащий, например, таймстемп или идентификатор отправителя. Получатель, дешифровав сообщение, обрабатывает свой приватный ключ, "выкалывая" информацию соответственно использованному тагу, т.о. после обработки этим ключом можно декриптовать все сообщения, кроме использующих данный таг (включая прочитанное).
Данная схема обеспечивает PFS без интеракций, в отличие от стандартных протоколов c DH-материалом в каждом сообщении, типа OTR или Axolotl. Единственное ограничение – вычислительная сложность выкалывания, поэтому рекомендуется использовать данную схему для инициализации (или переинициализации при сбое) переписки, а затем – OTR или Axolotl.
— unknown (16/09/2015 17:33)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


Не хотел в своё время в этом разбираться, но похоже это неизбежное зло перспективное направление для всех протоколов.
— gegel (16/09/2015 21:35, исправлен 16/09/2015 21:56)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
после каждой итерации размер секретного ключа растёт, а не уменьшается

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


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


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

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


— unknown (16/09/2015 22:12, исправлен 16/09/2015 22:13)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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



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

— pgprubot (27/09/2015 06:22, исправлен 27/09/2015 06:26)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

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



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



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

На страницу: 1, 2, 3, 4, 5, ... , 16, 17, 18, 19, 20 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3