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

Вторая половина фразы не соответствует действительности.

правильно ли я понимаю, что Symmetric Ciphers, не работают в batch mode?
как написать скрипт который скормит им passphrases, или их нужно обязательно вводить вручную?

Целых три варианта (помимо ручного ввода):

man gpg --passphrase-fd n Read the passphrase from file descriptor n. Only the first line will be read from file descriptor n. If you use 0 for n, the passphrase will be read from STDIN. This can only be used if only one passphrase is supplied. Note that this passphrase is only used if the option --batch has also been given. This is different from gpg. --passphrase-file file Read the passphrase from file file. Only the first line will be read from file file. This can only be used if only one passphrase is supplied. Obvi- ously, a passphrase stored in a file is of questionable security if other users can read this file. Don't use this option if you can avoid it. Note that this passphrase is only used if the option --batch has also been given. This is different from gpg. --passphrase string Use string as the passphrase. This can only be used if only one passphrase is supplied. Obviously, this is of very questionable security on a multi-user system. Don't use this option if you can avoid it. Note that this passphrase is only used if the option --batch has also been given. This is different from gpg.

для некоторого сообщества, регулярно участвующих в опросах, хочется поставить "локальный" кей-сервер с веб интерфейсом, то есть такой в который авторизованные ключи можно было бы добавлять руками, а возвращать через веб. Другими словами как сделать видимым public-key-ring на host1 через веб? Наверное, есть удобная реализация?

Либо полноценный SKS^[link1], либо писать собственную веб-морду с бэк-эндом в виде GPG (примерно как сделано на нашем сайте). Вероятно, второй вариант Вам больше подойдёт.

Насколько скомпрометирована (идентифицируема) будет личность отправителя если сообщение закриптовано комбинацией опций
gpg -e --default-recipient-self --hidden-recipient key2 message
при условии доступности информации с public-key-ring

Она будет скомпрометирована полностью, т.к. --default-recipient-self впишет в пакет сообщения его собственный keyID. Вместо --default-recipient-self используйте в данном случае --hidden-encrypt-to senderKeyID.

Вообще в Вашем случае желательно проверять, какие метаданные утекают через поля OpenPGP-пакетов. /Сервисы/PacketDump^[link2] Вам в помощь.

Если сообщение было зашифровано только для -r someoneelse — нет.

Давайте посмотрим на схематическом уровне как это работает: отправитель генерит случайный пароль для AES (по умолчанию), оным сообщение шифруется, затем сам пароль шифруется публичным ключом адресата.

Генерируется сеансовый ключ, который зашифровывается открытым ключом получателя. Подумайте, каким образом отправитель теперь может восстановить этот сеансовый ключ, не имея доступа к закрытому ключу получателя?

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

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

1. Может ли посторонний (тот, кто не адерсат сообщения) сказать, каким ключом подписан текст, зашифрованный как gpg --no-emit-version -es или gpg --no-emit-version -es?
2. Тот же вопрос, что и в п.1, при условии дополнительной опции --hidden-recipient.
3. Тот же вопрос, что и в п.2, но при условии нескольких адресатов (часть публичные, а часть — скрытые).
4. Если адресатов несколько, можно ли сделать так, чтобы подпись на сообщении была видна только некоторым (публичным и/или скрытым) из них? Если да, то как?
5. В man gpg говорится

   This option helps to hide the receiver of the message and is a limited countermeasure against traffic analysis.

   Какие подводные камни скрыты за словами "limited countermeasure"?

--throw-keyids

--no-throw-keyids

Do not put the recipient key IDs into encrypted messages. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis. ([Using a little social engineering anyone who is able to decrypt the message can check whether one of the other recip‐ ients is the one he suspects.]) On the receiving side, it may slow down the decryption process because all available secret keys must be tried. --no-throw-keyids disables this option. This option is essentially the same as using --hidden-recipient for all recipients.

--hidden-recipient name

-R

Encrypt for user ID name, but hide the key ID of this user's key. This option helps to hide the receiver of the message and is a limited countermeasure against traffic analysis. If this option or --recipient is not specified, GnuPG asks for the user ID unless --default-recipient is given.

--hidden-encrypt-to name

Same as --hidden-recipient but this one is intended for use in the options file and may be used with your own user-id as a hidden "encrypt-to-self". These keys are only used when there are other recipients given either by use of --recipient or by the asked user id. No trust checking is performed for these user ids and even disabled keys can be used.

Using a little social engineering anyone who is able to decrypt the message can check whether one of the other recipients is the one he suspects.

