GPG в недружественной среде
Здравствуйте!
Вопрос: Имеет ли возможность отправитель данных узнать сессионный ключ в самом банальном случае
gpg -e -r someoneelse somedata
с целью уличить получателя gpg сообщения в нечестности, если он "отказывается" расшифровывать ваше сообщение, под предлогом "испорченности сообщения".
Спасибо!
комментариев: 1060 документов: 16 редакций: 32
Третий раз: в текущем суррогате на основе openpgp мучений больше. Пусть даже они и кажутся простыми.
комментариев: 11558 документов: 1036 редакций: 4118
Я говорю даже не о целенаправленных атаках корреспондента или о его сговоре с атающим, а о случайных ошибках на стороне корреспондента. То, что Вы предлагаете, опасно именно с этой точки зрения. Сторонам нетрудно договориться не писать историю, но труднее договориться и реализовать надёжное удаление подключей OpenPGP с диска.
Странная постановка вопроса. По-моему, если вероятность события невысока, то нет смысла вообще городить огород, на котором в процессе реализации можно неочевидным образом подорваться. Можно просто использовать PGP с регулярно заменяемыми подключами, только не надо называть это PFS.
Опять же, полностью согласен с sentaus'ом. Вы пытаетесь приспособить некий механизм для целей, для которых он не создавался.
Тогда это уже по определению не opportunistic, а обычное начало протокола с согласованием параметров. Опять же, разговор о том, как могло или не могло быть, надо адресовать разработчикам. (Мне например, сходу не понятно, как бы плагин мог произвести такое согласование. Слать какие-то данные, не спрашивая пользователя? В какой момент? Тут много неочевидных нюансов.)
А в OTR нельзя писать в оффлайн, что с лихвой компенсирует весь недостаток мучений. :-) Согласованно сменить раз в месяц или год подключи, по-моему, проще, чем каждый день мучиться с тем, что в оффлайн не напишешь, а выхода абонента в онлайн можно ждать часами. Конечно, на пожарный случай можно писать и в оффлайн, шифруя сообщения с помощью PGP руками и применяя опцию -R, но это геморрой. И расшифровывать их потом руками тоже геморрой.
Я потому сразу сказал, что спор скорее терминологический. :-) Основная цель — отмывать ключ, который загрязнён большим количеством прошедшей через него информации. Если этого не делать совсем (не менять подключи), то рано или поздно на нём накапливается столько грязи, что это катастрофа. И все до одного секрета (в том числе, давно стёртые с дисков) остаются завязаными на один ключ. Вот этого и хотелось избежать в самую первую очередь. Всё остальное опционально.
В «обычном начале протокола с согласованием параметров» (допустим, политика always) если что-то не работает или не поддерживается, то не будет отослано ничего, в мной же предложенном случае сообщение отошлётся открытым текстом (как первое, так и последующие). Однако, они реализовали opprtunistic по-другому — так, что первое сообщение пойдёт открытым текстом даже тогда, когда всё ОК, работает и поддерживается у обеих сторон. Вот этот момент я и не могу понять. Почему бы не сделать этот конкретный случай (всё ОК, работает и поддерживается у обеих сторон) идентичным always?
В opportunistic при попытке отослать первое сообщение online-контакту производится попытка установить OTR-канал и согласовать параметры. Если она срабатывает, то дальше идёт OTR, если нет, то plain text'ом. Т.е. алгоритм, думаю ясен. Вроде как именно такой механизм подразумевается в документации, но у меня лично опыта работы с opportunistic
малонет совсем.комментариев: 9796 документов: 488 редакций: 5664
Именно для того протокол и создавался, что после того как согласован симметричный ключ аутентификации, абонент может насочинять посредством этого ключа любые произвольные сообщения.
Это напоминает идею кольцевых подписей, которую хотелось бы видеть реализованной в GnuPG: общая кольцевая подпись вида "сообщение подписано или A, или B, или обоими A+B, но точный ответ неизвестен", причём такую подпись можно делать без согласования и без разрешения включать кого-то в своё кольцо. Если сторона B получает такое сообщение от A, то она знает, что оно подписано A, т.к. сама сторона B его не подписывала, сама себе не отсылала и раздвоением личности не страдает. А третьей стороне это уже не доказать.
В OTR также, только PFS+OTR+{более гибкая аутентификация} в одном флаконе: согласовали сеансовый симметричный ключ, отвязали его от сеанса асимметричного согласования (на нём самом чей-либо подписи не стоит, а согласование происходит одновременно, т.к. последний шаг вывода симметричного ключа из вычислений по параметрам DH-сессии делается обеими сторонами параллельно), для шифрования и аутентификации (или для шифрования и аутентификации выводятся два разных симм. ключа?) и он симметрично аутентифицирует сообщения. Каждая сторона знает, что то, что не аутентифицировала она, аутентифицировано другой стороной. А для третьей стороны это недоказуемо: кто из двух мог подделать аутентификацию и подделывал ли вообще.
Идея в том, что технически они для третьей стороны не аутентифицированы. То, что вы называете "юридической отрицаемостью" просто опять же, ваша специфическая модель угрозы. OTR задумывалось не для вашего сценария, а для другого. Например, вы переписывались с известным чеовеком, а затем слили его откровения в паблик. Если они подписаны или строго аутентифицированы, то все вам поверят. Если используется OTR, то ваш слив
засчитаннедоказан — вы могли полностью сочинить или исказить текст переписки.Вас же интересует юридическая отрицаемость в плане защиты самого себя на неких следственно-судебных-розыскных мероприятиях. Здесь если только свой скрытый сервис в Tor подымать со своим Jabber-cервером и покрывающим трафиком (или аналогом Torchat). Но городить протокол на коленке, тем более только со своей стороны, смысла нет.
Кстати, записываемости в OTR нет ещё и чисто идеологически. Раз разглашение переписки недоказуемо, то нечего её записывать, вдруг будет случайная утечка, лучше поговорить и сделать вид, что ничего не было. А раз сторона предприняла меры к записи, то она делала это злонамеренно, её можно обвинить в том, что она пыталась выудить компромат из переписки и она также могла заранее предпринять меры к подделке сообщений. Как и в каких сценариях это (не)прокатит юридически, выше уже рассмотрено, в т.ч. и в вашем сообщении.
В идеале — да, и этот вопрос тоже прорабатывается. Суть в том, что не получится сделать так, чтобы у каждого абонента был свой jabber-сервер на скрытом ресурсе — это несовместимо с особенностями XMPP-протокола из-за его глубинной завязки на продвинутые фичи DNS. Единственное, что можно сделать — поставить один jabber-сервер на каком-то скрытом ресурсе и заставить всех регистрироваться именно на нём; на другие jabber-сервера он передавать сообщения не сможет.
Естественно, сервер нужен, потому что хочется иметь возможность писать в оффлайн, когда один из клиентов вообще физически не подключен к сети. При этом возникает плата за сообщения в оффлайн — третья сторона (пусть даже и анонимная, но всё же), который хранит весь список контактов, через неё проходят все сообщения (пусть даже шифрованные) и т.д., в то время как в идеале хотелось бы чего-то типа P2P-мессенджера без третьей (и в каком-то смысле доверенной) стороны. Всё трудно и непросто, и даже чисто идеологически неясно, как правильно строить защиту.
«Протокол» — это слишком громко звучит для процедуры «сменять подключи время от времени». Вон, посмотрите, даже SATtva подключи меняет; можете считать, что я у него понабрался.
Может, вы хотели сказать про запись сенасовых или временных ключей, а не переписки? Всё-таки запись переписки — ортогональная вещь к её шифрованию. В jabber-клиентах это регулируется разными опциями, никак друг с другом несвязанными, да и запись обычно ведётся не для злонамеренности, а для упрощения использования переданной информации во вполне легитимных целях (иначе пришлось бы всё, что хоть сколь-нибудь важно и может впоследствии пригодиться, записывать руками во внешний файл). К тому же, при незаписывании переписки при внезапном падении jabber-клиента или проблемах с сетью может быть утеряна важная многочасовая дискуссия, и что тогда? Её заново создавать с нуля?
Сейчас jabber (да и вообще, если глобально, разные IM-системы) заменил фактически все способы коммуникации в силу своей простоты, безопасности, удобства и практичности. Через jabber у кого-то может проходить масса деловой и важной переписки, и незаписывать её вообще — сильно терять в практичности. В общем, jabber — это не «привет, как дела?», которые нестрашно потерять, поэтому разумно вручную разбирать переписку и удалять её только после экстрагирования важных сведений во внешние файлы.
Они тут пишут:
Честно сказать, мне лень сейчас глубоко задумываться о том, безопасен ли их протокол, но у меня есть сомнения, касающиеся того, как эти «100 prekeys» дружат с отрицаемостью и PFS, случись что. Безопасность их метода может быть и хуже, но это не страшно, если все понимают и отдают себе отчёт в том, от чего защищает канонический OTR, но не защищает их метод.
засчитаннедоказан — вы могли полностью сочинить или исказить текст переписки.На одном известном примере все могли убедиться, что технические доказательства мало кого волнуют, даже если есть очевидные сомнения в их валидности. Насколько мне известно, полный детальный технический разбор ситуации так никто и не сделал. Всё это ещё раз подталкивает к тем мыслям о юридической отрицаемости, которые я озвучил. С большой вероятностью фактическое убеждение третьей стороны в истиности переписки будет вестись методом «кто громче заявит», «о чём скажут по телевизору» и «чей PR будет чернее», при этом лишь единицы заинтересуются деталями технических нюансов.
P.S. Я нашёл ошибку в GnuPG!