id: Гость   вход   регистрация
текущее время 05:02 18/08/2019
Автор темы: Гость, тема открыта 17/12/2010 17:00 Печать
Категории: анонимность, инфобезопасность, политика
http://www.pgpru.com/Форум/РаботаСGnuPG/GPGВНедружественнойСреде
создать
просмотр
ссылки

GPG в недружественной среде

Здравствуйте!
Вопрос: Имеет ли возможность отправитель данных узнать сессионный ключ в самом банальном случае
gpg -e -r someoneelse somedata
с целью уличить получателя gpg сообщения в нечестности, если он "отказывается" расшифровывать ваше сообщение, под предлогом "испорченности сообщения".
Спасибо!


 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— sentaus (27/09/2013 11:51, исправлен 27/09/2013 11:52)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Стоит ли так мучиться со стандартным OTR, если вероятность такого развития событий достаточно мала? Может, целесообразней заменить OTR суррогатом с временными ключами?

Третий раз: в текущем суррогате на основе openpgp мучений больше. Пусть даже они и кажутся простыми.

— SATtva (27/09/2013 12:07, исправлен 27/09/2013 12:10)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4090
В зависимости от модели угрозы (а она у Вас, насколько понимаю, очень жёсткая), схема PFS с PGP-ключами получается очень хрупкой, она не выдерживает случайный fuck up со стороны корреспондента или его системы.

В худшем случае противник получит, допустим, историю сообщений, взятую с диска. Этого часто «достаточно» почти для всего. OTR не запрещает писать историю. Кто-то может историю не писать, другие — стирать её время от времени, но смысл остаётся: этот факт непроверяем для другой стороны.

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


Стоит ли так мучиться со стандартным OTR, если вероятность такого развития событий достаточно мала? Может, целесообразней заменить OTR суррогатом с временными ключами?

Странная постановка вопроса. По-моему, если вероятность события невысока, то нет смысла вообще городить огород, на котором в процессе реализации можно неочевидным образом подорваться. Можно просто использовать PGP с регулярно заменяемыми подключами, только не надо называть это PFS.


Опять же, полностью согласен с sentaus'ом. Вы пытаетесь приспособить некий механизм для целей, для которых он не создавался.


Могло бы быть и иначе: при opportunistic клиенты обмениваются служебными пакетами данных, и если установить канал удаётся, то все сообщения, включая первое, отсылаются только после установления OTR-канала; если же клиенты выясняют, что поддержки OTR одна из сторон не имеет, то они не насилуют друг друга и всё шлют без шифрования (как первое сообщение, так и последующие).

Тогда это уже по определению не opportunistic, а обычное начало протокола с согласованием параметров. Опять же, разговор о том, как могло или не могло быть, надо адресовать разработчикам. (Мне например, сходу не понятно, как бы плагин мог произвести такое согласование. Слать какие-то данные, не спрашивая пользователя? В какой момент? Тут много неочевидных нюансов.)

— Гость (27/09/2013 12:29)   <#>

А в OTR нельзя писать в оффлайн, что с лихвой компенсирует весь недостаток мучений. :-) Согласованно сменить раз в месяц или год подключи, по-моему, проще, чем каждый день мучиться с тем, что в оффлайн не напишешь, а выхода абонента в онлайн можно ждать часами. Конечно, на пожарный случай можно писать и в оффлайн, шифруя сообщения с помощью PGP руками и применяя опцию -R, но это геморрой. И расшифровывать их потом руками тоже геморрой.


Я потому сразу сказал, что спор скорее терминологический. :-) Основная цель — отмывать ключ, который загрязнён большим количеством прошедшей через него информации. Если этого не делать совсем (не менять подключи), то рано или поздно на нём накапливается столько грязи, что это катастрофа. И все до одного секрета (в том числе, давно стёртые с дисков) остаются завязаными на один ключ. Вот этого и хотелось избежать в самую первую очередь. Всё остальное опционально.