The --hidden-recipient (or -R) command encrypts to a user, but hides the identity of that user. This is the same functionality as --throw-keyid, but can be used on a per-user basis.

intended for use in the options file?

may be used with your own user-id as a hidden "encrypt-to-self".

These keys are ... these user ids

These keys are only used when there are other recipients given

No trust checking is performed for these user ids and even disabled keys can be used?

https://www.pgpru.com/Форум/РаботаСGnuPG/GPGВНедружественнойСреде

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

Может ли посторонний (тот, кто не адерсат сообщения) сказать, каким ключом подписан текст, зашифрованный как gpg --no-emit-version -es или gpg --no-emit-version -es?

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

Тот же вопрос, что и в п.1, при условии дополнительной опции --hidden-recipient.
Тот же вопрос, что и в п.2, но при условии нескольких адресатов (часть публичные, а часть — скрытые).

Аналогично.

Если адресатов несколько, можно ли сделать так, чтобы подпись на сообщении была видна только некоторым (публичным и/или скрытым) из них? Если да, то как?

Отправить разным группам адресатов разные сообщения: одно с подписью, другое — без.

Какие подводные камни скрыты за словами "limited countermeasure"?

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

Отличия и тонкости этих опций мне не совсем понятны.

--throw-keyids применяется ко всем ключам получателей (не уверен, однако, как она сочетается с --encrypt-to-self), --hidden-recipient — только к указанным ключам, --hidden-encrypt-to — только к ключу отправителя (главный нюанс тут в том, что gpg не проверяет уровень достоверности данного ключа). Сам функционал опций обеспечивается идентично, так что и оговорка в квадратных скобках применима к каждой.

Кстати, почему-то собственный ключ не является по умолчанию помеченным, как доверенный с cert-level=3. Gnupg же видит, что есть секретный ключ для заданного, но при проверке подписи всё равно ругается на недоверенность. Так сделано на случай расшаривания секретного ключа между группой людей что ли?

GnuPG автоматически даёт локально генерируемым ключам уровень доверия "ultimate". Собственный ключ может не иметь установленного уровня доверия, только если был импортирован с другой системы (или если по каким-то причинам был утрачен trustdb.gpg). Наличие или отсутствие закрытого ключа в данном случае роли не играет.

Отслеживание самого сообщения

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

В смысле анонимности его передачи по интернету? Есть же Tor.

Раз доверие строится на подписях, а они импортируются, то в чём отличие импортированного приватного ключа от сгенерённого?

Если добавить строку throw-keyids в gpg.conf, то опция будет применяться по умолчанию ко всем шифровальным операциям, так?

Как оно подружится с PGP в jabber?

Отслеживание самого сообщения

В смысле анонимности его передачи по интернету? Есть же Tor.

Достоверность распространяется через подписи. Доверие — свойство ключа, которое gpg хранит в файле trustdb.

При сокрытии ID-ключа владелец файлообменника не должен определить — это несколько раз обменивались файлами два одинаковых анонима (т.е. фактически псевдонимы) или каждый раз были разные анонимы.

расшаривание секретного ключа между группой людей?

Достоверность — уверенность в том, что ключом с некоторым user id действительно владеет персона, указанная в user id (ФИО, ящик и т.п.), а что такое тогда доверие?

Доверие – уверенность в том, что ключи, подписанные данной персоной, являются достоверными. Почитайте /biblioteka/osnovy/setjdoverija^[link7], там это расписано.

throw-keyids защищает анонимов от владельца файлообменника?

Да. Если пакет был зашифрован с этим параметром, то в него не будут добавлены идентификаторы открытых ключей, которые использовались для шифрования. Как следствие, сторонний наблюдатель не сможет установить, какими ключами можно осуществить расшифровку.
Минус тут только один – при расшифровке надо пытаться расшифровывать каждым своим закрытым ключом каждую копию сеансового ключа из пакета, но gpg это делает абсолютно прозрачно.

Достоверность — уверенность в том, что ключом с некоторым user id действительно владеет персона, указанная в user id (ФИО, ящик и т.п.), а что такое тогда доверие?

Доверие – уверенность в том, что ключи, подписанные данной персоной, являются достоверными. Почитайте https://www.pgpru.com/biblioteka/osnovy/setjdoverija, там это расписано.

1. Я сам подписал для себя чей-то ключ с каким-то уровнем сертификации (--ask-cert-level) от 0 до 3ёх и никому об этом не сообщил. Подпись нужна только для меня лично, когда я работаю со своей связкой ключей.
2. Я доверяю импортированному ключу на основе того, что он подписан с какими-то уровнем сертификации теми дургими ключами, которым я в какой-то мере доверяю (сеть доверия).

