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

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


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



 
На страницу: 1, ... , 14, 15, 16, 17, 18, ... , 20 След.
Комментарии
— unknown (29/08/2014 23:55, исправлен 30/08/2014 00:06)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Идёте на http://arxiv.org, смотрите работы. Например эту. Справа там предлагается скачать в PDF, Postscript и Other formats. Дополнительные форматы есть не у всех работ. Но если они есть, то среди них для многих работ есть и формат Source. В Source может быть tar.gz со всеми картинками, вставленными отдельными файлами и LaTeX (типа такого), может быть простой LaTeX или сжатый tex.gz.

— Гость (30/08/2014 05:03)   <#>

Хреновое заводское оформление. Вот тут хоть что-то для приличия подкрутили. Попадались работы ещё лучше оформленные, но лень искать.
— unknown (31/08/2014 22:13, исправлен 31/08/2014 22:20)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Поменял до v.0.024.


От R избавился, они были нужны для улучшения отрицаемости внутри раунда. Теперь отрицаемость и PFS внутри раунда достигается без R и при этом эффективнее.


При помощи KDF из текущего DH-секрета раунда для следующего раунда вычисляются два Sid, как и раньше. А вот симметричных ключей вычисляется четыре: одна пара — для шифрования и аутентификации в одну сторону, другая — соответственно в другую.


Теперь сторона B может отправить сообщение стороне A, вычислить Sid для следующего раунда и сразу же стереть свой симметричный ключ, получив отрицаемость (в принятом нами ограниченном понятии этого свойства) и PFS уже внутри раунда. Получатель A также может после расшифровки и проверки сообщения вычислить аналогичный Sid и сразу же удалять этот симметричный ключ текущего раунда.

— gegel (01/09/2014 11:10, исправлен 01/09/2014 11:17)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Поменял до v.0.024

Все выглядит идеально. Но сегодня утром я неожиданно увидел то же под другим углом. Наверное, это Вам не совсем понравится, но и тем не менее выскажу свои соображения хотя-бы в качестве альтернативы для сравнения.
Дело в том, что Вы рассматриваете каждый раунд как независимое ключевое согласование, аутентифицированное с помощью имеющихся от предыдущего раунда Sid-ов. Я представил то же иначе.
Допустим, после раунда n (в частном случае n=0) стороны выводят доверяемый общий секрет s. Это эквивалентно наличию у них пред-расшаренного секрета. В раунде n+1 стороны обмениваются сообщениями под симметричным шифрованием с MDC, используя имеющийся пред-расшаренный секрет. При этом аутентификация данных как бы и не нужна (эту функцию выполняет MDC). Вводимые ключи являются частью сообщений, и стороны им доверяют, как и остальному содержимому. Таким образом, из них можно сразу выводить секрет для следующего раунда, без никакого дополнительного подписывания параметров DH.
В итоге протокол редуцируется до смешного минимума:


Раунд 0 (IKE):


A→B: MDC PKEB (Id A, X 0)


B→A: MDC PKEA (Y 0, HMACs0 (Id B) )


Раунд n:


A→B: MDC SEsn-1 (Message, Xn)


B→A: MDC SEs'n-1 (Message, Yn)


Конечно, я мог на вскидку опустить что-то важное, но под описанным выше углом зрения вроде выглядит приемлемо.

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

Я тоже об этом думал. Но делал протокол уже так, как будто MDC ненадёжен, может быть взломан и его просто нет. Т.е. MDC — это просто довесок, перестраховка, которая раз есть в OpenPGP, то почему бы ей не воспользоваться. Сомнения по поводу MDC уже были ранее в теме, потому как это шифрпанковское внутреннее специфичное изобретение OpenPGP RFC4880 теоретически нигде не описанное и формально недоказанное. В самом RFC он описывается как готовое решение для отрицаемости и отказа от подписей, можете почитать.


