Аналог PGP с обеспечением отрицаемости и наперёд заданной секретности оффлайн?
Обсуждение в соседней теме натолкнуло на мысль: существует ли решение, аналогичное PGP и обеспечивающее для оффлайн-сообщений конфиденциальность и аутентификацию, но плюс отрицаемость и наперед заданную секретность (PFS), ну, и, желательно, тихое уведомление о прессинге. Нашел похожий вопрос на crypto.stackexchange: похоже, что готовых решений пока нет. Возможно, где-то на pgpru это уже обсуждалось, или что-то уже появилось?
Как вы собираетесь доказывать? Написать статью, потом положить её в IACR/arXiv, сабмитнуть в J. of Crypt. или FOCS/STOC, провести через процедуру рецензирования независимыми оппонентами, и в итоге получить публикацию в реферируемом научном издании, индексируемом такими базами как Web of Science и/или scoups? Если что, это тот минимум, после которого хоть кто-то будет говорить, что «доказательство безопасности протокола в рамках таких-то допущений было дано». Т.е. это будет состоявшийся факт, на который смогут ссылаться люди, причём нахождение ошибок в вашей работе можно будет оформить как другую работу, и точно так же провести её через архив и журналы/конференции. Это даёт повод вашим потенциальным критикам внимательно читать вашу работу. Т.е. на нахождении в ней ошибок можно срубить новую публикацию.
Всё остальное — это как надписи на заборах, «кто-то написал». Кстати, описанный процесс вообще не дружит с анонимностью. Т.е., совсем никак.
Pond больше для почты, чем для IM, как я понял (для часто отправляемых сообщений не подходит), но всё же интересный проект, недавно его обсуждали. Он уже может претендовать на заменителя TorChat или нет? Судя по словам про случайно выбираемое время для контакта с серверами — нет. К тому же, идея использования серверов, когда оба юзера в онлайне, мне не очень нравится. Т.е. для доверенных контактов лучше прямое соединение, а для недоверенных — через сервер.
комментариев: 393 документов: 4 редакций: 0
Я усвоил то, о чем вы писали, еще с предыдущего, почти дословного, вашего поста по поводу публикаций в CS. Поэтому я ничего доказывать и не собираюсь, Вы неверно поняли. Я понимаю, что выполнить полноценное академическое доказательство практически нереально в моем случае.
Я когда-то очень бегло просмотрел этот проект, поэтому не могу ничего сказать об используемом транспорте. Но, как Вы сами указали, это почтовое решение, предполагающее, что получатель не все время онлайн. Поэтому сравнивать Pond и TorChat, наверное, не совсем корректно.TorChat прекрасно справляется со своей задачей анонимного мессенжера, его нет смысла на что-то менять (разве что добавить независимый слой шифрования/аутентификации плюс всякие довески типа проброса портов и т.п.).
Что же касается почты, то без онлайн-сервера тут не обойтись. Но, во первых, этот сервер должен быть на HS, а во вторых – лишь хранить и пересылать рандомно выглядящие данные указанному onion-адресату по его запросу, не требуя регистрации и аутентификации ни отправителя (при отправке почты на сервер), ни получателя (при запросе получателя на пересылку ему его почты). Естественно, почтовые клиенты должны обеспечивать оконечное PFS-шифрование и отрицаемую аутентификацию, например, используя протокол Axolotl.
Сразу как доделаю OnionPhone, по быстрому нацарапаю тестовый прототип такого сервера и клиента на С, алгоритмической сложности там абсолютно никакой нет.
Цитата от Гость (13/06/2013 23:37) из темы Pong:
Не могу согласиться. Оффлайн ничем не отличается от онлайн, кроме времени доставки. В любом случае ваш пакет проходит через множество узлов и так или иначе содержит адрес получателя.
Другое дело, что выходной узел может периодически проверять надичие получателя онлайн, а может дождаться от него сигнала (анонимно через Tor, с указанием своего онион-адреса). Если на сервере имеются письма для данного онион-адреса, сервер сам подключается к получателю и отсылает ему его письма. Таким образом, сервер может собирать информацию, сколько писем он переслал определенному псевдониму, но не знает, от кого. Кроме того, стороны могут периодически согласованно менять псевдонимы (онион-адреса), оставляя за собой ранее согласованное оконечное шифрование/аутентификацию.
комментариев: 393 документов: 4 редакций: 0
И таки чутье меня не подвело: последний вариант протокола уязвим, т.к. злонамеренный Боб может замонтировать UKS.
Reduced version:
A→B: MDC_PKE B(id A, X 0, X 1)
E→B: MDC_PKE B(Y 0, MDC_SEs0(Y 1, H(id E, id B, X 1)))
В результате Алиса и Ева расшаривают s 1 между собой, хотя обе считают, что с Бобом.
В предыдущих вариантах протокола с одним DH-ключом в сообщениях нулевого раунда (а также и в моем редуцированном варианте) это невозможно, т.к. Боб не знает s 1, который одновременно выполняет и функцию вашего s 0.
Т.к. нулевой раунд по сути не завершает IKE, то информация с него так или иначе должна протекать в следующий раунд для завершения аутентификации.
комментариев: 9796 документов: 488 редакций: 5664
Недавно удалил локальные записи предыдущих вариантов, не могу теперь понять какая редакция wiki соответствовала последнему неуязвимому варианту.
Удачно заметили. У меня было подозрение, что нельзя отказываться от MAC, т.к. MDC SE позволяет произвольно перешифровывать ответ. А в MAC надо загонять максимум параметров ответа, очень тщательно думая над отбрасыванием якобы лишнего. А то вот можно так доредуцироваться. И особого смысла балансировать в сторону большей отрицаемости за счёт общей безопасности нет.
комментариев: 393 документов: 4 редакций: 0
В данной ситуации MAC не поможет: Боб, зная s 0 и s' 0, точно так же пересчитает МАС. Но пока не удаляйте последнюю версию: возможно, это была паранойя с моей стороны. Я внимательно перечитал определение UKS (например, в Wiki), и оно не совсем совпадает ситуацией выше: классически Алиса должна расшаривать ключ с Евой и думать так же, а Ева должна расшаривать с Бобом, но думать, что с Алисой. В нашем случае ошибаются обе стороны. Возможно, это не считается за UKS, потому что я с удивлением обнаружил, что с трехпроходной SKEME (стр. 9) аналогичное тоже легко проделывается.
комментариев: 9796 документов: 488 редакций: 5664
Perfect Forward, что Security, что Deniability. Если Боб, с которым связывается Алиса, злонамерен уже в самом начале, то тут мало что поможет.
Правда, вы сами приводили работу "Deniable Authentication and Key Exchange", Mario Di Raimondo, Rosario Gennaro and Hugo Krawczyk, где разобраны и сложные случаи Боба, сотрудничающего с неким судьёй.
Оригинальная работа Кравчика очень старомодно выглядит, сложно её читать. Дело даже не в том, что MD5 там ещё считается стойкой функцией. Сейчас в работах вводят некую абстрактную h про которую говорят, что h — это случайный оракул или дают какое-то определяющее свойство и т.д.
Так вот, в вышеупомянутой более свежей работе, SKEME изложен несколько иначе. Пока не нашёл, у самого Кравчика есть более свежее переизложение конкретно самого SKEME? Поскольку в работе, где он разбирается, там уменьшена универсальность (по крайнее мере не рассматривается все 4 случая с разным уровнем отрицаемости и «вперёдсекретности»), количество шагов сокращено, сессионый ключ из секрета выводится иначе.
Если делать навороченный протокол и посылать через сеть серверов. Когда оба онлайн, самый рабочий вариант — p2p как hs2hs. Пересылающие вообще ничего не видят кроме того, что кто-то стучится на какой-то адрес. Что идёт внутри шифрованного тунеля — скрыто. Двусторонняя ли это связь — тоже скрыто. Почта ли это, IM или просто пересылка файлов — тоже скрыто. И даже адрес onion будет неизвестен, если стороны готовы у себя в torrc прописать соответствующие опции. А вот с оффлайном так легко не сделать...
комментариев: 9796 документов: 488 редакций: 5664
Это не входит в ядро протокола. Чтобы было легче рассматривать, оттуда уже даже выкинуто прикрытие почтового сообщения через PKE после нулевого раунда. Эта обёртка может и должна использоваться для неприметности сообщения по сравнению с обычным PGP и чтобы стойкость протокола гарантирована не была хуже обычной PGP-переписки. Но для наглядности рассмотрения это убрано из формализации. А передача через HS-2-HS, файлообменники, прикручивание анонимных коммуникаций — на совести пользователя. Это вынесено за рамки минимальной формализации. Также как возможная внутренняя замена Диффи-Хеллмана на эллиптику и более нестандартные, и совсем экзотические варианты.
Именно.
Инициатор A генерирует одноразовую пару ключей, отвечающая сторона B генерирует общий ключ K для симметрики. Начальная аутентификация средствами PGP. Вся дальнейшая связь и аутентификация A и B осуществляется на ключе K. При каждой транзакции ключ K модифицируется функцией, идущей только вперед (Keccak sponge wrap, как вы предлагаете, или что-то аналогичное). Также K модифицируется по времени.
Такая структура совместимо вписывается в систему PGP c минимальными дополнениями (ключехранилище для K). Оверхед +1 проход на установление связи (по сравнению с обычной PGP). Удобно, практично, просто.
Почтенный gegel, может стоит взять и сделать как дополнительную полезную фичу к PGP.
комментариев: 393 документов: 4 редакций: 0
Очень абстрактно. На вскидку атака:
– Инициатор A генерирует одноразовую пару ключей;
– Подписывает временный публичный ключ и отсылает его B
– Ева перехватывает, переподписывает, и отсылает его B, выдавая за свой;
– B получает, генерирует K, шифрует с помощью полученного ключа и отсылает E. E в неизменном виде пересылает А.
В итоге классическая UKS: А считает, что общается с B, и общается с ним на самом деле. B считает, что общается с E, но общается с А.
Про отрицаемость в предложенной схеме вообще речь не идет. Об самоизлечении – тоже (при утечке симметричного ключа на каком-то этапе все последующие сообщения будут скомпрометированы даже для пассивного атакующего).
Хотя похожий протокол (на однонаправленной хеш-функции) используется в Циммермановском SilentCircle.
PS: Keccak sponge wrap – это режим аутентифицируемого шифрования с использованием Keccak Sponge. Хеш-функция – просто Keccak.
Начальный обмен одноразовой парой закрыт и аутентифицирован долговременными PGP ключами A и B. Последующий обмен на ключе K тоже может быть инкапсулирован в PGP почту.
Большое преимущество по сравнению с обычной PGP, когда в случае утечки ключа скомпрометированы все сообщения.
Причем с сохранением совместимости, минимально возможным оверхедом/неудобством и малыми изменениями.
После того как установлен начальный контакт на ключе K, мы можем периодически переустанавливать ключ с помощью той же процедуры с одноразовой парой ключей. Причем делать это автоматически, на фоне идущей переписки.
Вспоминается популярная песня из детства с припевом "Пусть лучше будет хуже чем не будет совсем" (не помню кто пел).
комментариев: 9796 документов: 488 редакций: 5664
Здесь авторы интересно рассматривают One-Round Key Exchange (ORKE) и Non-Interactive Key Exchange (NIKE) сверяясь с моделями Bellare and Rogaway (the BR model) и Canetti and Krawczyk (the CK model). Им удалось доказать PFS для достаточно универсального протокола (м.б. не завязан на DH) — так там ещё разные PFS бывают, они отдельно рассматривают weak PFS, а на отрицаемость они даже не замахивались.
В очередной раз убеждаюсь: единственное, что приходит в голову после чтения таких работ — самопальные протоколы сразу в топку, нечего страдать NIH и изобретать своё, особенно если такая тема так сложно идёт даже у продвинутых теоретиков.
Они рассматривают другой класс протоколов; а у Вас, как всегда, нет аргументов по сути дела.
Когда-то был большой проект, в котором, помимо многого прочего, нужно было разработать схему помехоустойчивого кодирования. На соседней кафедре был профессор с мировым именем в теории кодов. Обратились к нему. Ничего они не сделали, в результате пришлось все делать самим. Получилось довольно коряво, однако работоспособно. C позиции нынешних знаний, конечно, следовало бы сделать не то и не так, но Карла Маркс нас учил что практика – критерий истины. Такие дела.
http://www.zas-comm.ru
Как определили работоспособность? Слили схему кодирования противнику и в реальной войне он не смог заглушить канал? Да даже если и так, означает ли это, что в следующей войне он не заглушит?
Когда практика столкнётся с неумолимой теорией, стелить соломку будет поздно. В таком темпе можно и вечные двигатели изобретать, пока лох деньги несёт, и защиту от копирования (пока её не сломали) и всё остальное. У ZAS'а промытые мозги по самое нехочу. Понимания нет, а гонора выше крыши.