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

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


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



 
На страницу: 1, ... , 8, 9, 10, 11, 12, ... , 20 След.
Комментарии
— unknown (18/08/2014 12:51, исправлен 18/08/2014 16:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Полхэша — это хорошо, если Keccak. Старые хэши — не RO-PRF, их нежелательно использовать напрямую, только через HMAC. А так, да, Abadi выглядит совсем хорошо в плане минималистичности. Вот только исключение id, не позволит ли какие-то игры с переотправкой?


A→B: MDC_PKEB ( idA, X )
B→A: MDC_PKEA ( Y, h(Xy) ) (используется вторая половина хеша)
A→B: h(Yx) (первая половина хеша)



Это не MITM, но вот, что может быть. Алиса хочет поговорить с Бобом, а Боб с Кэрол. Сами Алиса и Кэрол терпеть друг друга не могут и ни в коем случае не хотят разговаривать между собой напрямую. В итоге Боб может разговаривать через себя с ними одновременно, они знают, что разговаривают с Бобом. Но если они перейдут на симметричное шифрование SE без обёртки в PKE, то он может соединить их друг с другом и послушать, как они начнут между собой ругаться, не понимая, что они разговаривают уже не с Бобом, а между собой. Если они согласованный ключ будут оборачивать каждый раз в PKE и пересогласовывать ключ, то Боб может пропустить одно сообщение от Алисы к Кэрол или от Кэрол к Алисе вслепую, без возможности прочитать. Но они могут отправить друг другу что-то лишнее: это вмешательство в протокол, как минимум. Хуже, если он может как-то подписать или пометить параметры связи и доказать этот факт.


A→B: MDC_PKEB ( idA, X )
B→C: MDC_PKEC ( idB, X )
C→B: MDC_PKEB ( Y, h(Xy) ) (используется вторая половина хеша)
B→A: MDC_PKEA ( Y, h(Xy) ) (используется вторая половина хеша)
A→B: h(Yx) (первая половина хеша)
B→C: h(Yx) (первая половина хеша)



Не гарантирую, что будет время для содержательного просмотра, но отправляйте или публикуйте.

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

Мда, это деффект. Причем, похоже, включение Id под PKE в ответ не поможет: Боб все равно сможет подменить Id Кэррол на свой. Причем это в равной степени относится и к оригинальному Abadi, что, скорее всего, и является причиной его критики. Поможет включение ID ответчика под хеш: h( Xy || IDB ). Боб не знает Xy = Yx, поэтому не сможет убедить Алису в том, что он – Кэррол. В случае использования Keccack при этом также отпадает необходимость использования разных половинок хеша (если Id гарантировано не пустой).


Ссылку на черновик fileдоки по OnionPhone пока опубликую тут (хотя это в некотором смысле оффтоп). Там быстый старт, руководство пользователя и в конце описание формата ключей, протоколов и т.д. Возможно, кто-то внесет замечания по интерфейсу. Любая критика приветствуется и будет учтена.

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

Зря я исправил опечатку в своём варианте протокола — она от этого защищала :) хотя не защищала от другого. Просто у Кравчика было именно так, правда для протоколов с подписями, а не PKE. По хорошему, что в Абади, что в моей модификации Кравчика надо загонять под хэш или HMAC оба id, с указанием кто запрашивает кого:


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


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


Собственно, здесь включать XY в скобки не надо, т.к. для вычисления s надо знать секретные a или b. Хотя, может явное указание idA : idB — тоже лишнее? Ведь всё равно нужно вычислять s. Но, по крайней мере, отвечающий (отрицаемо для посторонних) доказывает кто он и кому он отвечает.


Зато MDC_SEs надо явно внести в скобки под MDC_PKE. Вариант с продолжением запроса согласования ключей в каждом последующем раунде пока не публикую, чтобы не загромождать восприятие.

— gegel (18/08/2014 15:08, исправлен 18/08/2014 15:21)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
надо загонять под хэш или HMAC оба id

Не совсем хорошо для отрицаемости. Хотя под хешем допустимо, надо лишь не пользовать этот s позже (удалять тот час после завершения IKE).


Зато MDC_SEs надо явно внести в скобки под MDC_PKE.

На вскидку не могу понять, чем обусловлена такая необходимость. Хотя, похоже, хуже от этого не будет, в том числе и в плане отрицаемости (хотя надо подумать).
Т.е. Вы предлагаете использовать PGP как обертку на протяжении всей беседы. Наверное, в случае --throw-id от этого хуже не будет.
Бегло просмотрел ссылки по скриптам. Да, это изящный способ решить некоторые проблемы PGP малой кровью. К сожалению, я не силен в скриптовых языках, поэтому сделать это быстро и качественно точно не смогу. Идеальным была бы скриптовая реализация Axolotl или предложенного выше его варианта, в т.ч. и в вашей версии IKE + перманентной PGP-обертке.

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

