Аналог PGP с обеспечением отрицаемости и наперёд заданной секретности оффлайн?
Обсуждение в соседней теме натолкнуло на мысль: существует ли решение, аналогичное PGP и обеспечивающее для оффлайн-сообщений конфиденциальность и аутентификацию, но плюс отрицаемость и наперед заданную секретность (PFS), ну, и, желательно, тихое уведомление о прессинге. Нашел похожий вопрос на crypto.stackexchange: похоже, что готовых решений пока нет. Возможно, где-то на pgpru это уже обсуждалось, или что-то уже появилось?
комментариев: 9796 документов: 488 редакций: 5664
Идёте на http://arxiv.org, смотрите работы. Например эту. Справа там предлагается скачать в PDF, Postscript и Other formats. Дополнительные форматы есть не у всех работ. Но если они есть, то среди них для многих работ есть и формат Source. В Source может быть tar.gz со всеми картинками, вставленными отдельными файлами и LaTeX (типа такого), может быть простой LaTeX или сжатый tex.gz.
Хреновое заводское оформление. Вот тут хоть что-то для приличия подкрутили. Попадались работы ещё лучше оформленные, но лень искать.
комментариев: 9796 документов: 488 редакций: 5664
Поменял до v.0.024.
От R избавился, они были нужны для улучшения отрицаемости внутри раунда. Теперь отрицаемость и PFS внутри раунда достигается без R и при этом эффективнее.
При помощи KDF из текущего DH-секрета раунда для следующего раунда вычисляются два Sid, как и раньше. А вот симметричных ключей вычисляется четыре: одна пара — для шифрования и аутентификации в одну сторону, другая — соответственно в другую.
Теперь сторона B может отправить сообщение стороне A, вычислить Sid для следующего раунда и сразу же стереть свой симметричный ключ, получив отрицаемость (в принятом нами ограниченном понятии этого свойства) и PFS уже внутри раунда. Получатель A также может после расшифровки и проверки сообщения вычислить аналогичный Sid и сразу же удалять этот симметричный ключ текущего раунда.
комментариев: 393 документов: 4 редакций: 0
Все выглядит идеально. Но сегодня утром я неожиданно увидел то же под другим углом. Наверное, это Вам не совсем понравится, но и тем не менее выскажу свои соображения хотя-бы в качестве альтернативы для сравнения.
Дело в том, что Вы рассматриваете каждый раунд как независимое ключевое согласование, аутентифицированное с помощью имеющихся от предыдущего раунда 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)
Конечно, я мог на вскидку опустить что-то важное, но под описанным выше углом зрения вроде выглядит приемлемо.
комментариев: 9796 документов: 488 редакций: 5664
Я тоже об этом думал. Но делал протокол уже так, как будто MDC ненадёжен, может быть взломан и его просто нет. Т.е. MDC — это просто довесок, перестраховка, которая раз есть в OpenPGP, то почему бы ей не воспользоваться. Сомнения по поводу MDC уже были ранее в теме, потому как это
шифрпанковскоевнутреннее специфичное изобретение OpenPGP RFC4880 теоретически нигде не описанное и формально недоказанное. В самом RFC он описывается как готовое решение для отрицаемости и отказа от подписей, можете почитать.Но если попытка создать очередной протокол, наподобие "Flat Spheroid" будет когда-то формализована, то его стойкость можно будет рассмотреть без MDC и провести сравнительный анализ с другими протоколами. Ваши идеи по заземлению протокола мне нравились и существенно повлияли на его текущую версию.
Более того, может быть подумаю о том, чтобы описать его в двух вариантах: полном, не опирающемся на стойкость MDC; и вашем сокращённом, основанном на том, что MDC — стойкая конструкция, которая когда-нибудь может быть формализована и признана академическим сообществом.
P.S.: Flat Spheroid v.0.025 в двух вариантах, готово.
комментариев: 9796 документов: 488 редакций: 5664
Может там сделать:
B → A: MDC PKEB (Y0, MDC SEB→A (IdB, Y1))
комментариев: 393 документов: 4 редакций: 0
Еще вопрос: в раунде n обе стороны вводят ключи n+1 и соответственно выводят секреты n+1 (все симметрично). Но в раунде 0 только одна сторона вводит ключ 1. Таким образом, не совсем понятно происхождение секретов s1.
Может, попробовать перейти на "последовательное спаривание" (0-1, 1-2, 2-3) ключей в стиле OTR?
комментариев: 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.
комментариев: 393 документов: 4 редакций: 0
Кстати, я именно с описания OTR-протокола брал пример. Наверное, не лучший подход оказался. Более приемлемо раунды описаны в их
первой работе, стр.4.
Уязвимость этой версии касалась IKE и была исправлена позже, принцип "спаривания" остался тот же.
Да, я просмотрел RFC по Вашей ссылке. Используется CFB с добавленным (обязательно в конце) хешем от предыдущего открытого текста. Как-то пытася читать Rogaway по поводу его OCB, так он критикует подобные решения.
комментариев: 9796 документов: 488 редакций: 5664
Протокол радикально переработан до v.0.03. Скорее всего, не в последний раз.
комментариев: 393 документов: 4 редакций: 0
Только хотел об этом написать, думал, как корректнее это сделать. Естественно, при захвате компьютера будет сразу видно объем предыдущей переписки. В то же время острой необходимости в счетчике вроде и нет, т.к. replay-атака исключается, ведь обе стороны участвуют в выведении секрета.
В идеале – да. Но я очень долго по всякому крутил 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) )
Я понимаю, что это не академично (по уму доказывают стойкость, а не пытаются найти атаку). Но потом я тщательно просмотрел
Abadi, слайд 4: в ответ под MAC включается только свой Id. Как я и предполагал, этого достаточно для блокирования UKS. И, кстати, может, есть смысл заменить в ответе под MDC X 1 хешем (с целью экономии места)?
Согласен, это напоминает проблему полустатической DH. Причем в каких-то описаниях протоколов даже встречалась оценка уменьшения стойкости при многократном выполнении. Новизна Вашего варианта неоспорима, да. Интересно, почему в свое время OTR так не сделали, ведь пораундово по идее проще как в понимании, так и в реализации.
PS: чем дольше смотрю на вышеприведенный IKE, тем больше не нравится идея вводить X 1 и Y 1 в нулевом раунде. Получается, секрет s0 используется исключительно для MDC_SE ответа. Это для лучшей отрицаемости? Может, вернуть так, как было в предыдущих версиях: из него же вывести и рабочие ключи для следующего раунда? Дело в том, что с этим X 1 – сплошной геморрой: его обязательно надо возвращать инициатору (под MDC (в виде хеша) или под MAC), иначе можно замонтировать UKS. А аргументов в пользу выведения s1 уже в нулевом раунде вроде как пока и нет.
комментариев: 9796 документов: 488 редакций: 5664
Вот у меня ни доказательств, ни даже интуитивной уверенности в этом нет. Лучше перестраховаться и чётко обозначить, кто кому возвращает ответ и на какой параметр будущего раунда отвечает.
Очевидно, да, можно хоть оба id с ним вместе похэшировать, если бороться за экономию места. В расширенном варианте протокола, когда ответ даётся под MAC, такой проблемы не возникает, поэтому машинально и перенёс в MDC SE, не подумав.
Ну вот как вы прислали ещё раз ссылку на OTR с нормальными формулами, так я и заметил этот изъян, по крайней мере очень сомнительный момент попарного использования DH в выведении ключей. Надо собрать побольше доказательств и официально предложить альтернативу.
Под MAC проблемы места нет, сколько бы параметров туда не пихали, поэтому в первых версиях протокола я вообще не экономил.
Строго обоснованно ответить не смогу. Но раз нулевой раунд только для IKE, то если он не завершится успехом, то стороны не получат ключа для связи в следующем раунде. И в случае каких-то гипотетических атак, все проблемы остаются на нулевом раунде: стёрли его параметры — дальше идёт обычная пораундовая связь. Т.е. никакой лишней информации с нулевого раунда в первый пусть не протекает. Обычно, такая вроде безопасная, но лишняя информация, позволяет находить различители для построения атак. Пусть нулевой и первый раунды будут максимально разделены. Так выглядит логичнее и аккуратнее. Никаких чрезмерных затрат это тоже не требует.
комментариев: 393 документов: 4 редакций: 0
Да, это разумно. С точки зрения той же отрицаемости лучше использовать полученный в IKE секрет только для подписывания параметров, но не в качестве рабочего ключа.
Но хочу обратить Ваше внимание на один нюанс: по сути, у нас нулевой раунд не завершает IKE. После него Алиса (инициатор) уверена в идентичности Боба (она получила подписанные параметры). Но Боб уверен в идентичности Алисы, только когда получает от нее первое сообщение (т.е. уже в первом раунде). После нулевого раунда, даже имея s1, Боб не должен писать первым.
Я не могу на вскидку оценить последствия, просто констатирую факт.
комментариев: 9796 документов: 488 редакций: 5664
Здесь никаких последствий, изначально задумывалось строгое пошаговое чередование. В плане особенностей реализации, Боб может ставить на согласованный на нулевом раунде ключ некий блокирующий флаг "unverified", а затем удалять этот флаг с ключа после прихода корректного ответа Алисы на первом раунде.
Другое дело, что в обобщённом описании протокола вообще не предусмотрена система отправки сообщений в нарушение очереди или нескольких сообщений от одной стороны без получения завершающего ответа от другой, контроль рассогласований и пр. Вроде это и так логично, без строго очерёдных попарных ответов не завершить пересогласование для следующего раунда. Но если очень хочется, то в некоторых случаях можно делать то, что предлагают авторы Axolotl — окно безопасности на цепочке производных ключей s, вырабатываемых через KDF от текущего ключа раунда.
Хэш добавил.
комментариев: 393 документов: 4 редакций: 0
Это нужно делать, без окна безопасности в стиле Axolotl протокол будет теоретической игрушкой, непригодной для почты. Я так предполагал, что это не выносится в обсуждение на данном этапе, но будет навешено позже в любом случае.
Собственно, Боб может и первым отсылать сообщение, если используется перманентная PGP-обертка. Но оно будет подвержено сильной wPFS-атаке (с активным атакующим). Допустим, Ева инициирует беседу с Бобом от имени Алисы. Боб выполняет раунд 0, отсылая Алисе ответ, а затем сразу же отсылает ей сообщение. Ни Алиса, ни Ева не могут согласовать секрет с Бобом и прочитать сообщение, сеанс завершается. Но позже Ева, завладев PGP-ключом Алисы, выводит секрет и читает сообщение Боба.
Я попытался взглянуть на это под другим углом:
B→A: MDC_PKEA (Y 0, HMACs0 (Id B))
уже инкапсулирует в себе Id A в неявном виде в PKE (даже глядя на формулу). Я не встречал описания протоколов с DH под PKE, сравнить не с чем. А без PKE, конечно, оба Id должны быть под MAC (например, тот же SKEME). Это, наверное, слишком смелая идея, и обоснованная не более чем интуитивно, но если удастся это как-то доказать, то отрицаемость только выиграет.