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

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


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



 
На страницу: 1, 2, 3, 4, 5, ... , 16, 17, 18, 19, 20 След.
Комментарии
— Гость (08/09/2014 02:44)   <#>

Как вы собираетесь доказывать? Написать статью, потом положить её в IACR/arXiv, сабмитнуть в J. of Crypt. или FOCS/STOC, провести через процедуру рецензирования независимыми оппонентами, и в итоге получить публикацию в реферируемом научном издании, индексируемом такими базами как Web of Science и/или scoups? Если что, это тот минимум, после которого хоть кто-то будет говорить, что «доказательство безопасности протокола в рамках таких-то допущений было дано». Т.е. это будет состоявшийся факт, на который смогут ссылаться люди, причём нахождение ошибок в вашей работе можно будет оформить как другую работу, и точно так же провести её через архив и журналы/конференции. Это даёт повод вашим потенциальным критикам внимательно читать вашу работу. Т.е. на нахождении в ней ошибок можно срубить новую публикацию.

Всё остальное — это как надписи на заборах, «кто-то написал». Кстати, описанный процесс вообще не дружит с анонимностью. Т.е., совсем никак.
— Гость (08/09/2014 09:16)   <#>

Pond больше для почты, чем для IM, как я понял (для часто отправляемых сообщений не подходит), но всё же интересный проект, недавно его обсуждали. Он уже может претендовать на заменителя TorChat или нет? Судя по словам про случайно выбираемое время для контакта с серверами — нет. К тому же, идея использования серверов, когда оба юзера в онлайне, мне не очень нравится. Т.е. для доверенных контактов лучше прямое соединение, а для недоверенных — через сервер.
— gegel (08/09/2014 10:02, исправлен 08/09/2014 10:26)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Как вы собираетесь доказывать?

Я усвоил то, о чем вы писали, еще с предыдущего, почти дословного, вашего поста по поводу публикаций в CS. Поэтому я ничего доказывать и не собираюсь, Вы неверно поняли. Я понимаю, что выполнить полноценное академическое доказательство практически нереально в моем случае.


Pond

Я когда-то очень бегло просмотрел этот проект, поэтому не могу ничего сказать об используемом транспорте. Но, как Вы сами указали, это почтовое решение, предполагающее, что получатель не все время онлайн. Поэтому сравнивать Pond и TorChat, наверное, не совсем корректно.TorChat прекрасно справляется со своей задачей анонимного мессенжера, его нет смысла на что-то менять (разве что добавить независимый слой шифрования/аутентификации плюс всякие довески типа проброса портов и т.п.).
Что же касается почты, то без онлайн-сервера тут не обойтись. Но, во первых, этот сервер должен быть на HS, а во вторых – лишь хранить и пересылать рандомно выглядящие данные указанному onion-адресату по его запросу, не требуя регистрации и аутентификации ни отправителя (при отправке почты на сервер), ни получателя (при запросе получателя на пересылку ему его почты). Естественно, почтовые клиенты должны обеспечивать оконечное PFS-шифрование и отрицаемую аутентификацию, например, используя протокол Axolotl.
Сразу как доделаю OnionPhone, по быстрому нацарапаю тестовый прототип такого сервера и клиента на С, алгоритмической сложности там абсолютно никакой нет.


Цитата от Гость (13/06/2013 23:37) из темы Pong:

Как известно, посылка в оффлайн без доверия третьей стороне невозможна

Не могу согласиться. Оффлайн ничем не отличается от онлайн, кроме времени доставки. В любом случае ваш пакет проходит через множество узлов и так или иначе содержит адрес получателя.
Другое дело, что выходной узел может периодически проверять надичие получателя онлайн, а может дождаться от него сигнала (анонимно через Tor, с указанием своего онион-адреса). Если на сервере имеются письма для данного онион-адреса, сервер сам подключается к получателю и отсылает ему его письма. Таким образом, сервер может собирать информацию, сколько писем он переслал определенному псевдониму, но не знает, от кого. Кроме того, стороны могут периодически согласованно менять псевдонимы (онион-адреса), оставляя за собой ранее согласованное оконечное шифрование/аутентификацию.


— gegel (08/09/2014 18:47, исправлен 08/09/2014 18:49)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
> чем дольше смотрю на вышеприведенный IKE, тем больше не нравится идея вводить
X 1 и Y 1 в нулевом раунде.

< Т.е. никакой лишней информации с нулевого раунда в первый пусть не протекает.

> Но хочу обратить Ваше внимание на один нюанс: по сути, у нас нулевой раунд не завершает IKE.
...
Я не могу на вскидку оценить последствия, просто констатирую факт.

< Здесь никаких последствий, изначально задумывалось строгое пошаговое чередование.

