Аналог PGP с обеспечением отрицаемости и наперёд заданной секретности оффлайн?
Обсуждение в соседней теме натолкнуло на мысль: существует ли решение, аналогичное PGP и обеспечивающее для оффлайн-сообщений конфиденциальность и аутентификацию, но плюс отрицаемость и наперед заданную секретность (PFS), ну, и, желательно, тихое уведомление о прессинге. Нашел похожий вопрос на crypto.stackexchange: похоже, что готовых решений пока нет. Возможно, где-то на pgpru это уже обсуждалось, или что-то уже появилось?
комментариев: 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) (первая половина хеша)
Не гарантирую, что будет время для содержательного просмотра, но отправляйте или публикуйте.
комментариев: 393 документов: 4 редакций: 0
Мда, это деффект. Причем, похоже, включение Id под PKE в ответ не поможет: Боб все равно сможет подменить Id Кэррол на свой. Причем это в равной степени относится и к оригинальному Abadi, что, скорее всего, и является причиной его критики. Поможет включение ID ответчика под хеш: h( Xy || IDB ). Боб не знает Xy = Yx, поэтому не сможет убедить Алису в том, что он – Кэррол. В случае использования Keccack при этом также отпадает необходимость использования разных половинок хеша (если Id гарантировано не пустой).
Ссылку на черновик доки по OnionPhone пока опубликую тут (хотя это в некотором смысле оффтоп). Там быстый старт, руководство пользователя и в конце описание формата ключей, протоколов и т.д. Возможно, кто-то внесет замечания по интерфейсу. Любая критика приветствуется и будет учтена.
комментариев: 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. Вариант с продолжением запроса согласования ключей в каждом последующем раунде пока не публикую, чтобы не загромождать восприятие.
комментариев: 393 документов: 4 редакций: 0
Не совсем хорошо для отрицаемости. Хотя под хешем допустимо, надо лишь не пользовать этот s позже (удалять тот час после завершения IKE).
На вскидку не могу понять, чем обусловлена такая необходимость. Хотя, похоже, хуже от этого не будет, в том числе и в плане отрицаемости (хотя надо подумать).
Т.е. Вы предлагаете использовать PGP как обертку на протяжении всей беседы. Наверное, в случае --throw-id от этого хуже не будет.
Бегло просмотрел ссылки по скриптам. Да, это изящный способ решить некоторые проблемы PGP малой кровью. К сожалению, я не силен в скриптовых языках, поэтому сделать это быстро и качественно точно не смогу. Идеальным была бы скриптовая реализация Axolotl или предложенного выше его варианта, в т.ч. и в вашей версии IKE + перманентной PGP-обертке.
комментариев: 9796 документов: 488 редакций: 5664
Единственно, чего реально можно достичь с помощью отрицаемости — это сказать: «Алиса сама выдумывала себе сообщения от имени Боба и сама их себе присылала. А то, что у Боба на связке тоже ключ Алисы и ему приходили сообщения с её id, а он посылал какие-то ответы — это косвенная улика. На суде с оформленной конфискацией цифровых улик может и прокатит. А просто похитить ключи трояном или для иного способа раскрытия переписки посторонним — нет.»
А из чего тогда выводить ключ для MDC_SEs?
Именно это там и сделано.
Я мог бы сделать форк, погонять, отладить, окончательно определиться с теорией и отправить автору предложение патча, но времени заниматься таким проектом пока нет.
Для обёртки и чтобы шифртекст, шифрованный ранее согласованным симметричным ключом был виден только получателю.
Вообще у меня идея именно для «почты малой кровью», что в названии топика и отражено. А вас вроде как больше потянуло на чаты и даже радио, где своя специфика и избыточный кодинг оправдан, чтобы не было избыточного текста в передачах и ресурсы экономились.
комментариев: 393 документов: 4 редакций: 0
Прикольно, но, похоже, приведенная выше атака частично актуальна и для TorChat (по сути соединение с HS эквивалентно отсылке PGP --throw-id).
Я имел в виду, не использовать его в том же виде. Просто из общего секрета выводить отдельно ключи для MAC, SE, аутентификации и т.д. Хотя это тривиально, конечно.
комментариев: 9796 документов: 488 редакций: 5664
Abadi якобы поломали (с его запутанной системой доказательств), Axolot кто-то другой поломал, Torchat поломали (С ним то что? Можно через свой логин на HS соединить двух собеседников? Например стукач соединяет кого-то прямо с полицейским управлением? Там тоже нет подписи для отрицаемости?).
Было уже якобы такое в этой теме, а затем вот так. На самом деле — без нормальной системы доказательств проектировать протоколы чисто эвристически очень рискованно. Почти тыканье вслепую, никакой provable security, сплошной шифрпанк :)
Кстати, считается хорошей практикой. Если нет уверенности, что можно использовать один и тот же параметр в разных местах протокола, лучше вывести из него производные параметры посредством какой-либо KDF.
комментариев: 393 документов: 4 редакций: 0
Ну, это не чуждо даже маэстро: именно из-за параметров под хешем HMQV трансформировалась в FHMQV, и это явно не предел.
комментариев: 9796 документов: 488 редакций: 5664
Не используйте Word никогда для подготовки технических, научных и пр. серьёзных документов. Откройте для себя LaTeX. В крайнем случае, делайте экспорт doc в pdf и публикуйте последний.
комментариев: 393 документов: 4 редакций: 0
Просто дурные привычки виндузятника, исправляюсь. Скидывал на скорую руку то, что было: черновики все же...
Но уже радует, что хоть кто-то это читает.
Под винду прекрасно работает MikTex — дистрибутив LaTeX'а. Дело не только в корявой вордовой вёрстке и в том, что WYSIWYG — зло для создания текстов, а в том, что для просмотра doc-файлов (нормального, а не приближённо-ориентировочного) требуется ставить офис libreoffice, весящий сотни мегабайт и тянущий за собой множество десктоп-ориентированного говна, а также джаву.
комментариев: 393 документов: 4 редакций: 0
http://torfone.org/download/xmail.pdf
http://torfone.org/download/onionphone.pdf
комментариев: 9796 документов: 488 редакций: 5664
Про ваш XMail. Кстати, название уже занято.
В разделе Conversation:
п.1: g — это рэндомно выбранное значение для вычисления нового т.н. Injected Key?
п.4: в режиме Keccak Duplexing Sponge, вычислять MAC отдельно необязательно. Собственно, именно для этого такой режим и был придуман.
Тяжело как-то разбирать. Даже в аккуратно написанных формулах можно пропустить ошибки.
Помимо пошагового описания, была бы хоть какая-то такая картинка, или вот как в этой новости, или более формальная схема, или таблица со стрелками.
Про местами чисто грамматические опечатки в имени Алисы, названии Keccak и про общее оформление пока вежливо молчу :) Черновик — так черновик.
OnionPhone в таком виде разобрать ещё тяжелее будет.