Но если попытка создать очередной протокол, наподобие "Flat Spheroid" будет когда-то формализована, то его стойкость можно будет рассмотреть без MDC и провести сравнительный анализ с другими протоколами. Ваши идеи по заземлению протокола мне нравились и существенно повлияли на его текущую версию.


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


P.S.: Flat Spheroid v.0.025 в двух вариантах, готово.

— unknown (03/09/2014 17:41)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Подумалось, а зачем в сокращённой версии протокола вообще HMAC, даже в нулевом раунде, если везде полагаемся на MDC и специфические свойства HMAC вроде как не нужны?

Может там сделать:

B → A: MDC PKEB (Y0, MDC SEB→A (IdB, Y1))
— gegel (03/09/2014 20:06)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Да, действительно. Я сразу и не заметил такую возможность. Т.о. для реализации скриптом нужны только pow и KDF.
Еще вопрос: в раунде n обе стороны вводят ключи n+1 и соответственно выводят секреты n+1 (все симметрично). Но в раунде 0 только одна сторона вводит ключ 1. Таким образом, не совсем понятно происхождение секретов s1.
Может, попробовать перейти на "последовательное спаривание" (0-1, 1-2, 2-3) ключей в стиле OTR?
— unknown (03/09/2014 21:26)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Подправил этот вариант.

Помимо очень простой практичной реализации, это интересно с т.з. дальнейшего изучения MDC в плане его сводимости к т.н. non-malleability. Судя по описанию и полному отсутствию теоретических работ, MDC в GnuPG — это самопальный (в плане того, что разработчики GnuPG его взяли не из публикаций) non-malleable encryption mode. Возможно, что он даже стойкий, но имеет какие-то ограничения в плане своей полноценности. Помимо привязки к GnuPG есть смысл держать на рассмотрении такой вариант в случае замены MDC на более проверенный non-malleable mode.


Я как-то традиционно привык обозначать раунды через i от слова итерация, а не n — number. Это непринципиально, естественно. Но как-то чаще попадается, вот даже в Стрибог.

А по сути, верно замечено. Подразумевается, что в нулевом раунде стороны согласуют первый секрет и тут же одна сторона уже может его использовать. Но при этом получается, что в первом раунде (после нулевого) используется этот же совместно выведенный секрет и т.о. получается равентство ключей s0 = s1. Как бы, некритично, но лучше исправить. Дальше все раунды идут стандартно, последующие симметричные ключи выводятся один раз из общего секрета предыдущего раунда.

Частично исправил это недоразумение указанием номера раунда i в KDF. Так что, DH между нулевым и первым раундом остаётся общим, а s — гарантированно разные.


Если «последовательные спариватели» не удосужились разместить на своей wiki-странице вменяемые формулы к формальному описанию протокола, то придёться когда-то добраться до их протокола и сделать это за них. Хотя бы для себя. Иначе, не видя перед глазами чётко формализованной картины, не понять преимущества, недостатки и пути развития того или иного решения.

Вообще, времена, когда протоколы придумываются в почтовых рассылках — ужас. Это же не патч к коду, который не требует ничего специфического, читается и без подсветки. Можно кончено и LaTeX-подстрочник текстом постить, но это неудобно. В итоге, в рассылках посылают урезанные до простого текста формулы и их же потом вешают на сайт того же Axolotl. Была бы хоть pdf, как для OTR.

Текущая версия v.0.026.
— gegel (03/09/2014 22:20, исправлен 03/09/2014 22:31)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
вменяемые формулы к формальному описанию протокола

Кстати, я именно с описания OTR-протокола брал пример. Наверное, не лучший подход оказался. Более приемлемо раунды описаны в их fileпервой работе, стр.4.
Уязвимость этой версии касалась IKE и была исправлена позже, принцип "спаривания" остался тот же.


это самопальный ... non-malleable encryption mode.

Да, я просмотрел RFC по Вашей ссылке. Используется CFB с добавленным (обязательно в конце) хешем от предыдущего открытого текста. Как-то пытася читать Rogaway по поводу его OCB, так он критикует подобные решения.