В «обычном начале протокола с согласованием параметров» (допустим, политика always) если что-то не работает или не поддерживается, то не будет отослано ничего, в мной же предложенном случае сообщение отошлётся открытым текстом (как первое, так и последующие). Однако, они реализовали opprtunistic по-другому — так, что первое сообщение пойдёт открытым текстом даже тогда, когда всё ОК, работает и поддерживается у обеих сторон. Вот этот момент я и не могу понять. Почему бы не сделать этот конкретный случай (всё ОК, работает и поддерживается у обеих сторон) идентичным always?


В opportunistic при попытке отослать первое сообщение online-контакту производится попытка установить OTR-канал и согласовать параметры. Если она срабатывает, то дальше идёт OTR, если нет, то plain text'ом. Т.е. алгоритм, думаю ясен. Вроде как именно такой механизм подразумевается в документации, но у меня лично опыта работы с opportunistic мало нет совсем.
— unknown (27/09/2013 14:26, исправлен 27/09/2013 14:40)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
что может сделать полностью злонамеренный абонент при использовании OTR? Понятно, что он владеет собственным приватным ключом, публичным ключом второй стороны, выхлопами всех шагов протокола DH и результирующим симметричным ключом. Если он всю эту информацию соберёт вместе и выдаст третьему лицу, докажет ли он этим самым, что общался конкретно с тем абонентом, или нет? Вопрос чисто математический

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


Это напоминает идею кольцевых подписей, которую хотелось бы видеть реализованной в GnuPG: общая кольцевая подпись вида "сообщение подписано или A, или B, или обоими A+B, но точный ответ неизвестен", причём такую подпись можно делать без согласования и без разрешения включать кого-то в своё кольцо. Если сторона B получает такое сообщение от A, то она знает, что оно подписано A, т.к. сама сторона B его не подписывала, сама себе не отсылала и раздвоением личности не страдает. А третьей стороне это уже не доказать.


В OTR также, только PFS+OTR+{более гибкая аутентификация} в одном флаконе: согласовали сеансовый симметричный ключ, отвязали его от сеанса асимметричного согласования (на нём самом чей-либо подписи не стоит, а согласование происходит одновременно, т.к. последний шаг вывода симметричного ключа из вычислений по параметрам DH-сессии делается обеими сторонами параллельно), для шифрования и аутентификации (или для шифрования и аутентификации выводятся два разных симм. ключа?) и он симметрично аутентифицирует сообщения. Каждая сторона знает, что то, что не аутентифицировала она, аутентифицировано другой стороной. А для третьей стороны это недоказуемо: кто из двух мог подделать аутентификацию и подделывал ли вообще.


техническая отрицаемость полагается на непроверяемые аргументы типа «абонент не пишет историю сообщений».

Идея в том, что технически они для третьей стороны не аутентифицированы. То, что вы называете "юридической отрицаемостью" просто опять же, ваша специфическая модель угрозы. OTR задумывалось не для вашего сценария, а для другого. Например, вы переписывались с известным чеовеком, а затем слили его откровения в паблик. Если они подписаны или строго аутентифицированы, то все вам поверят. Если используется OTR, то ваш слив засчитан недоказан — вы могли полностью сочинить или исказить текст переписки.


Вас же интересует юридическая отрицаемость в плане защиты самого себя на неких следственно-судебных-розыскных мероприятиях. Здесь если только свой скрытый сервис в Tor подымать со своим Jabber-cервером и покрывающим трафиком (или аналогом Torchat). Но городить протокол на коленке, тем более только со своей стороны, смысла нет.


Кстати, записываемости в OTR нет ещё и чисто идеологически. Раз разглашение переписки недоказуемо, то нечего её записывать, вдруг будет случайная утечка, лучше поговорить и сделать вид, что ничего не было. А раз сторона предприняла меры к записи, то она делала это злонамеренно, её можно обвинить в том, что она пыталась выудить компромат из переписки и она также могла заранее предпринять меры к подделке сообщений. Как и в каких сценариях это (не)прокатит юридически, выше уже рассмотрено, в т.ч. и в вашем сообщении.

— Гость (28/09/2013 00:39)   <#>
Про OTR и писание в оффлайн, это решаемо. Например, так же как решили сделать в «TextSecure» — обычный «prekey».
— Гость (28/09/2013 02:19)   <#>