Единственно, чего реально можно достичь с помощью отрицаемости — это сказать: «Алиса сама выдумывала себе сообщения от имени Боба и сама их себе присылала. А то, что у Боба на связке тоже ключ Алисы и ему приходили сообщения с её id, а он посылал какие-то ответы — это косвенная улика. На суде с оформленной конфискацией цифровых улик может и прокатит. А просто похитить ключи трояном или для иного способа раскрытия переписки посторонним — нет.»



А из чего тогда выводить ключ для MDC_SEs?



‎Именно это там и сделано.


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



Для обёртки и чтобы шифртекст, шифрованный ранее согласованным симметричным ключом был виден только получателю.


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

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

Прикольно, но, похоже, приведенная выше атака частично актуальна и для TorChat (по сути соединение с HS эквивалентно отсылке PGP --throw-id).


А из чего тогда выводить ключ для MDC_SEs?

Я имел в виду, не использовать его в том же виде. Просто из общего секрета выводить отдельно ключи для MAC, SE, аутентификации и т.д. Хотя это тривиально, конечно.

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

Abadi якобы поломали (с его запутанной системой доказательств), Axolot кто-то другой поломал, Torchat поломали (С ним то что? Можно через свой логин на HS соединить двух собеседников? Например стукач соединяет кого-то прямо с полицейским управлением? Там тоже нет подписи для отрицаемости?).


Было уже якобы такое в этой теме, а затем вот так. На самом деле — без нормальной системы доказательств проектировать протоколы чисто эвристически очень рискованно. Почти тыканье вслепую, никакой provable security, сплошной шифрпанк :)



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

— gegel (18/08/2014 16:03)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
без нормальной системы доказательств проектировать протоколы чисто эвристически очень рискованно.

Ну, это не чуждо даже маэстро: именно из-за параметров под хешем HMQV трансформировалась в FHMQV, и это явно не предел.
— unknown (18/08/2014 16:21)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Да, Коблиц будет вечно актуален:
И Кравчик, и референты из программного комитета были загипнотизированы "доказательством", так что они пошли против здравого смысла. Каждый кто работает в криптографии должен очень внимательно подумать перед отбрасыванием проверочных шагов, предназначенных для предотвращения проблем с безопасностью. Конечно кто-то с опытом и экспертными навыками Кравчика мог бы никогда и не допустить такой оплошности, если бы он не был слишком самоуверен в своих "доказательствах" безопасности. Также как и многие другие гиперболизированные идеи – противорадиационные укрытия в 1950-х, противоракетная защита в 1980-х – "доказательства" безопасности криптографических протоколов часто дают фальшивую уверенность, ослепляющую людей перед реальной опасностью.
— Гость (18/08/2014 20:11)   <#>

Не используйте Word никогда для подготовки технических, научных и пр. серьёзных документов. Откройте для себя LaTeX. В крайнем случае, делайте экспорт doc в pdf и публикуйте последний.
— Гость (18/08/2014 20:17)   <#>
И в RAR не пакуйте.
— gegel (18/08/2014 23:42)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Я, кстати, ждал этих замечаний по rar и word, и рекомендации LaTeX. Буквально час назад еще удивился, почему никто так и не возмутился. Ну, теперь все нормально :)
Просто дурные привычки виндузятника, исправляюсь. Скидывал на скорую руку то, что было: черновики все же...
Но уже радует, что хоть кто-то это читает.
— Гость (19/08/2014 03:31)   <#>

Под винду прекрасно работает MikTex — дистрибутив LaTeX'а. Дело не только в корявой вордовой вёрстке и в том, что WYSIWYG — зло для создания текстов, а в том, что для просмотра doc-файлов (нормального, а не приближённо-ориентировочного) требуется ставить офис libreoffice, весящий сотни мегабайт и тянущий за собой множество десктоп-ориентированного говна, а также джаву.
— gegel (19/08/2014 10:18)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
MikTex есть, конечно. Просто дурные привычки. Пока конвертировал в pdf:

filehttp://torfone.org/download/xmail.pdf
filehttp://torfone.org/download/onionphone.pdf
— unknown (19/08/2014 11:40, исправлен 19/08/2014 11:43)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Про ваш XMail. Кстати, название уже занято.


В разделе Conversation:


п.1: g — это рэндомно выбранное значение для вычисления нового т.н. Injected Key?
п.4: в режиме Keccak Duplexing Sponge, вычислять MAC отдельно необязательно. Собственно, именно для этого такой режим и был придуман.


Тяжело как-то разбирать. Даже в аккуратно написанных формулах можно пропустить ошибки.
Помимо пошагового описания, была бы хоть какая-то такая картинка, или вот как в этой новости, или более формальная схема, или таблица со стрелками.


Про местами чисто грамматические опечатки в имени Алисы, названии Keccak и про общее оформление пока вежливо молчу :) Черновик — так черновик.


OnionPhone в таком виде разобрать ещё тяжелее будет.

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