— unknown (04/09/2014 17:26, исправлен 04/09/2014 17:37)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Протокол радикально переработан до v.0.03. Скорее всего, не в последний раз.


  1. Идея со счётчиком раундов — неудачная. Если, например, от Алисы перехвачено i сообщений на какой-то адрес и при захвате её счётчик будет равен i, то это её лишний раз демаскирует. Лучше не хранить в параметрах количество проведённых раундов.
  2. В нулевом раунде нужно ответить под MAC какой id отвечает какому id и параметрами первого раунда X1 и Y1, чтобы избежать UKS-атаки. Вопрос, насколько надёжен такой ответ под SE MDC, остаётся открытым.
  3. Поскольку попарное зацепление выводимых через DH-ключей (key ratcheting как в OTR или Axolotl), не используется, то после нулевого раунда никакие synthetic id не нужны. Сами производные ключи s выполняют функцию id.
  4. Key ratchting отвергнут намеренно. При совместном выведении ключа по Диффи-Хеллману обе DH-половинки (как секретную, так и открытую) нужно использовать один раз, после чего отбросить. При попарном же зацеплении одна и та же DH-половинка образует пару выведения секрета сначала с одной, задем с другой половинкой. Может быть это даже где-то широко используется на практике (в VPN, SSL), но я не видел теоретического обоснования такого использования. Неизвестно, точно ли так можно делать, по крайней мере это отход от классического представления DH-протокола. Даже если это в общем безопасно, ещё неизвестно, насколько это безопасно в каких-то частных протоколах и при замене стандартного DH, например, на эллиптику. Особенно, когда вторая не вполне доверяемая сторона может посылать некоторое подобранное значение новой DH-половины к уже ранее использованной DH-половине, т.к. точно знает, когда такая половина повторяется для выведения нового секрета.
— gegel (04/09/2014 21:18, исправлен 04/09/2014 21:52)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Идея со счётчиком раундов — неудачная.

Только хотел об этом написать, думал, как корректнее это сделать. Естественно, при захвате компьютера будет сразу видно объем предыдущей переписки. В то же время острой необходимости в счетчике вроде и нет, т.к. replay-атака исключается, ведь обе стороны участвуют в выведении секрета.


какой id отвечает какому id и параметрами первого раунда X1 и Y1, чтобы избежать UKS-атаки.

В идеале – да. Но я очень долго по всякому крутил IKE сокращенного варианта протокола на предмет UKS:


A→B: MDC_PKEB (idA, X 0, X 1)
B→A: MDC_PKEB ( Y 0, MDC_SEs0 (id B, X 1, Y 1) )


Я понимаю, что это не академично (по уму доказывают стойкость, а не пытаются найти атаку). Но потом я тщательно просмотрел fileAbadi, слайд 4: в ответ под MAC включается только свой Id. Как я и предполагал, этого достаточно для блокирования UKS. И, кстати, может, есть смысл заменить в ответе под MDC X 1 хешем (с целью экономии места)?


Особенно, когда вторая не вполне доверяемая сторона может посылать некоторое подобранное значение новой DH-половины к уже ранее использованной DH-половине

Согласен, это напоминает проблему полустатической DH. Причем в каких-то описаниях протоколов даже встречалась оценка уменьшения стойкости при многократном выполнении. Новизна Вашего варианта неоспорима, да. Интересно, почему в свое время OTR так не сделали, ведь пораундово по идее проще как в понимании, так и в реализации.




PS: чем дольше смотрю на вышеприведенный IKE, тем больше не нравится идея вводить X 1 и Y 1 в нулевом раунде. Получается, секрет s0 используется исключительно для MDC_SE ответа. Это для лучшей отрицаемости? Может, вернуть так, как было в предыдущих версиях: из него же вывести и рабочие ключи для следующего раунда? Дело в том, что с этим X 1 – сплошной геморрой: его обязательно надо возвращать инициатору (под MDC (в виде хеша) или под MAC), иначе можно замонтировать UKS. А аргументов в пользу выведения s1 уже в нулевом раунде вроде как пока и нет.

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

