Аналог PGP с обеспечением отрицаемости и наперёд заданной секретности оффлайн?
Обсуждение в соседней теме натолкнуло на мысль: существует ли решение, аналогичное PGP и обеспечивающее для оффлайн-сообщений конфиденциальность и аутентификацию, но плюс отрицаемость и наперед заданную секретность (PFS), ну, и, желательно, тихое уведомление о прессинге. Нашел похожий вопрос на crypto.stackexchange: похоже, что готовых решений пока нет. Возможно, где-то на pgpru это уже обсуждалось, или что-то уже появилось?
комментариев: 393 документов: 4 редакций: 0
Именно. Вот поэтому я и поднял вопрос о данных, хранимых между сеансами. В моем варианте просто данных меньше (в ущерб стойкости?), поэтому легче оценить.
Еще надо бы просмотреть не только в плане отрицаемости, но и в плане возможности получения предыдущего ключа и расшифровки дампа (как на стороне отправителя, так и получателя; пока без навешенного костыля в виде KDF).
комментариев: 9796 документов: 488 редакций: 5664
Во первых, стираются Xi-1 и Yi-1, в текущем раунде есть только Xi и Yi, выведенные в т.ч. и с их помощью. Из под текущих Sid предыдущие параметры тоже нельзя узнать. Наконец, секретные DH-параметры ai-1 и bi-1 с предыдущего раунда тоже стёрты. Т.е. si-1 и s'i-1 выводить после завершения того раунда уже не из чего.
Единственно, что незавершённый раунд даёт окно безопасности на два сообщения. М.б., если приделать к этому две пары DH с каждой стороны и ratcheting, как в Axolotl, то что-нибудь и получится. Но пока, можно остановиться на этом варианте и считать раунд с безопасным окном в два сообщения — приемлемым. Хотя это не снимает проблему подтверждения аутентификации при захвате параметров, как внутри раунда, так и при последующем раунде при поступлении новых сообщений с другой стороны.
комментариев: 393 документов: 4 редакций: 0
Хм, у Вас в этом плане ситауция даже лучше, чем у Axolotl: инициатор хранит раундовый приватный ключ с момента отправки запроса до момента получения ответа, а ответчик вообще не хранит. Доверие передается через отрицаемые Sid-ы, защищенные R.
Только вот асимметрично получается, как-то не изящно смотрится. Может, потом будет смысл подумать на счет спаривания типа 01, 12, 23...
И еще: я уже задавал этот вопрос, но так до конца и не понял мотивацию: какой смысл прятать вводимый Xn под MDC SE? Ведь это публичный параметр, может быть передан и открыто. А MDC лишний раз связывает его с Message. Хотя, конечно, в вашем варианте с перманентной PKE-оберткой это же все равно делает MDC PKE.
Боюсь, что это априори недостижимо: при захвате злоумышленник становится эквивалентен получателю, а последний по определению должен уметь проверить аутентификацию.
комментариев: 9796 документов: 488 редакций: 5664
Другой вариант: раз инициатор менее защищён — он считает половинчатый Sid, а отправитель может посчитать и полный. Поскольку в аутентификации следующего раунда будут использованы оба Sid'a, то это даст отрицаемое связывание по параметрам ообеих сторон предыдущего сеанса.
комментариев: 393 документов: 4 редакций: 0
Я вообще не пойму, зачем в Sid включать параметры ответной стороны – это ведь мой Sid. Хотя, действительно, с ходу оценить последствия такого решения трудно.
Брр, жуткая асимметрия... У Эркюля Пуарро усы бы бубликом от такого подхода свернулись.
комментариев: 9796 документов: 488 редакций: 5664
А для передачи отрицаемой аутентификации на следующий раунд достаточно двух половинчатых, но взаимодополняющих Sid.
комментариев: 393 документов: 4 редакций: 0
комментариев: 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. Тогда он всё равно не сможет взломать записанную переписку если у него не записаны сообщения нулевого раунда.
комментариев: 393 документов: 4 редакций: 0
комментариев: 9796 документов: 488 редакций: 5664
Никак не связывает, если противнику неизвестен совместно выведенный ключ s.
С учётом текущих упрощений V.0.023.
комментариев: 393 документов: 4 редакций: 0
V.
Все таки решили оставить в выведении Sid параметры противоположной стороны от предыдущего раунда (Id / Sid i-1 и Xi-1) ?
Убедили. Случай единичного брутфорса пока не принимаем во внимание.
комментариев: 9796 документов: 488 редакций: 5664
С нулевым раундом — точно да, иначе как протянуть доверие от первой аутентификации?
А вот в последующих — есть смысл подумать, может оставить только
SidBi+1 = MACs'i (RB, Yi+1);
SidAi+1 = MACs'i (RA, Xi+1).
Судя по приведённой вами работе итальянцев, такие протоколы создавать-то несложно: они все дают слабую наперёд заданную отрицаемость. Они беззащитны в сценарии, если Боб отрицает переписку с Алисой, но Алиса является злонамеренной и сохраняет все s и прочие параметры, чтобы затем передать их стороне, которая знает параметры Боба, чтобы та убедилась, что Message, полученные Бобом, действительно исходили от Алисы. Более того, сторона, перехватывающая письма Боба, но захватившая его закрытый ключ, сможет расшифровать и прочесть все сообщения, которые он у себя удалил после расшифровки, если Алиса злонамеренно сохраняла все параметры сеансов, чтобы подставить Боба.
комментариев: 393 документов: 4 редакций: 0
У них весьма строгая модель, требующая дополнительного шага в протоколе (коммитмента). Я разбирал их DDH-вариант, стр.29 (хотя остальные тоже интересны), примеряя к нашей задаче. На С я это закодирую, но скриптом – вряд-ли (там нужна элементарная математика над группой, я сам добавлял нужные функции в ядро библиотеки подписи DH25519, немного разобравшись с уже имеющимися функциями).
NIDA на основе сочетания подписи Шнорра и шифрования Эль-Гамаля, ссылку на который я уже приводил когда-то), позволяющие одновременно отрицаемо аутентифицировать и отправителя, и само сообщение (в нашем случае – вводимый ключ), но у них проблемы с безопасностью, и это уж совсем модерн.
Еще есть однопроходные отрицаемые аутентификаторы (например,
PS: вот, кстати, еще одно простое китайское
решение с обычной DH.
Понятно, что в такой ситауции Алиса сможет показать третьей стороне, что она может создать сообщение, которое можно расшифровать имеющимися у Боба ключами (т.е. что она с ним в контакте). Но вот сможет ли она связать предыдущие сообщения с тем, что изъято у Боба (его секретным PGP-ключом и хранимыми параметры текущего сеанса)? Наверное, нет: Алиса не может убедить третью сторону, что отсылала первый запрос Бобу, а не себе самой, и что получила ответ именно от него. Завтра еще подумаю на свежую голову: ваша перманентная обертка может вызывать непредсказуемые эффекты.
комментариев: 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 для предъявления в следующем раунде, как вы приводили в примерах и др.
А протоколы с более стойкой отрицаемостью пытаются вывести на основе какой-то малопонятной экзотики и там всё более шатко — и с определениями, и с доказателсьтвами. Вот так, основательно покопавшись в теме, косвенно и можно понять, почему она не взлетает, хотя количество работ по такому узкому вопросу реально огромно.
комментариев: 393 документов: 4 редакций: 0
К слову: из
работы Крачика (стр. 4, 3-й абзац):
И тут же сноска:
Так что с Вами нельзя не согласиться. Как я уже говорил, отрицаемость в таком рафинированном виде может быть интересна нам с Вами, но никак не той аудитории, которой она действительно нужна. Наверное, PFS и надежность аутентификации куда важнее, и лучше концентрироваться именно на ней. Например, критика OTR за публикацию использованных MAC-ключей (концепция: "после проверки MAС получателем любой, знающий содержание сообщения, может его изменить (CTR-mode) и снова аутентифицировать"). Звучит интересно, но на практике еще никому не понадобилось.
PS: если Вас не затруднит, ткните меня в какую-нибудь подходящую LaTeX-заготовку, на досуге перепишу доку на OnionPhone к альфа-релизу.
По ходу реализовал еще одну идею в коде OnionPhone: возможность проброса выбранного UDP-порта через TCP-Tor. Попробовал с VLC-потоковой трансляцией: даже сносную картинку (на низком фрейм-рейте с H264) удалось получить.