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

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


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



 
На страницу: 1, ... , 13, 14, 15, 16, 17, ... , 20 След.
Комментарии
— gegel (27/08/2014 22:02, исправлен 27/08/2014 22:11)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

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

— unknown (27/08/2014 22:37)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В текущей версии "Flat Spheroid" нельзя расшифровать Message c предыдущего раунда, при условии, что долговременный закрытый асимметричный ключ утёк и всё под PKE расшифровывается.

Во первых, стираются Xi-1 и Yi-1, в текущем раунде есть только Xi и Yi, выведенные в т.ч. и с их помощью. Из под текущих Sid предыдущие параметры тоже нельзя узнать. Наконец, секретные DH-параметры ai-1 и bi-1 с предыдущего раунда тоже стёрты. Т.е. si-1 и s'i-1 выводить после завершения того раунда уже не из чего.

Единственно, что незавершённый раунд даёт окно безопасности на два сообщения. М.б., если приделать к этому две пары DH с каждой стороны и ratcheting, как в Axolotl, то что-нибудь и получится. Но пока, можно остановиться на этом варианте и считать раунд с безопасным окном в два сообщения — приемлемым. Хотя это не снимает проблему подтверждения аутентификации при захвате параметров, как внутри раунда, так и при последующем раунде при поступлении новых сообщений с другой стороны.
— gegel (27/08/2014 22:39, исправлен 27/08/2014 22:43)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Хм, у Вас в этом плане ситауция даже лучше, чем у Axolotl: инициатор хранит раундовый приватный ключ с момента отправки запроса до момента получения ответа, а ответчик вообще не хранит. Доверие передается через отрицаемые Sid-ы, защищенные R.
Только вот асимметрично получается, как-то не изящно смотрится. Может, потом будет смысл подумать на счет спаривания типа 01, 12, 23...
И еще: я уже задавал этот вопрос, но так до конца и не понял мотивацию: какой смысл прятать вводимый Xn под MDC SE? Ведь это публичный параметр, может быть передан и открыто. А MDC лишний раз связывает его с Message. Хотя, конечно, в вашем варианте с перманентной PKE-оберткой это же все равно делает MDC PKE.


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

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

— unknown (27/08/2014 23:03)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Можно сократить Sid'ы: пусть сторона B считает Sid также как и отправляемый в сообщении MAC (только со своим RB и Yi+1), но без Message, аналогично и для стороны A: с обычными параметрами, затем с RA и Xi+1, но без параметров ответной стороны. Тогда отправитель может посчитать Sid сразу после отправки и удалить R, получатель — сразу после получения и тоже сразу же удалить R. Вот только сходу не пойму, хорошо ли иметь такой половинчатый Sid, в который включены не все параметры второй стороны, которые передаются в раунде.

Другой вариант: раз инициатор менее защищён — он считает половинчатый Sid, а отправитель может посчитать и полный. Поскольку в аутентификации следующего раунда будут использованы оба Sid'a, то это даст отрицаемое связывание по параметрам ообеих сторон предыдущего сеанса.
— gegel (27/08/2014 23:31)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
но без параметров ответной стороны.

Поскольку в аутентификации следующего раунда будут использованы оба Sid'a

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

Другой вариант: раз инициатор менее защищён — он считает половинчатый Sid, а отправитель может посчитать и полный.

Брр, жуткая асимметрия... У Эркюля Пуарро усы бы бубликом от такого подхода свернулись.
— unknown (27/08/2014 23:59)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Может обеим сторонам вообще считать половинчатый Sid, главное что он заверен посредством текущего s'. Тогда можно не дожидаться ответной половины DH для своего Sid и сразу отбрасывать R, вычисляя Sid в момент отправки-получения. Тогда получатель может сразу отрицать аутентификацию сохранённого сообщения в одном шаге уже внутри раунда: проверил аутентификацию по MAC, посчитал похожий MAC без Message для Sid, сохранил что есть из половинок DH, а полученный R — сразу стёр. Так что, при захвате текущих параметров, Message уже нельзя будет аутентифицировать даже внутри раунда после того как это первым сделал пользователь. И отрицание аутентификации симметричное для каждой стороны внутри раунда, и формулы проще, и опять симметрия не нарушается.

А для передачи отрицаемой аутентификации на следующий раунд достаточно двух половинчатых, но взаимодополняющих Sid.
— gegel (28/08/2014 00:13)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Да, по идее смотрится привлекательно, но надо подумать, как бы чего по ходу не опустили. Похоже, мы уверенно двигаемся в сторону того же минимализма.
— unknown (28/08/2014 09:41, исправлен 28/08/2014 09:42)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Более того, в текущем ненулевом раунде не надо закатывать под MAC текущие X и Y — они уже содержатся в Sid. А текущие s и s' уже выведены на предыдущем раунде.


Предполагается много чего ещё поменять, пока даже не собрался с мыслями, чего написать в TODO. И это только очередной этап. В дальнейшем можно будет и подумать над раздельными sA→B, sB→A, s'A→B и s'B→A через KDF или даже с дополнительной DH-парой.


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

— gegel (28/08/2014 10:32)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Может, тогда хоть включать X и Message под разные SE? Так смотрится лучше в плане отрицаемости: все же MDC как-то их связывает. Это перестраховка, конечно, но не больше, чем квантовый компьютер.
— unknown (28/08/2014 11:13, исправлен 28/08/2014 11:53)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Никак не связывает, если противнику неизвестен совместно выведенный ключ s.