Ваше определение достоверности(validity) вполне вменяемо:

Достоверность — уверенность в том, что ключом с некоторым user id действительно владеет персона, указанная в user id (ФИО, ящик и т.п.)

Достоверность – это свойство ключа.

Доверие(trust) – уверенность в том, что ключи, подписанные данной персоной, являются достоверными. Это характеристика личности, владеющей соответствующим ключом, с ВАШЕЙ точки зрения.
Например:
1)У меня есть достоверный ключ Васи. Я доверяю Васе, следовательно все ключи, которые подпишет Вася, будут для меня достоверными автоматически.

2)У меня есть достоверный ключ Пети. Но я не доверяю Пете, я знаю, что он подписывает все подряд ключи, и выставляю ему untrusted, и поэтому его подписи на ключах третьих лиц не будут делать эти ключи достоверными.

1. Я сам подписал для себя чей-то ключ с каким-то уровнем сертификации (ask-cert-level) от 0 до 3ёх и никому об этом не сообщил. Подпись нужна только для меня лично, когда я работаю со своей связкой ключей.

Тут есть только достоверность. Предполагается, что вы ключ проверили и считаете его достоверным.

Я доверяю импортированному ключу на основе того, что он подписан с какими-то уровнем сертификации теми дургими ключами, которым я в какой-то мере доверяю (сеть доверия).

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

Доверие(trust) – уверенность в том, что ключи, подписанные данной персоной, являются достоверными.

Собственный ключ может не иметь установленного уровня доверия, только если был импортирован с другой системы (или если по каким-то причинам был утрачен trustdb.gpg). Наличие или отсутствие закрытого ключа в данном случае роли не играет.

Получается, доверие к некоторому ключу — это степень трансляционности достоверности этого ключа на достоверность других ключей, им подписанных (при использовании сети доверия).

И как мне сделать собственный ключ доверенным, если он был импортирован c другой системы?

Да всё так. Своему собственному ключу нужно выставить ultimate доверие – он при этом автоматически станет достоверным, и всё, что им подписано, признаётся достоверным. ultimate можно выставить и на открытый ключ без закрытого, только смысла это особого не имеет, если только этот открытый ключ не ваш (а закрытого вдруг по каким-то причинам нет). В общем, его нужно ставить только на свои ключи. :)

Наверное, там как-то так: если собственный ключ (к которому имеется и закрытый) не помечен, как доверенный, то его подпись на его же открытом ключе не расценивается, как влекущая за собой достоверность этого (открытого) ключа. Даже не могу понять: логично такое поведение или алогично, что из этого следует, и зачем так сделали.

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

Нет, от наличия/отсутствия закрытого ключа ничего не зависит, только от выставленного ultimate доверия.

Своему собственному ключу нужно выставить ultimate доверие – он при этом автоматически станет достоверным, и всё, что им подписано, признаётся достоверным

Вот как раз это и вызывает вопрос (почему так сделали?).

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

sentaus только что ведь исчерпывающе ответил

IF приватный ключ есть
THEN делаем ключевую пару trust=5
ELSE проверяем значение trust для имеющегося публичного ключа
END

Может быть приватный ключ украден (скопирован без ведома автора), публично распостранён, но не отозван как скомпрометированный. Его можно скачать и поэкспериментировать с ним. Но доверия к его подписям и шифровкам нет уже никакого.

Имеет ли возможность отправитель данных узнать сессионный ключ в самом банальном случае
gpg -e -r someoneelse somedata

Jabber-клиент сам по ему одному ведомым законам вызывает gpg для шифрования сообщений.

Соответственно, механическая замена самого gpg не поможет — надо ещё парсить и распознавать опции, с которыми gpg запускается jabber-клиентом, а я вообще без понятия, каковы эти опции.

1. Жёсткая завязка на AES-128, который не поменять даже на AES-256.
2. Нельзя писать в оффлайн.
3. Поддержка OTR менее (IMHO) распространена среди jabber-клиентов, чем PGP.
4. Требуются дополнительные телодвижения по сверке отпечатков. Всё равно на практике доверие, как правило, устанавливается через PGP, и только через него уже — к отпечаткам ключей OTR.

OTR — это тоже не самое умное решение хотя бы потому, что там

1. Это не столь существенная проблема. Серьёзно, проблема из пункта 2 куда более существенна на практике.
2. Это последствия мер против всяких атак с повторной передачей сообщения. Кстати, openpgp для джаббера не предусмотрено стандартного способа передачи шифрованных+подписанных сообщений. В принципе, очевидный костыль вкручивается легко, только кто ж его сам сделает при реализации XEP?