И таки чутье меня не подвело: последний вариант протокола уязвим, т.к. злонамеренный Боб может замонтировать UKS.


Reduced version:


A→B: MDC_PKE B(id A, X 0, X 1)

B→E: MDC_PKE E(id B, X' 0, X 1)

E→B: MDC_PKE B(Y 0, MDC_SEs0(Y 1, H(id E, id B, X 1)))

B→A: MDC_PKE A(Y' 0, MDC_SEs'0(Y 1, H(id B, id A, X 1)))

В результате Алиса и Ева расшаривают s 1 между собой, хотя обе считают, что с Бобом.


В предыдущих вариантах протокола с одним DH-ключом в сообщениях нулевого раунда (а также и в моем редуцированном варианте) это невозможно, т.к. Боб не знает s 1, который одновременно выполняет и функцию вашего s 0.
Т.к. нулевой раунд по сути не завершает IKE, то информация с него так или иначе должна протекать в следующий раунд для завершения аутентификации.

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

Недавно удалил локальные записи предыдущих вариантов, не могу теперь понять какая редакция wiki соответствовала последнему неуязвимому варианту.

Удачно заметили. У меня было подозрение, что нельзя отказываться от MAC, т.к. MDC SE позволяет произвольно перешифровывать ответ. А в MAC надо загонять максимум параметров ответа, очень тщательно думая над отбрасыванием якобы лишнего. А то вот можно так доредуцироваться. И особого смысла балансировать в сторону большей отрицаемости за счёт общей безопасности нет.
— gegel (08/09/2014 22:21)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
У меня было подозрение, что нельзя отказываться от MAC

В данной ситуации MAC не поможет: Боб, зная s 0 и s' 0, точно так же пересчитает МАС. Но пока не удаляйте последнюю версию: возможно, это была паранойя с моей стороны. Я внимательно перечитал определение UKS (например, в Wiki), и оно не совсем совпадает ситуацией выше: классически Алиса должна расшаривать ключ с Евой и думать так же, а Ева должна расшаривать с Бобом, но думать, что с Алисой. В нашем случае ошибаются обе стороны. Возможно, это не считается за UKS, потому что я с удивлением обнаружил, что с fileтрехпроходной SKEME (стр. 9) аналогичное тоже легко проделывается.
— unknown (09/09/2014 20:56, исправлен 09/09/2014 20:58)   профиль/связь   <#>
комментариев: 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 случая с разным уровнем отрицаемости и «вперёдсекретности»), количество шагов сокращено, сессионый ключ из секрета выводится иначе.

— Гость (11/09/2014 01:53)   <#>

Если делать навороченный протокол и посылать через сеть серверов. Когда оба онлайн, самый рабочий вариант — p2p как hs2hs. Пересылающие вообще ничего не видят кроме того, что кто-то стучится на какой-то адрес. Что идёт внутри шифрованного тунеля — скрыто. Двусторонняя ли это связь — тоже скрыто. Почта ли это, IM или просто пересылка файлов — тоже скрыто. И даже адрес onion будет неизвестен, если стороны готовы у себя в torrc прописать соответствующие опции. А вот с оффлайном так легко не сделать...
— unknown (11/09/2014 21:09, исправлен 11/09/2014 21:11)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Это не входит в ядро протокола. Чтобы было легче рассматривать, оттуда уже даже выкинуто прикрытие почтового сообщения через PKE после нулевого раунда. Эта обёртка может и должна использоваться для неприметности сообщения по сравнению с обычным PGP и чтобы стойкость протокола гарантирована не была хуже обычной PGP-переписки. Но для наглядности рассмотрения это убрано из формализации. А передача через HS-2-HS, файлообменники, прикручивание анонимных коммуникаций — на совести пользователя. Это вынесено за рамки минимальной формализации. Также как возможная внутренняя замена Диффи-Хеллмана на эллиптику и более нестандартные, и совсем экзотические варианты.

— ZAS (03/10/2014 17:28)   <#>
Вначале инициатор связи создает временную PGP-связкy ключей для согласования аутентификационной фразы (тот час удаляя связку после использования)


Именно.

Инициатор A генерирует одноразовую пару ключей, отвечающая сторона B генерирует общий ключ K для симметрики. Начальная аутентификация средствами PGP. Вся дальнейшая связь и аутентификация A и B осуществляется на ключе K. При каждой транзакции ключ K модифицируется функцией, идущей только вперед (Keccak sponge wrap, как вы предлагаете, или что-то аналогичное). Также K модифицируется по времени.
Такая структура совместимо вписывается в систему PGP c минимальными дополнениями (ключехранилище для K). Оверхед +1 проход на установление связи (по сравнению с обычной PGP). Удобно, практично, просто.