С учётом текущих упрощений V.0.023.

— gegel (28/08/2014 19:19, исправлен 28/08/2014 19:21)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

V.

0.023.

Все таки решили оставить в выведении Sid параметры противоположной стороны от предыдущего раунда (Id / Sid i-1 и Xi-1) ?


Никак не связывает, если противнику неизвестен совместно выведенный ключ s.

Убедили. Случай единичного брутфорса пока не принимаем во внимание.

— unknown (28/08/2014 20:57)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

С нулевым раундом — точно да, иначе как протянуть доверие от первой аутентификации?

А вот в последующих — есть смысл подумать, может оставить только

SidBi+1 = MACs'i (RB, Yi+1);
SidAi+1 = MACs'i (RA, Xi+1).

Судя по приведённой вами работе итальянцев, такие протоколы создавать-то несложно: они все дают слабую наперёд заданную отрицаемость. Они беззащитны в сценарии, если Боб отрицает переписку с Алисой, но Алиса является злонамеренной и сохраняет все s и прочие параметры, чтобы затем передать их стороне, которая знает параметры Боба, чтобы та убедилась, что Message, полученные Бобом, действительно исходили от Алисы. Более того, сторона, перехватывающая письма Боба, но захватившая его закрытый ключ, сможет расшифровать и прочесть все сообщения, которые он у себя удалил после расшифровки, если Алиса злонамеренно сохраняла все параметры сеансов, чтобы подставить Боба.
— gegel (29/08/2014 00:52, исправлен 29/08/2014 01:10)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

У них весьма строгая модель, требующая дополнительного шага в протоколе (коммитмента). Я разбирал их DDH-вариант, стр.29 (хотя остальные тоже интересны), примеряя к нашей задаче. На С я это закодирую, но скриптом – вряд-ли (там нужна элементарная математика над группой, я сам добавлял нужные функции в ядро библиотеки подписи DH25519, немного разобравшись с уже имеющимися функциями).
Еще есть однопроходные отрицаемые аутентификаторы (например, fileNIDA на основе сочетания подписи Шнорра и шифрования Эль-Гамаля, ссылку на который я уже приводил когда-то), позволяющие одновременно отрицаемо аутентифицировать и отправителя, и само сообщение (в нашем случае – вводимый ключ), но у них проблемы с безопасностью, и это уж совсем модерн.


PS: вот, кстати, еще одно простое китайское fileрешение с обычной DH.


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

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

— unknown (29/08/2014 21:31, исправлен 29/08/2014 21:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

А наверное, да. Алиса скажет: вот такого-то числа на его PKEB был отправлен такой-то шифртекст под SEs. Алиса даёт s для этого письма и указывает, какой из этого шифртекста должен извлечься RA, X и Message. Алиса может просто запоминать все s и предъявить их, а захватившая Боба сторона подберёт, чтобы хоть какое-то из них совпало с каким-то перехваченным сообщением и давало осмысленный Message при расшифровке, что уже будет достаточно.


Если сильный противник узнал весь ключевой материал Боба и получил сохранённые параметры сеанса от Алисы, то наверняка он перехватывал и то, что Боб отправлял Алисе под PKEA. Если Алиса сдаст ради компрометации Боба и свой закрытый ключ, то противник может расшифровать то, что Боб отправлял ей, и неважно, общий у них был s в раунде или раздельный: Алиса сдаёт все s и секретные параметры DH всех раундов, противник убеждается, что они подходят и расшифровывает открытый текст Message, отправляемых Бобом для Алисы.


Так-что итальянцы, скорее всего, правы: стойкой отрицаемой аутентификации не существует, если есть сильный противник и злонамеренный второй участник протокола. Все протоколы, которые мы можем обсудить — дают лишь слабую отрицаемость. Поэтому я изначально и не хотел вообще сильно с ней заморачиваться. А то, что хотите вы, получилось ненамного лучше того же Axolotl, SKEME и пр. В моём варианте (и других аналогичных) вообще не важно, что вносить под MAC для выработки id следующего сеанса: хоть все параметры проведённого раунда (это лишь заверит правильность его проведения для участников), хоть вообще пустую строку (константу). MACs' для вывода Sid заверяет лишь факт знания секретного ключа предыдущего сеанса s', который не передавался в открытую, а выводился из DH-обмена. С таким же успехом вместо такого Sid могли бы использоваться и половинки хэша от s для предъявления в следующем раунде, как вы приводили в примерах и др.


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

— gegel (29/08/2014 22:42, исправлен 29/08/2014 22:59)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Если сильный противник узнал весь ключевой материал Боба и получил сохранённые параметры сеанса от Алисы, то наверняка он перехватывал и то, что Боб отправлял Алисе под PKE

К слову: из fileработы Крачика (стр. 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 за публикацию использованных MAC-ключей (концепция: "после проверки MAС получателем любой, знающий содержание сообщения, может его изменить (CTR-mode) и снова аутентифицировать"). Звучит интересно, но на практике еще никому не понадобилось.


PS: если Вас не затруднит, ткните меня в какую-нибудь подходящую LaTeX-заготовку, на досуге перепишу доку на OnionPhone к альфа-релизу.


По ходу реализовал еще одну идею в коде OnionPhone: возможность проброса выбранного UDP-порта через TCP-Tor. Попробовал с VLC-потоковой трансляцией: даже сносную картинку (на низком фрейм-рейте с H264) удалось получить.

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