id: Гость   вход   регистрация
текущее время 21:57 28/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 След.
Комментарии
— 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)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В рассылке хвалили обзор по Tor'у — Performance and Security Improvements for Tor: A Survey. Читать его весь не надо, полезно иметь перед глазами.

По теме топика. Старый Tor-протокол был уязвим к MitM (см. стр. 23 — 24). Сейчас там используется выработка ключа ntor. Разумеется, там только PFS, но не отрицаемость. Тем не менее, оно м.б. полезно для этой темы и смежных.

Тор-узел публикует в статистике постоянный (общий для многих клиентов, длительно не меняющийся) gb. Клиент посылает (gx1, gx2) в качестве эфемерного запроса. Узел посылает в ответ эфемерный gy.

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

В принципе, gb можно и UID'ом на PGP-ключ повесить, там ограничение в 4кБ.
— gegel (18/03/2015 11:41)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Клиент вычисляет сессионный эфемерный ключ как хэш от: (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)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

По идее да, странно, что в самой работе это не уточнено и не написано, что-то вида:
H ( (gb)x1 ║ (gy)x2 ) = H ( (gx1)b ║ (gx2)y )



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



Это да, главное помнить, что gb в виде UID'а выкладывается в паблик, неотрицаемо связанный с ключом владельца. Останется отвязать от него остальной протокол если помимо PFS нужна и отрицаемость.


Кстати, на PGP ключ в качестве UID'а можно вместо самих посторонних ключей можно вешать их хэш-отпечатки: H (имя сайта, TLS-сертификата), хоть H(gb), хоть H(OTR), хоть H(чего-угодно) и т.д. При первом запросе по открытому каналу владелец ключа вышлет в ответ на H(gb), извлечённый с ключа — свой gb вместе с сеансовым gy. Сам gb даже не надо будет подписывать — он достоверен по хэшу. А пользователю достаточно его у себя один раз сохранить для всего последующего окна переписок.

— gegel (18/03/2015 21:38, исправлен 18/03/2015 21:39)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
на PGP ключ в качестве UID'а можно вместо самих посторонних ключей можно вешать их хэш-отпечатки

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


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

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

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

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



Верно.



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


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



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

— SATtva (19/03/2015 10:05)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

На самом деле, для таких целей есть более каноничный контейнер — OpenPGP notations. Это произвольные метаданные, привязываемые к UID и не засирзагаживающие при этом вывод --list-keys. См. man gpg--cert-notation и --edit-key notation.
— unknown (19/03/2015 10:18, исправлен 19/03/2015 12:48)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


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


H ( (gb)x1 ║ (gy)x2 ) = H ( (gx1)b ║ (gx2)y )


и


H ( (gb)x1 ║ (gy)x1 ) = H ( (gx1)b ║ (gx1)y )


В ходе прослушивания сеанса вывода совместного ключа противник не знает b, но также как и пользователь знает gb; не знает y, но знает gy.


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

— gegel (19/03/2015 10:22)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Вы неверно меня поняли: я имел в виду, что вместо двух ефемеральных ключей x1 и x2, генерируемых клиентов для каждого сеанса, можно генерировать всего один, и возносить в его степень и gb, и gy.
По идее, от этого ничего не изменится в плане безопасности, по крайней мере в той интерпретации протокола, как Вы его описали.
— unknown (19/03/2015 10:23)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Это даже с учётом уточнения в /comment90539?
— gegel (19/03/2015 10:24)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Опоздал и с ответом, и с правкой. У нас прямо онлайн :)
Сейчас осмыслю...
— gegel (19/03/2015 10:29)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Как бы это число x1 не вычислилось упрощённым способом или в отношении него не возникло хотя бы частичной утечки битов.

Это да, но, мне кажется, только до хеширования. Я специально уточнил, что это может быть перестраховка от недостатков хеш-функции.
Если хеш (суб-)идеален (тот же Kecсak), то невооруженным глазом разница с одним и двумя разными эфемералами не просматривается явно ИМХО. Хотя, конечно, авторам виднее, и я вполне могу жестко ошибаться.
— unknown (19/03/2015 11:26, исправлен 19/03/2015 11:29)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Пусть Алиса отправила gx1 и получила gy. В процессе согласования это же не под хэшем отправляется.


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


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

— gegel (19/03/2015 11:40, исправлен 19/03/2015 11:48)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Может ли Ева

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

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