Почтенный gegel, может стоит взять и сделать как дополнительную полезную фичу к PGP.
— gegel (03/10/2014 20:23, исправлен 03/10/2014 20:28)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Инициатор A генерирует одноразовую пару ключей, отвечающая сторона B генерирует общий ключ K для симметрики. Начальная аутентификация средствами PGP. Вся дальнейшая связь и аутентификация A и B осуществляется на ключе K.

Очень абстрактно. На вскидку атака:


– Инициатор A генерирует одноразовую пару ключей;
– Подписывает временный публичный ключ и отсылает его B
– Ева перехватывает, переподписывает, и отсылает его B, выдавая за свой;
– B получает, генерирует K, шифрует с помощью полученного ключа и отсылает E. E в неизменном виде пересылает А.
В итоге классическая UKS: А считает, что общается с B, и общается с ним на самом деле. B считает, что общается с E, но общается с А.


Про отрицаемость в предложенной схеме вообще речь не идет. Об самоизлечении – тоже (при утечке симметричного ключа на каком-то этапе все последующие сообщения будут скомпрометированы даже для пассивного атакующего).
Хотя похожий протокол (на однонаправленной хеш-функции) используется в Циммермановском SilentCircle.


PS: Keccak sponge wrap – это режим аутентифицируемого шифрования с использованием Keccak Sponge. Хеш-функция – просто Keccak.

— ZAS_ (03/10/2014 21:06)   <#>
Инициатор A генерирует одноразовую пару ключей, отвечающая сторона B генерирует общий ключ K для симметрики. Начальная аутентификация средствами PGP. Вся дальнейшая связь и аутентификация A и B осуществляется на ключе K.



– Инициатор A генерирует одноразовую пару ключей;
– Подписывает временный публичный ключ и отсылает его B
– Ева перехватывает, переподписывает, и отсылает его B, выдавая за свой;


Начальный обмен одноразовой парой закрыт и аутентифицирован долговременными PGP ключами A и B. Последующий обмен на ключе K тоже может быть инкапсулирован в PGP почту.

(при утечке симметричного ключа на каком-то этапе все последующие сообщения будут скомпрометированы даже для пассивного атакующего).


Большое преимущество по сравнению с обычной PGP, когда в случае утечки ключа скомпрометированы все сообщения.
Причем с сохранением совместимости, минимально возможным оверхедом/неудобством и малыми изменениями.

Про отрицаемость в предложенной схеме вообще речь не идет. Об самоизлечении – тоже


После того как установлен начальный контакт на ключе K, мы можем периодически переустанавливать ключ с помощью той же процедуры с одноразовой парой ключей. Причем делать это автоматически, на фоне идущей переписки.

Вспоминается популярная песня из детства с припевом "Пусть лучше будет хуже чем не будет совсем" (не помню кто пел).
— unknown (19/01/2015 11:22, исправлен 19/01/2015 11:25)   профиль/связь   <#>
комментариев: 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 и изобретать своё, особенно если такая тема так сложно идёт даже у продвинутых теоретиков.

— ZAS (20/01/2015 20:24)   <#>
Вспоминается популярная песня из детства с припевом "Пусть лучше будет хуже чем не будет совсем" (не помню кто пел).


авторы интересно рассматривают One-Round Key Exchange (ORKE) и Non-Interactive Key Exchange (NIKE)


Они рассматривают другой класс протоколов; а у Вас, как всегда, нет аргументов по сути дела.

В очередной раз убеждаюсь: единственное, что приходит в голову после чтения таких работ — самопальные протоколы сразу в топку, нечего страдать NIH и изобретать своё,


Когда-то был большой проект, в котором, помимо многого прочего, нужно было разработать схему помехоустойчивого кодирования. На соседней кафедре был профессор с мировым именем в теории кодов. Обратились к нему. Ничего они не сделали, в результате пришлось все делать самим. Получилось довольно коряво, однако работоспособно. C позиции нынешних знаний, конечно, следовало бы сделать не то и не так, но Карла Маркс нас учил что практика – критерий истины. Такие дела.

http://www.zas-comm.ru
— Гость (20/01/2015 20:42)   <#>

Как определили работоспособность? Слили схему кодирования противнику и в реальной войне он не смог заглушить канал? Да даже если и так, означает ли это, что в следующей войне он не заглушит?

Когда практика столкнётся с неумолимой теорией, стелить соломку будет поздно. В таком темпе можно и вечные двигатели изобретать, пока лох деньги несёт, и защиту от копирования (пока её не сломали) и всё остальное. У ZAS'а промытые мозги по самое нехочу. Понимания нет, а гонора выше крыши.
На страницу: 1, 2, 3, 4, 5, ... , 16, 17, 18, 19, 20 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3