В идеале — да, и этот вопрос тоже прорабатывается. Суть в том, что не получится сделать так, чтобы у каждого абонента был свой jabber-сервер на скрытом ресурсе — это несовместимо с особенностями XMPP-протокола из-за его глубинной завязки на продвинутые фичи DNS. Единственное, что можно сделать — поставить один jabber-сервер на каком-то скрытом ресурсе и заставить всех регистрироваться именно на нём; на другие jabber-сервера он передавать сообщения не сможет.

Естественно, сервер нужен, потому что хочется иметь возможность писать в оффлайн, когда один из клиентов вообще физически не подключен к сети. При этом возникает плата за сообщения в оффлайн — третья сторона (пусть даже и анонимная, но всё же), который хранит весь список контактов, через неё проходят все сообщения (пусть даже шифрованные) и т.д., в то время как в идеале хотелось бы чего-то типа P2P-мессенджера без третьей (и в каком-то смысле доверенной) стороны. Всё трудно и непросто, и даже чисто идеологически неясно, как правильно строить защиту.


«Протокол» — это слишком громко звучит для процедуры «сменять подключи время от времени». Вон, посмотрите, даже SATtva подключи меняет; можете считать, что я у него понабрался.


Может, вы хотели сказать про запись сенасовых или временных ключей, а не переписки? Всё-таки запись переписки — ортогональная вещь к её шифрованию. В jabber-клиентах это регулируется разными опциями, никак друг с другом несвязанными, да и запись обычно ведётся не для злонамеренности, а для упрощения использования переданной информации во вполне легитимных целях (иначе пришлось бы всё, что хоть сколь-нибудь важно и может впоследствии пригодиться, записывать руками во внешний файл). К тому же, при незаписывании переписки при внезапном падении jabber-клиента или проблемах с сетью может быть утеряна важная многочасовая дискуссия, и что тогда? Её заново создавать с нуля?

Сейчас jabber (да и вообще, если глобально, разные IM-системы) заменил фактически все способы коммуникации в силу своей простоты, безопасности, удобства и практичности. Через jabber у кого-то может проходить масса деловой и важной переписки, и незаписывать её вообще — сильно терять в практичности. В общем, jabber — это не «привет, как дела?», которые нестрашно потерять, поэтому разумно вручную разбирать переписку и удалять её только после экстрагирования важных сведений во внешние файлы.


Они тут пишут:

The TextSecure Protocol

TextSecure’s upcoming iOS client (and Android data channel client) uses a simple trick to provide asynchronous messaging while simultaneously providing forward secrecy.

At registration time, the TextSecure client preemptively generates 100 signed key exchange messages and sends them to the server. We call these “prekeys.” A client that wishes to send a secure message to a user for the first time can now:

  1. Connect to the server and request the destination’s next “prekey.”
  2. Generate its own key exchange message half.
  3. Calculate a shared secret with the prekey it received and its own key exchange half.
  4. Use the shared secret to encrypt the message.
  5. Package up the prekey id, the locally generated key exchange message, and the ciphertext.
  6. Send it all in one bundle to the destination client.

The user experience for the sender is ideal: they type a message, hit send, and an encrypted message is immediately sent.

The destination client receives all of this as a single push notification. When the user taps it, the client has everything it needs to calculate the key exchange on its end, immediately decrypt the ciphertext, and display the message.

With the initial key exchange out of the way, both parties can then continue communicating with an OTR-style protocol as usual. Since the server never hands out the same prekey twice (and the client would never accept the same prekey twice), we are able to provide forward secrecy in a fully asynchronous environment.

Честно сказать, мне лень сейчас глубоко задумываться о том, безопасен ли их протокол, но у меня есть сомнения, касающиеся того, как эти «100 prekeys» дружат с отрицаемостью и PFS, случись что. Безопасность их метода может быть и хуже, но это не страшно, если все понимают и отдают себе отчёт в том, от чего защищает канонический OTR, но не защищает их метод.


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

P.S. Я нашёл ошибку в GnuPG!
--no-sig-cache
Do not cache the verification status of key signatures. Caching gives a much better performance in key listings. However, if you suspect that your public keyring is not save against write modifications
© man gpg
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3