Для PFS в PGP можно время от времени менять подключи шифрования.

Подключи в OpenPGP не дают свойства PFS

<> не стоит. По сравнению с <>. Вначале для <>. А потом <>. Вплоть до <> мессаджа. О том, что <>.»

не стоит по сравнению с <> вначале для <>, а потом <> вплоть до <> мессаджа о том, что <>.

It is often used as a cryptographic protocol that allows two parties to verify the identity of the remote party through the use of a shared secret, avoiding a man-in-the-middle attack without the inconvenience of manually comparing public key fingerprints through an outside channel. In effect a relatively weak password/passphrase in natural language can be used. ∎^[link12]

мог бы ведь юзать ключ тот, который был в последнем сеансе, технически это ничему бы не противоречило, достаточно договориться о стандарте. ∎^[link13]

при первом же следующем выходе абонента в онлайн ключи могли бы меняться на другие [rekeying или как там это в протоколах называется, ротация ключей короче ;)] ∎^[link14]

Первые два пункта разруливаются нестандартными велосипедами, но для этого надо писать код и положить орган на несовместимость с другими клиентами.

А что, в OTR сообщения подписываются и есть защита от переотправок?

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

Если он всю эту информацию соберёт вместе и выдаст третьему лицу, докажет ли он этим самым, что общался конкретно с тем абонентом, или нет

Вообще нет. MAC может сгенерировать любая сторона.

Разработчики tkabber, вестимо. Им плевать на XEP.

В общем, всё плохо с совместимостью. Примерно как с браузерами во времена IE.

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

Это всё ручное, приходится фактически реализовывать протокол в своей голове. Собственно, это и есть самая большая трудность.

Тем не менее, никто не запрещает создать специальный анонимный PGP-ключ, передать его абонентам по шифрованному каналу, попросив абонентов не выкладывать его на сервера ключей, а потом сверху ещё и включить throw-keyids.

Либо вообще юзать gpg/pgp-шифрование внутри OTR-сессии.

Да, тоже можно, хотя это и не будет полноценным OTR в том смысле, что злонамеренный абонент в этом случае имеет все те же рычаги, что и при голом PGP без OTR.

Какой-то терминологический спор получается. Что конкретно вы понимаете под PFS? Невозможность расшифровать старые сообщения? Это гарантируется тем, что подключи время от времени отзываются, копии их отовсюду удаляются, а на связку добавляются новые подключи.

Если же вы под PFS понимаете невозможность доказать авторство (в том смысле, в каком оно есть в OTR), то это тоже решается.

Это всё ручное, приходится фактически реализовывать протокол в своей голове. Собственно, это и есть самая большая трудность.

(process:XXXX): GLib-CRITICAL **: g_hash_table_foreach: assertion `version == hash_table->version' failed

(default|jid) (plain|manual|opportunistic|always)

Sets either the default policy or the policy for the given jid The plain policy should never be used, because you won’t be able to receive or send any OTR encrypted messages. If you set the policy to manual, you or your chat partner have to start the OTR encryption by hand (e.g. with /otr start). The policy "opportunistic" does that itself by sending a special whitespace-sequence at the end of unencrypted messages. So the other OTR-enabled chat client knows, that you want to use OTR. Note that the first message will always be unencryted, if you use this policy. With the policy "always" no message will be sent in plain text. If you try to sent the first message unencrypted, mcabber will try to establish an OTR channel. Please resend your message, when you get the information that the channel was established. If someone sends you plaintext messages while the policy is set to "always", you’ll be able to read the message but it won’t be saved to the history.

© man mcabber

Вроде бы для always проблемы первого сообщения нет, но всё равно остаётся какое-то чувство неуверенности. И в чём отличие opportunistic от always?

По-видимому, в том, что opportunistic даёт сигнал отвечающей стороне инициировать OTR-сессию, если там в клиенте есть поддержка OTR, но если поддержки нет, отвечающая сторона сможет прочитать сообщение; always же принудительно запускает OTR-сессию отправителем: если отвечающая сторона не поддерживает OTR, то прочитать ничего не сможет.

Для работы с оффлайном OTR мог бы иметь отдельный ключ, который бы менялся только во время online-сессий, а шифрование сообщений, посылаемых в online, могло бы происходить так же, как оно работает сейчас.

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

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

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

В зависимости от модели угрозы (а она у Вас, насколько понимаю, очень жёсткая), схема PFS с PGP-ключами получается очень хрупкой, она не выдерживает случайный fuck up со стороны корреспондента или его системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

--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