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

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


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



 
На страницу: 1, ... , 10, 11, 12, 13, 14, ... , 20 След.
Комментарии
— gegel (20/08/2014 12:22)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
это же {Kn-16 … Kn-1}

Ну, уж последний документ старался писать для домохозяек.
а как делать по-нормальному — сто раз было сказано. Какая-то помесь из самых жутких стандартов
Я и сам ситуацию адекватно понимаю, так что все говорите прямо :) Но даже от автора к автору в серьезных работах стандарты бывают совсем разные. У меня их, по видимому, совсем нет. Но когда я впервые читал описание OTR, а затем описание Axolotl, то в душе возмущался не меньше вашего. На самом деле, протокол не такой и сложный, и разбирать алгоритм там особо и нечего. Другое дело – криптографические тонкости, но до этого дело пока не дошло.

Вобщем, с формой все понятно и лучше пока не будет: и так ушла масса времени на это. А что касается сути, то пока еще надеюсь на конструктивные замечания. Но если нет – то нет :(
— unknown (20/08/2014 21:04, исправлен 22/08/2014 09:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Ну, по-крайней мере, если вы считаете, что лучше по минимуму светить айдишниками под чистым PKE и запрятать их от греха подальше, чтобы затем методом перебора подбирать все входящие сообщения под свою секретную половинку, то под влиянием вашей идеи (хотелось бы доказать, что это не перестраховка), я предлагаю и свой модифицированный протокол, где получатель подбирает свои ранее использованные параметры для вычисления правильного s и пытаясь подобрать связанные с ними id получателя.


X = g, p, ga mod p
Y = g, p, gb mod p
s = KDF ( ga )b mod p = KDF ( gb )a mod p
s' = KDF (s)


A → B: MDC_PKEB (idA, X)
B → A: MDC_PKEA (Y, HMACs (idB, idA, X, Y))
A → B: MDC_PKEB (MDC_SEs' (Message), HMACs (idA, idB, Y, X, Message))


Вариант с непрерывной перепиской и пересогласованием (возможны дальнейшие варианты и исправления):

Round for s=0


A → B: MDC_PKEB (idA, X0)
B → A: MDC_PKEA (Y0, HMACs_0 (idB, idA, X0, Y0))
A → B: MDC_PKEB (MDC_SEs'_0 (Message), MDC_SEs_0 (X1), HMACs_0 (idA, idB, Y0, X0, X1, Message))


Round for s=1


B → A: MDC_PKEA (Y1, MDC_SEs'_1 (Message), MDC_SEs_1 (Y2), HMACs_1 (idB, idA, X1, Y1, Y2, Message))
A → B: MDC_PKEB (MDC_SEs'_1 (Message), MDC_SEs_1 (X2), HMACs_1 (idA, idB, Y1, X1, X2, Message))


Round for s=2


B → A: MDC_PKEA (Y2, MDC_SEs'_2 (Message), MDC_SEs_2 (Y3), HMACs_2 (idB, idA, X2, Y2, Y3, Message))
A → B: MDC_PKEB (MDC_SEs'_2 (Message), MDC_SEs_2 (X3), HMACs_2 (idA, idB, Y2, X2, X3, Message))


Round for s=i


B → A: MDC_PKEA (Yi, MDC_SEs'_i (Message), MDC_SEs_i (Yi+1), HMACs_i (idB, idA, Xi, Yi, Yi+1, Message))
A → B: MDC_PKEB (MDC_SEs'_i (Message), MDC_SEs_i (Xi+1), HMACs_i (idA, idB, Yi, Xi, Xi+1, Message))



и т.д.


Знака "║" для конкатенации (неформатированного объединения встык) я избегаю, полагая, что поля для параметров могут быть специально форматированными. У Кравчика принято обозначать также. Но, естественно, операция расположения параметров в функциях — некоммутативна: от порядка следования символов, разделённых запятыми, результат меняется.



Проблема даже не в этом. Понятно, что это черновик. Понятно, что там и откуда, мы это долго обсуждали. Понятно, что оформление — дело наживное.


Проблема в том, что вы излагаете идеи не для домохозяек, но и не для криптографов. А как будто для тупо кодеров. Бывает такая форма стандартов, при этом достаточно кривых. Их цель – чтобы самые тупые кодеры по пунктам поняли, что надо закодить, а возможные ошибки нашли по тестовым примерам. Но такие стандарты не рассчитаны, что кто-то будет анализировать идею, которая там заложена. Т.е., по форме — это инструкция к реализации без удобства обсуждения теоретической части.

— Гость (20/08/2014 23:10)   <#>

Домохозяйки не будут это читать. :-)


Очень точно подмечено. Так и хочется написать эссе «как бы выглядели программы, если б математики их писали так же, как прогеры пишут матаналитику». Типа нафиг нам отступы — и так всё понятно, на интерпретацию программы это не влияет. Зачем ставить лишние пробелы? И так же разобрать можно. Зачем давать осмысленные имена переменным? Это только делает код длиннее, поэтому давать всё именовать как a1...a999. Зачем бить код на модули и функции? Давайте писать всё вместе, чтоб сразу было всё на месте, а где надо, нарисуем стерлки поставим goto. Зачем писать комментарии? Комментарии к коду — сам код; кому надо, тот разберётся. И т.д.

Unknown, а зачем вы выделяете формулы жирным шрифтом? Без него вам плохо видно или плохо воспринимается?
— gegel (20/08/2014 23:54, исправлен 21/08/2014 00:10)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
А как будто для тупо кодеров.

Вот тут согласен на 100%. Как для себя писал :) Когда поздно ночью пытаешься переложить какой-то протокол (например, тот же китайский NIDA выше по теме) на рабочий С-код, то именно так и хочется видеть описание. Одновременно анализировать и кодить нереально хоть тупо-кодеру, хоть и не-тупо.


поставим goto

читал топик про ФП и с трудом удержался от коммента: мазохизм ради идеи. Когда я считаю оптимальным использовать goto, я его используя, не взирая на "гласные и негласные стандарты". Это в продолжение темы: корячимся, делая черновики в LaTeX, первично отлаживая код в GCC, работая в Linux-консоли... Я не готов отказаться от благ цивилизации ради идеи. И не одинок: китайцы делают embedded-разработки в основном в средах под Windows, сопроводительный софт – на моем любимом Borland C++Buider 6.0 (вытягивая мышей компоненты), документацию – в Word. Причем очень быстро и эффективно. А у нас ракеты не летают почему-то...


я предлагаю и свой модифицированный протокол

Да, он бронирован, как танк.


В вашем примере непонятно, из каких DH-ключей выводятся sn (что с чем паруется).


Я так понял, что s' выводится из того же секрета, что и s?


И чем обусловлено решение передавать ключ отдельным MDC_SE? Отрицаемостью?


PS: во второе сообщение (B->A) я все же включил IDB и вне хеша из соображений удобства релизации: получатель должен подобрать подходящий файл. Если ID не указан в сообщении явно, то он должен храниться в этом файле на диске. Мне показалось безопаснее включать свой ID в ответ под PKE, чем хранить чужой ID у себя в файле контакта. Лучше оставить файл контакта анонимным, не привязанным к конкретному ID.


Может, есть смысл сделать первичные запрос и ответ неразличимыми? Тогда при утечке PGP невозможно будет определить, кто инициатор.


Не хотите добавить мастер-ключи и хеширование, как в Axolotl или в предложенном мною варианте? Отличная идея, модификация из Циммермановского SilentCircle, позволяет создавать управляемое ключевое окно и разруливать нарушения последовательности и потери ( см. advanced-ratcheting )

— Гость (21/08/2014 01:29)   <#>

Тут некоторые люди даже свои кустарные шифры предлагали анализировать по их C-коду, а не описанию. Напомнило фразу «хороший экспериментатор думает в терминах происходящей физики, плохой — в терминах показаний приборов, хороший теоретик думает в терминах смысла производимых действий, плохой — в терминах матвыкладок "я подставил это туда, и у меня получилось"». Здесь так же.


Если вы всю жизнь забивали гвозди оконным интерфейсом микроскопом, а потом вам дали в руки командную строку с автодополнением молоток и объяснили его преимущества, вам тоже будет неудобно. Переучиваться всегда тяжелее, чем учиться сразу правильно с нуля. Особенно C++ веселит: http://yosefk.com/c++fqa/picture.html.


будет наверное такое же количество весёлых публикаций и бесcмысленных исследований как у индусов и китайцев. Надо же рост и развитие будет показывать, раз у граждан такая наркотическая зависимость от пропаганды гордости за державу. У китайцев и индусов тоже видимо, как у всех больших интенсивно развивающихся стран с амбициями. А реальный результат будет очень маленький. По крайней мере на первое время.
— unknown (21/08/2014 11:26, исправлен 21/08/2014 12:57)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Изначально обычным шрифтом была выделена часть протокола, относящаяся к вычислению DH и вычислениям «на месте», а передаваемые далее параметры были выделены жирным шрифтом.


Сейчас исправлено по другому принципу: вычисления DH и «на месте» остались вынесенными в начало протокола, а жирным шрифтом выделены названия функций в формулах, названия шагов и заголовки.



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



В каждом раунде i генерятся секретные параметры ai, bi и соответствующие им открытые Xi, Yi. Ключ si выводится для параметров с одинаковым i. Поэтому, кроме нулевого раунда, совместно выведенный si используется для передачи симметрично шифрованных сообщений дважды, в одну и в другую сторону. А параметры для si+1 (для следующего сеанса связи) передаются также в текущем сеансе, при этом остаются связанными с текущими параметрами: если в текущем сеансе выявлено, что согласование прошло неверно, то и следующий сеанс согласовать не удасться.



Да, как вторая производная через KDF, чтобы s для шифрования следующей половинки DH и s' для шифрования собственно сообщения не были одинаковыми.



Это сделано только для одной стороны, так что отрицаемость от этого зависит слабо. Это позволяет сделать несколько вещей:


Только сторона, знающая текущий правильно согласованный si, может расшифровать новую половину ключа и тем самым проверить значение HMACs_i, в которое также включена половина нового ключа вместе со старыми. За счёт такого дополнительно связывания сторонам легко убедиться, что никто не вклинивается с момента первоначального установления контакта, не передавая при этом больше своих id в открытом виде.



Пусть все перебирает.



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


Если сторона захватила секретный PKE-ключ стороны B (SKB) и при этом записала всю переписку, она всё равно может расшифровать только параметры idA, а расшифровав ещё и все Xi и Yi, она не сможет подобрать idB, поскольку не может по ним вычислить s, так что она не проверит HMAC и не расшифрует SE-переписку. Но ведь она и так знает, что украла ключ стороны B с idB и взяла переписку с неё.


А если она украдёт ключ стороны A, то без дополнительных сведений, она не узнает, с кем связывалась сторона A. Если используется анонимный канал связи, то инициатор не скрываем при захвате секретного PKE-ключа отвечающего, а вот при захвате секретного PKE-ключа инициатора, отвечающий остаётся скрытым. Т.е. наблюдается скрытность отвечающего в рамках PFS. Как добиться такого и для инициатора — не знаю. Разве что договориться о секретном позывном вместо id в нулевом раунде, но это аналог совместного секретного ключа, который знают обе стороны.


При этом, отрицаемость сохраняется, если не путать её с нераскрываемостью в рамках PFS: любая из сторон может утверждать, что эти сообщения сфальсифицированы и/или подброшены, так как никто из сторон их не подписывал.



Посмотрю ещё. Пока надо этот минимум довести до ума, и так уже с самого примитивного уровня много накручивается по необходимости.


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


Или это будет просто шифрпанковская поделка с китайским колоритом, которая просто как-то работает, радуя покупателей пользователей (и их противников). Ведь сами пользователи проверить качество безопасности не смогут, в отличие от качества обычных товаров. Так что, китайский эмпирический подход здесь не годится.


P.S. Аутентификацию расшифрованного Message внёс ещё и под MAC. Теперь можно меньше доверять стойкости реализации функции MDC в GnuPG (или даже вовсе от неё отказаться, хотя карман не тянет, она всё равно по умолчанию используется), а опираться на стойкую аутентификацию по совместно выведенному симметричному ключу в HMAC. MDC, похоже остаётся критичным только в первых двух шагах с PKE и тольео в нулевом раунде.


P.S.S. С Keccak-Sponge (рис.4, 5) всё выглядело бы намного проще — один нешифруемый параметр Yi передаём в открытую, всё остальное в скобки без повторений и результат MAC от хвоста шифрования.

— gegel (21/08/2014 13:43, исправлен 21/08/2014 14:00)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Ключ si выводится для параметров с одинаковым i.
совместно выведенный si используется для передачи симметрично шифрованных сообщений дважды, в одну и в другую сторону.

Ясно. Дважды – не совсем хорошо в теории. Логика OTR и Axolotl другая: допустим, А вводит ключи a, c, ...
В вводит b, d... Секреты парятся как ab, bc, cd... по одному в каждую сторону. В вашем примере: ab, cd в обе стороны каждый. Но, возможно, в этом есть и преимущества, надо подумать.


в которое также включена половина нового ключа вместе со старыми.

Еще один оригинальный вариант передачи доверия от обмена к обмену (другие – подмешивание части предыдущего секрета в новый в Axolotl, и предложенный мною: выводить очередной секрет из двух DH: предыдущей и текущей). Идея хорошая.


Пусть все перебирает.

В любом случае все перебирает. Но вы абстрагируетесь от реализации: ведь предполагается, что файлы контактов псевдонимны (они не содержат ИД) И где мне, открыв очередной файл, брать ИД, чтобы проверить MAC? Вариантов два: или отправитель дополнительно включает свой ИД в свое сообщение вне хеша, или я храню чужие ИДы в файлах контактов (тогда файлы становятся "именные"). Меньшим злом мне показался первый вариант.


Если у него утечёт его секретный ключ, то будет понятно, что он с кем-то переписывался и был инициатором.
Тоже справедливо и для ответчика: если утечёт его секретный ключ, то будет ясно, что он кому-то отвечал.

Вот я и предлагаю добавлять ID во второе сообщение и рандом вместо MAC в первое, чтобы невозможно было по длине и содержимому (кроме ИД, остальные данные выглядят как рандом) отличить сообщения A->B от B->A в случае утечки PGP.


Аутентификацию расшифрованного Message внёс ещё и под MAC.

Это разумно, сам хотел предложить это сделать.


PS: и еще вот что приходит на ум. Задачей аутентифицированного IKE является однозначно связать вводимые эфемеральные ключи со своими ИД. Таки образом, эти ключи становятся псевдонимами ИД для участников и могут быть использованы вместо ИД в следующих обменах. Может, есть смысл оставить ИД только в первичном сеансе, а затем использовать ключи предыдущих сеансов вместо ИДов под МАС? Это существенно облегчит реализацию и избавит от необходимости делать файлы контактов "именными", храня в них ИДы. При захвате компьютера может весьма помочь выкрутиться.


PPS: Все же найдите время вникнуть в реализацию Axolotl (если нет желания возится с каракулями его варинта в моем исполнении). Мокси и Тревп – таки гениальные ребята, и из их протокола можно взять оригинальные идеи, которые, в сочетании с армированностью вашего протокола смотрелись бы замечательно.

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

Хорошо, в нулевом раунде можно обменяться ID в открытую, забив HMAC рэндомом. А в последующих раундах включать в Message, которое шифровано симметричным ключом: «Алиса — Бобу», «Юстас — Алексу» и т.д. Вообще, подразумевается, раз Алиса помнит куда писать Бобу, то она помнит или у неё где-то хранится его id — отпечаток PGP-ключа, например. Вообще, айдишники, также как и секретные параметры DH хранятся на диске в зашифрованном паролем виде (как, впрочем и закрытые ключи). Если у какой-то из сторон перехватят закрытый ключ и пароль к нему, то из-за PFS не смогут разве что прочесть ранее переданные сообщения. Но вытащить список предполагаемых адресатов из компьютера всяко смогут. Это ведь не относится к отрицаемости?

— gegel (21/08/2014 15:41)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
забив HMAC рэндомом.
Нет-нет, ни в коем случае! Я вот что имел в виду:
A → B: MDC_PKEB (idA, X, R) R-рандом по длине совпадающий с HMAC.
B → A: MDC_PKEA (idB, Y, HMACs (idA, idB, X, Y))
Исключать idB из-под HMAC нельзя, Вы сами на это указали. Иначе возможна UKS: А соглсовывает ключ с E (при активном сочувствии B), будучи уверенной, что делает это с B. А далее – как на слайде Кравчика с F19.

Если у него утечёт его секретный ключ, то будет понятно, что он с кем-то переписывался и был инициатором.
Тоже справедливо и для ответчика: если утечёт его секретный ключ, то будет ясно, что он кому-то отвечал.

Не прошло и пары часов, как до меня дошла Ваша мысль: действительно, злоумышленник, записывающий трафик на стороне участника, позже при утечке PGP, в любом случае может определить роль участника по направлению сообщения.
А злоумышленник, перехвативший сообщение где-то по средине анонимного транспорта, все равно не знает, чей ключ ему нужен для дешифровки. Так что смысла вводить R для неотличимости запроса от ответа особо и нет.
— gegel (21/08/2014 19:20)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Вообще, айдишники, также как и секретные параметры DH хранятся на диске в зашифрованном паролем виде (как, впрочем и закрытые ключи).


Не проще ли будет сделать так, чтобы программа/скрипт изначально хранили все (включая саму себя) в TrueCrypt?

Но вытащить список предполагаемых адресатов из компьютера всяко смогут


Список то смогут вытащить, другое дело, что в нем будет указано: он может быть псевдонимный и не содержать реальных ID. То же касается и адресов: это могут быть специально заведенные онион-адреса. Ведь вся затея с динамическими псевдорандомными идентификаторами и поиском по файлам и состоит в том, чтобы нигде не светить ИД долговременных ключей в процессе переписки после IKE.
— Гость (22/08/2014 01:54)   <#>

Да, так смотрится намного лучше. Вам на заметку: названия шагов и прочего, чтоб они не сливались с основным текстом, можно писать как заголовки 5-го ранга:

Round for s=0


Разметка:
=====Round for //s//=0=====
— unknown (22/08/2014 10:56)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Спасибо за совет. Поправил.


Дисковое шифрование крайне желательно, но оно опционально и не решает всех проблем. Когда-то, в начале использования PGP, дискового шифрования практически ни у кого не было. Тогда и решили: закрытый ключ хранить на диске только в зашифрованном паролем виде, а расшифровывать только временно в память, когда нужно пользователю — для расшифрования сообщений, подписи, изменения самого ключа и пр. Понятно, что такое не прокатывает на серверах, где живого пользователя нет. Но на рабочей станции такую годами сложившуюся практику лучше оставить. Например, у противника есть эксплойт, который может прочитать файл с диска и он утаскивает закрытый ключ. Но нет более редкого эксплойта, чтобы выполнить произвольный код или как-то иначе подсадить троян, чтобы перехватить пароль для его расшифровки. Поэтому в GnuPG все секретные ключи шифруются. Разумно также и шифровать все временные секретные параметры DH с id и только в таком виде писать на диск.


Здесь возникает масса соображений. Как мелких, так и принципиальных. Постараюсь привести по-возможности их все.

Стороны всё равно светят в переписке хотя бы один id. Если перехвачено начало переписки и перехвачен секретный ключ получателя вместе с паролем для его использования, то этот id всё равно будет извлечён. Конечно, внутри переписки, стороны могут договориться поменять id на клички-позывные. Могут даже попросить друг друга сменить адреса или выслать отпечатки новых ключей. Но здесь теряется доверие, возникает опасность навязывания контакта с третьей стороной.

Наконец, принципиальный момент. Есть вещи, которые надо явно обговорить, а затем формализовать.

Что у нас есть и формализовано:

  1. Perfect Forward Secrecy. Треться сторона, имеющая запись всей переписки в шифрованном виде, захватившая закрытый ключ любой из сторон A или B и пароль на доступ к нему, не сможет расшифровать ранее переданные между ними сообщения из-за постоянного DH-пересогласования и удаления временного ключевого материала.
  2. Deniability. Отрицаемость. Сторона A или B не может опубликовать переписку публично или для некоей отдельной третьей стороны так, чтобы формально убедить всех (или выбранную третью сторону) в её подлинности. Это так, потому что на сообщениях сторон не будет подписей. Значит сами стороны, или любой сомневающийся может утверждать, что переписка искажена, полностью выдумана или даже, что никакого контакта вообще никогда не было.

Теперь замечание о неполноте отрицаемости. Отрицаемость не работает, если третья сторона сама захватывает или взламывает сторону A или B с предварительно перехваченной шифрованной перепиской, частично неудалёнными последними секретными параметрами согласования, id, ключами и паролями от них. Такому противнику доказательства не нужны: он всё видит как свидетель и доверяет буквально своим глазам, хотя собранный им материал может быть и недоказателен для посторонних, которые подозревают его в фальсификации. Он не может прочитать ранее удалённые расшифрованные сообщения, но увидит id и узнает, кто с кем переписывался.

Вы предлагаете ввести в протокол защиту и от такого сильного противника. Но для этого протокол должен обладать неким свойством, не попадающим в два вышеприведённых. Они не обеспечивают решения требуемой задачи. Нужно задать и формально описать некое третье свойство, например Perfect Forward Anonymity (Pseudonymity). Но мне о протоколах с таким свойством ничего неизвестно. Более того, даже толком не сформулировав это свойство, не стоит ради приближения к нему вносить изменения в консервативно достигнутую защиту, обеспечивающую два основных свойства. А то может получиться, что и неясное третье свойство достигнуто не будет, и какое-то из двух предыдущих поломается (за счёт открытия противнику путей вмешателсьтва во взаимную аутентификацию, например).

Ну и ещё раз по практическим соображениям. Для шифрования и нераскрываемой для третьей стороны аутентификации используются OpenPGP-ключи. И ключи всех, с кем вы теоретически могли бы переписываться, будут висеть у вас на связке. Это как книга ваших возможных контактов. Если противник может добраться до компьютера и расшифровать все данные, то он может установить потенциальные контакты. Разве что, вынести все открытые ключи и контакты с id в шифрованном виде на какой-нибудь onion, а на своём компьютере хранить только свой закрытый ключ.

id нужны для того, чтобы стороны точно знали кто отправляет сообщение кому и за счёт этого не было вмешательства в аутентификацию. Конечно, можно вместо прямых id ввести какие-то rolling id, т.е. псевдослучайные значения, завязанные на секрет от предыдущего согласования. Axolotl что-то похожее и пытается сделать, использовав две пары DH-согласования ключей для получения двух различных s в одну и в другую сторону, а заодно и решения вопроса, кто и кому отправляет сообщения. Но у нас всё завязано на OpenPGP. И если аутентификация собъётся, то стороны могут откатиться к исходному ключу OpenPGP и начать всё с нулевого раунда. А для этого надо помнить id-ключей и передавать, по крайней мере в первом запросе, именно их.

Ещё в Axolotl есть KDF от текущего ключа вместо пересогласования по DH. Это, чтобы задать окно безопасности на несколько сообщений, отправляемых за короткое время, чтобы не ждать ответа от другой стороны и самому создавать новые s в одностороннем порядке, так чтобы другая сторона могла вопроизвести этот процесс. Это такой суррогат PFS при помощи средств только симметричной криптографии, удобный для короткого временного применения, его и к предложенному мной протоколу прикрутить несложно.

А вот над остальным надо думать, но есть масса сомнений в безопасности внедрения таких дополнительных фич.
— gegel (22/08/2014 21:01, исправлен 22/08/2014 22:55)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Сторона A или B не может опубликовать переписку публично или для некоей отдельной третьей стороны так, чтобы формально убедить всех (или выбранную третью сторону) в её подлинности.

Это расслабленное определение отрицаемости, оно касается лишь содержимого переписки. Полная отрицаемомть дает возможность отрицать факт участия в переписке.
В данном протоколе хотелось бы достичь отрицаемой аутентификации (формальное определение есть fileтут, 2.1). Я частично ориентировался на fileсценарий 2 (стр.1), предложенный Raimondo и Gennaro (одна из их работ fileтут). Там вводится понятие forward deniability (созвучное с вашей Perfect Forward Anonymity). В fileдругой работе поддается сомнению возможность достижения сильной отрицаемости и вводится свое расслабленное понятие peer_and_time deniability (раздел 4).
PS: вот еще fileработа Кравчика с общей формализацией понятия отрицаемости и анализом SKEME и SIGMA


Отрицаемость не работает, если третья сторона сама захватывает или взламывает Такому противнику доказательства не нужны

По вышеприведенному сценарию она должна работать. Но не путайте роль информанта и судьи (по первой ссылке).


Но вся эта отрицаемотсь интересна нам с вами, но вряд-ли – практикующим террористам/педофилам/наркодиллерам: их все равно будут бить не по паспорту. Поэтому я исходил в основном из практических соображений, оценивая возможные последствия от вполне реальной ситуации: захвата компьютера одного из участников уже после аутентификации, в процессе переписки (при этом второй участник не является информатором, иначе об отрицаемости речь не идет). В этом случае считаем, что все пароли будут выданы под давлением, поэтому толку от обычного шифрования приватной информации никакого. Другое дело – скрытые TrueCrypt контейнеры, я бы предпочел их в любом случае.


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

Самое первое, что сделает даже участковый – посмотрит вашу телефонную книгу. Ценное свойство Axolotl – скрыть реальные ID, заменив их псевдонимами (причем постоянно меняющимися в процессе переписки), надежными для сторон так же, как и ИД, но выглядящими рандомно для злоумышленника, получившего доступ к компьютеру и слушающего переписку до этого. Если аутентификации сбивается, то можно рискнуть начать с начала (момент выполнения IKE – уязвим для отрицаемости факта контакта), но опять же, удалив PGP-ключи контакта после согласования. Именно поэтому я и не хотел перманентно заворачивать все сообщения в PGP.


Ещё в Axolotl есть KDF от текущего ключа вместо пересогласования по DH. Это, чтобы задать окно безопасности на несколько сообщений

И еще буфер для хранения неиспользованных ключей (несколько выведенных наперед (KDF) со старого в момент согласования нового, а также пропущенные при последовательных KDF). Это и есть та фишка, которая делает возможным переписку по email: опоздавшие сообщения читаются в определенном регулируемом окне. Т.е. адаптация OTR к условиям почты (обсуждалось в начале темы).

— unknown (23/08/2014 13:22)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Введём понятие Synthetic Pseudo Random Forward Deniable ID. Слово "synthetic" здесь не лишнее, так как означает вывод псевдослучайного параметра из определённых параметров сеанса и это слово из распространённой терминологии. Пусть те параметры раунда (Round Parameters), которые у нас идут под HMAC, обозначаются как RP.

Тогда, каждая сторона на этапе своей отправки вычисляет и сохраняет для следующего раунда SPRFDIDi+1 = KDF (HMACs (RPi)). Это же она делает для противоположной стороны, на основании данных, полученных на шаге приёма.

Пусть все шаги нулевого раунда остаются такими же, как есть. Инициатор Алиса всё равно должна один раз послать свой id в открытую. Хотя Боб уже со второго шага нулевого раунда может заменить свой id на синтетический, ему это не нужно — если Алиса заинтересована в удалении секретных DH-параметров также,как и Боб, то не зная s, idB под HMAC подобрать невозможно. Зато, на первом раунде стороны переходят на SPRFDIDA_1 и SPRFDIDB_1, вычисленным по результатам предыдущего раунда.

Получается, что связь между всеми параметрами раунда и даже отправленными сообщениями переходит на параметры DH для следующего раунда и на синтетические ID. Эта связь заверяет DH и ID, но делает ID отрицаемыми — ведь предыдущие s и необходимые для его вывода параметры предыдущих раундов уничтожаются. Сами сообщения при этом, в принципе можно сохранять, если они чем-то ценны.

В таком виде стороны конечно могут после согласования заменить регулярные PKE-ключи на более анонимные, чтобы после провала, раскрытие ключей не показывало их привязки к кому-либо. Концепция SPRFDID будет отрицаемо для противника тянуть на себе всю аутентификацию, с самого начала (нулевого раунда). Но это не устраняет опасности атаки втёршегося в доверие переотправщика. Так что, сторонам следует делать выбор: рисковать хранением публичных ключей друг друга на связке или поменять ключи и рискнуть столкнуться с определённым вариантом злонамеренного поведения одной из сторон. В принципе, SPRFDID уменьшает эту вероятность — если сторона A уже списывалась с E, она будет хранить SPRFDID с предыдущего сеанса, если не списывалась — она спросит у злонамеренной стороны B, почему та делает перезапрос SPRFDID. Хотя строгой защиты от переотправки при полной отвязке ключей это не даёт. Только позволяет заподозрить неладное, на что злонамеренная сторона всегда способна выдать правдободные оправдания. Отрицаемость — это штука обоюдоострая.

Совет на будущее. Не пишите везде H как хэш, если результат не идёт о самой низкоуровневой детализации протокола. Потому что (H)MAC и KDF — это не просто тупо взять хэш. Это должны быть разные вещи и в теоретическом плане, и в плане реализации. В плане теории отличие MAC от KDF будет важно, если будет проводиться формальное доказательство стойкости протокола: будет виднее, что в каком виде заменять на PRF. В плане реализации: SHA-2 напрямую использовать нельзя, нужен HMAC и KDF отдельно. Причём, сам KDF может быть реализован через HMAC с определённым параметром вместо ключа, для вывода производного ключа произвольной длины, если нужно растянуть ключ меньшего размера до большего. При переходе на Keccak всё значительно упростится, но там тоже важно знать в каких режимах его использовать для MAC и KDF, какие режимы комбинировать, как подавать и снимать параметры.

KDF и MAC — это определённые устоявшиеся понятия, которые могут быть заменены разными практическими конструкциями, которые ранее исследованы теоретически. Когда вместо KDF и MAC везде тупо подставляют хэш, то про такое говорят poor-man-KDF, poor-man-MAC. Авторы Axolotl — похоже, poor man's в этом смысле.
— gegel (23/08/2014 14:04, исправлен 23/08/2014 15:00)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Концепция SPRFDID – Именно то, о чем я постоянно думал, но четко формализовано Вами.


Хотя Боб уже со второго шага нулевого раунда может заменить свой id на синтетический

После вашего замечания я тщательно анализировал варианты на предмет UKS: заменить может, но в параметры, с которых этот синтетический ИД будет выводиться, в нулевом раунде Боб должен обязательно включить свой рельный id.


Сами сообщения при этом, в принципе можно сохранять, если они чем-то ценны.

Одно время у меня была идея пойти еще дальше: полностью отделить DH-согласование для выведения ключей шифрования от параллельного DH-согласования для аутентификацииключей (передачи доверия по цепочке). Т.е. в каждое сообщение вкладываем по 2 DH-ключа и два MAC: одним заверяем ключи, как описано выше, вторым только аутентифицируем сообщение (этот МАС выводится с использованием того же секрета, что и ключ шифрования: полученного с помощью "чистой" DH). Получаем интересное свойство: любой может написать письмо получателю и аутентифицировать текст, но получатель (и только он) всегда сможет определить, действительно ли письмо от отправителя. Теперь можно отрицать наличие (или следы) сообщений на диске: да, я получил и прочитал сообщение (файл), думая, что оно от моей бабушки. Но оно оказалось недоверяемым, и его содержание отношения ко мне не имеет.


Потому что (H)MAC и KDF — это не просто тупо взять хэш.

Да, это я усвоил еше год назад по Вашему замечанию о выведении ключей с DH-секрета. "Исправление" SHA путем алгоритма HMAC тоже разобрал. Хотя не совсем почувствовал теоретическую разницу между HMAC и KDF (внешнее различие – произвольная длина выдачи в KDF и фиксированная в HMAC). Но после работы над библиотекой Keccak это как-то стерлось, что, конечно, в общем случае неверно.
Надо посмотреть, какую хеш-функцию ребята используют в Open WhisperSystems TextSecure: если, например, blake2, то их тоже можно понять.

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