Вот у меня ни доказательств, ни даже интуитивной уверенности в этом нет. Лучше перестраховаться и чётко обозначить, кто кому возвращает ответ и на какой параметр будущего раунда отвечает.


Очевидно, да, можно хоть оба id с ним вместе похэшировать, если бороться за экономию места. В расширенном варианте протокола, когда ответ даётся под MAC, такой проблемы не возникает, поэтому машинально и перенёс в MDC SE, не подумав.


Ну вот как вы прислали ещё раз ссылку на OTR с нормальными формулами, так я и заметил этот изъян, по крайней мере очень сомнительный момент попарного использования DH в выведении ключей. Надо собрать побольше доказательств и официально предложить альтернативу.


Под MAC проблемы места нет, сколько бы параметров туда не пихали, поэтому в первых версиях протокола я вообще не экономил.


Строго обоснованно ответить не смогу. Но раз нулевой раунд только для IKE, то если он не завершится успехом, то стороны не получат ключа для связи в следующем раунде. И в случае каких-то гипотетических атак, все проблемы остаются на нулевом раунде: стёрли его параметры — дальше идёт обычная пораундовая связь. Т.е. никакой лишней информации с нулевого раунда в первый пусть не протекает. Обычно, такая вроде безопасная, но лишняя информация, позволяет находить различители для построения атак. Пусть нулевой и первый раунды будут максимально разделены. Так выглядит логичнее и аккуратнее. Никаких чрезмерных затрат это тоже не требует.
— gegel (05/09/2014 01:03, исправлен 05/09/2014 01:03)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Пусть нулевой и первый раунды будут максимально разделены. Так выглядит логичнее и аккуратнее.

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


Но хочу обратить Ваше внимание на один нюанс: по сути, у нас нулевой раунд не завершает IKE. После него Алиса (инициатор) уверена в идентичности Боба (она получила подписанные параметры). Но Боб уверен в идентичности Алисы, только когда получает от нее первое сообщение (т.е. уже в первом раунде). После нулевого раунда, даже имея s1, Боб не должен писать первым.
Я не могу на вскидку оценить последствия, просто констатирую факт.

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

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

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

Хэш добавил.
— gegel (05/09/2014 22:54, исправлен 05/09/2014 22:58)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Но если очень хочется, то в некоторых случаях можно делать то, что предлагают авторы Axolotl

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


Боб может ставить на согласованный на нулевом раунде ключ некий блокирующий флаг "unverified"

Собственно, Боб может и первым отсылать сообщение, если используется перманентная PGP-обертка. Но оно будет подвержено сильной wPFS-атаке (с активным атакующим). Допустим, Ева инициирует беседу с Бобом от имени Алисы. Боб выполняет раунд 0, отсылая Алисе ответ, а затем сразу же отсылает ей сообщение. Ни Алиса, ни Ева не могут согласовать секрет с Бобом и прочитать сообщение, сеанс завершается. Но позже Ева, завладев PGP-ключом Алисы, выводит секрет и читает сообщение Боба.


в ответ под MAC включается только свой Id

Вот у меня ни доказательств, ни даже интуитивной уверенности в этом нет.

Я попытался взглянуть на это под другим углом:
B→A: MDC_PKEA (Y 0, HMACs0 (Id B))
уже инкапсулирует в себе Id A в неявном виде в PKE (даже глядя на формулу). Я не встречал описания протоколов с DH под PKE, сравнить не с чем. А без PKE, конечно, оба Id должны быть под MAC (например, тот же SKEME). Это, наверное, слишком смелая идея, и обоснованная не более чем интуитивно, но если удастся это как-то доказать, то отрицаемость только выиграет.

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