Аналог PGP с обеспечением отрицаемости и наперёд заданной секретности оффлайн?
Обсуждение в соседней теме натолкнуло на мысль: существует ли решение, аналогичное PGP и обеспечивающее для оффлайн-сообщений конфиденциальность и аутентификацию, но плюс отрицаемость и наперед заданную секретность (PFS), ну, и, желательно, тихое уведомление о прессинге. Нашел похожий вопрос на crypto.stackexchange: похоже, что готовых решений пока нет. Возможно, где-то на pgpru это уже обсуждалось, или что-то уже появилось?
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 393 документов: 4 редакций: 0
Если честно, я в этом пока ни черта не понимаю, поэтому могу позволить себе незаангажированно пофантазировать, если, конечно, это никого не напрягает.
Это было вступление.
Теперь предположим, что общего секрета у Алисы и Боба нет, и они могут идентифицироваться друг перед другом и перед третьей стороной только своими публичными ключами, проверяемыми по PKI.
Алиса берет текст публичного ключа Боба, дописывает к нему нейтральную метку (например, версию данного протокола), и подписывает. Подпись будет Y.
Далее, как и выше, Алиса отправляет Бобу PGP-сообщение, содержащее X+Y, где X – определенный текст. Получив сообщение, Боб проверяет подпись Алисы и уверен, что X тоже написано ею. Но доказать это третьей стороне он по прежнему не может: Алиса может опровергнуть, сказав, что посылала Y Бобу ранее в контексте совсем другой беседы.
Примечание:
– честная Алиса должна тот час после отсылки сообщения Бобу удалить Y, если она не хочет, чтобы кто-то позже мог выдать Бобу себя за нее.
– честный Боб должен тот час после проверки подписи удалить Y, если он не хочет, чтобы кто-то позже мог представиться ему Алисой.
– но каждый из них может сжульничать, и это недоказуемо.
Пока верно? Если в принципе да, то продолжу.
комментариев: 9796 документов: 488 редакций: 5664
2 SATtva:
Пусть PKA — открытый (публичный) асимметричный ключ стороны A.
SKA — закрытый (секретный) асимметричный ключ.
То что при асимметричном шифровании в нижележащем слое используется симметричное с одноразовым сеансовым ключом для простоты рассматривать не будем.
Сторона A подписывает и шифрует для B пароль: Encrypt_PKB (Sign_SKA (Pass)).
Если им помимо отрицаемости нужно ещё и PFS, то эта исходная шифровка, если будет перехваченной, то она останется зашифрованной долговременными асимметричными ключами, которые могут быть скомпрометированными или которые будут вызывать интерес у противника для выдачи под давлением. Тогда он расшифрует все последуюшие симметрично шифрованные перехваченные сообщения и PFS чисто на симметрике не сработает.
Если стороны согласовывают пароль из двух половинок, то схема чуть сильнее, потому что противнику нужно получить закрытые ключи с обеих сторон, чтобы восстановить начальные кратковременные ключи во всех перехваченных сеансах связи. Но всё равно — привязка кратковременных симметричных ключей к долговременным асимметричным — слабое место. Для PFS, но не для отрицаемости.
Нужны какие-то какие-то аналоги пошагового оффлайнового DH, чтобы отвязаться в переписке от долговременных асимметричных ключей.
Полноценное PFS требует удаления всего использованного для шифрования ключевого материала.
комментариев: 11558 документов: 1036 редакций: 4118
Не выйдет: с ЭЦП выползает такая прекрасная вещь, как метки времени, ломающие отрицаемость беседы. Боб может доказать, что получил сообщение от Алисы, если та специально не подделывала время (а это в общем случае не так). Опять же, зачем эти сложности с открытыми ключами? unknown же выше уже привёл протокол в общем виде. Короче, не совсем понимаю, к чему Вы ведёте.
комментариев: 11558 документов: 1036 редакций: 4118
Да, точно, поспешил с ответом.
комментариев: 9796 документов: 488 редакций: 5664
Она может сразу выслать ему пароль для симметричного шифрования. в первом же сообщении.
Скорее это схема для недоверяющих (потенциально нечестных друг перед другом сторон). Если третья сторона (Ева) перехватывает их сообщения и знает время отправки, то после раскрытия совместного пароля любой стороной она прочтёт всю их переписку, зная, что она подлинная.
Вот если одна из сторон нечестная (хочет раскрыть и опубликовать переписку и доказать её подлинность третьей стороне), но пытается усилить свою доказательность простановкой криптографических штампов времени у третьей стороны — это ей не поможет. Другая сторона может утверждать, что поддельные сообщения заготавливались заранее или делались очень быстро по шаблону.
Но перехватчик Ева знает какие сообщения реально ходили в канале связи, а какие были опубликованы отдельно.
P.S. У меня оказался немного другой взгляд на метки времени.
комментариев: 11558 документов: 1036 редакций: 4118
Тут имеется в виду раскрытие в прямом эфире, при котором Боб сливает Еве содержимое беседы в её процессе. Даже обычная погрешность часов в несколько минут не позволит Алисе утверждать, что это трафик из какой-то совсем посторонней беседы.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Из man gpg:
Т.е. mdc будет использоваться по-умолчанию итак практически всегда. В крайнем случае через можно посмотреть подробный выхлоп присланного сообщения и поискать в нём строку mdc_method.
Тогда, первые два пункта не меняются, остальные можно сделать лучше:
комментариев: 9796 документов: 488 редакций: 5664
С отрицаемостью вроде как всё хорошо. Даже как-то подозрительно и не верится, что всё так просто оказалось.
PFS можно сделать, высылая внутри OpenPGP сообщений одноразовые асимметричные открытые ключи OpenSSL и уничтожая их закрытую часть после использования. Чтобы шифровать сначала OpenSSL, а затем оборачивать OpenPGP. Правда это уже костыли и подпорки.
комментариев: 393 документов: 4 редакций: 0
Я держал в уме общение через TorChat-сервер, когда писал. Если Ева контролирует трафик обоих, то, боюсь, что-то отрицать не получится, даже без его расшифровки.
Без своей подписи? Если подпишет, теряется отрицаемость, если нет – доверие к паролю со стороны Боба. Предполагаем – общего секрета пока нет.
Вот об этом даже не догадывался. Ну, тогда вместо ЭЦП Алиса может зашифровать текст публичного ключ Боба + версию протокола своим закрытым ключом (надеюсь, в OpenPGP это возможно) и вложить в сообщение: та же подпись, но без меток времени. Она проверяется расшифровкой ее публичным ключом.
К этому и веду. Расшарить с отрицанием хочу не симметричный ключ, а аутентификатор для последующих общих секретов DH:
Теперь все точно как и в предыдущий раз, но в начале Алиса генерирует временную пару ключей. X – публичний ключ из этой пары. Также Алиса придумывает случайный тег аутентификации, хеширует и добавляет к первому сообщению его хеш H. Также Алиса берет текст публичного ключа Боба, дописывает к нему нейтральную метку (например, версию данного протокола), и шифрует своим приватным ключем. Результат будет Y. Отправив сообщение, Алиса тот час удаляет Y.
Боб, получив сообщение проверяет Y и, удостоверившись, что оно написано Алисой, удаляет Y, сохраняет H, придумывает свой тег, шифрует его полученным в сообщении временным ключом и отправляет Алисе.
Алиса уверенна, что ответ пришел от Боба (т.к. ключ она посылала только ему). Но доказать третьей стороне она не сможет, т.к. вполне могла сама себе послать это сообщение. Теперь Алиса отправляет Бобу сообщение, содержащее свой ранее придуманный тег.
Получив его, Боб сверяет хеш тега Алисы и теперь уверен, что этот тег был придуман именно ею.
Алиса и Боб ксорят теги. Теперь у них них есть общий секрет всего за три хопа с использованием PGP при двухсторонней отрицаемости. В дальнейшем он будет использоваться для аутентификации DH-секретов (анти-MitM) с сохранением отрицаемости на случай, если один из участников соберет DH-материал с целью восстановить цепочку и скомпроментировать второго, доказав, что он аутентифицировал текущий общий секрет DH. Необходимости в PGP больше нет.
Если до этого места в рассуждении явных ляпов нет, я составлю более-менее человеческое описание всего протокола (вместе с DH-стадией) и выложу на обсуждение.
комментариев: 393 документов: 4 редакций: 0
Обязательно вывести из половинок, т.к. сторона, назначающая ключ, может в качестве него подсунуть хеш от заявления, удостоверивающего ситуацию, а затем доказать, что другая сторона использовала именно этот ключ. Отрицаемость теряется.
комментариев: 9796 документов: 488 редакций: 5664
Со своей подписью конечно. Теряется отрицаемость только факта инициализации самого сеанса связи, но не теряется отрицаемость написанного. Так будет с любым протоколом где нет имеющегося заранее общего секрета.
Остальную часть вашего поста может быть разберу позднее.
комментариев: 9796 документов: 488 редакций: 5664