OpenPGP 加密文件将包含预期收件人的公共加密密钥的密钥 ID,如本问题所述。
有没有办法从生成的加密文件中删除该信息?是否gpg
提供不包含该信息的选项?
如果没有,推荐什么解决方法?我想为特定收件人加密文件并与任何第三方共享,而不会泄露收件人或发件人的身份。
(可以假设接收者的公钥被广泛共享并与接收者的真实身份相关联。)
OpenPGP 加密文件将包含预期收件人的公共加密密钥的密钥 ID,如本问题所述。
有没有办法从生成的加密文件中删除该信息?是否gpg
提供不包含该信息的选项?
如果没有,推荐什么解决方法?我想为特定收件人加密文件并与任何第三方共享,而不会泄露收件人或发件人的身份。
(可以假设接收者的公钥被广泛共享并与接收者的真实身份相关联。)
使用-R
(or --hidden-recipient
) 标志gpg
来执行此操作。此答案中的更多详细信息。
gpg 中有几个选项。请注意,您可以在 gpg.conf 文件中使用所有这些来永久设置它们(通过省略长选项前的“--”,但请注意,--try-secret-key 是仅在版本中可用的选项2.1beta1+,现在已经测试了 3 年。我认为文档是由错误生成的,因为大多数人不会有这个选项):
--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.
--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 recipients 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.
在接收端...请注意,如果您有许多私钥,这可能会特别烦人,因为 gpg 会提示您输入每个私钥的密码,直到找到一个有效的密码。要快速循环显示提示,只需按 Enter 输入错误的键,gpg 不应像这样每个键多次提示您。
接收软件(如邮件客户端)可以采用多种技术来缓解此问题。我所知道的最实用的方法是生成一个临时密钥环,其中的密钥预计是匿名收件人(例如,您收到邮件的电子邮件地址)。如果那个/那些密钥失败,应该在不更改密钥环的情况下再次调用 gpg 以尝试所有用户的密钥。命令如下:
gpg --export-secret-keys <key(s)> > tmp_keyring
gpg --decrypt --no-default-keyring --secret-keyring tmp_keyring <...>
On failure:
gpg --decrypt <...>
以下是选项:
--try-secret-key name
For hidden recipients GPG needs to know the keys to use for trial decryption.
The key set with --default-key is always tried first, but this is often not
sufficient. This option allows to set more keys to be used for trial
decryption. Although any valid user-id specification may be used for name it makes
sense to use at least the long keyid to avoid ambiguities. Note that gpg-agent
might pop up a pinentry for a lot keys to do the trial decryption. If you want
to stop all further trial decryption you may use close-window button instead
of the cancel button.
--try-all-secrets
Don't look at the key ID as stored in the message but try all secret keys in turn
to find the right decryption key. This option forces the behaviour as used by
anonymous recipients (created by using --throw-keyids or --hidden-recipient)
and might come handy in case where an encrypted message contains a bogus key ID.
--skip-hidden-recipients
--no-skip-hidden-recipients
During decryption skip all anonymous recipients. This option helps in the case that
people use the hidden recipients feature to hide there own encrypt-to key from
others. If oneself has many secret keys this may lead to a major annoyance
because all keys are tried in turn to decrypt something which was not really
intended for it. The drawback of this option is that it is currently not possible
to decrypt a message which includes real anonymous recipients.
如果您对隐私感兴趣,您可能会对另一种选择感兴趣。在发送电子邮件时发布您的操作系统和软件版本实际上是无用且对您的隐私非常不利的:
--emit-version
--no-emit-version
Force inclusion of the version string in ASCII armored output. If given once only
the name of the program and the major number is emitted (default), given twice
the minor is also emitted, given triple the micro is added, and given quad an
operating system identification is also emitted. --no-emit-version disables
the version line.
有关安全和隐私的 gpg 最佳实践的一般概述,请查看riseup labs 的此入门。
我不确定您是否可以使用任何特定程序剥离该信息,但我不明白它为什么会导致任何问题。至于变通方法,接收者可以用他们的私钥签署一个新的公钥,用发送者的公钥加密新的公钥,将新的公钥发送给发送者,然后发送者可以使用它进行传输。这样,新的“会话”公钥永远不会向世界公开,也无法将其链接回接收者。
值得注意的是,仍然有可能有人知道收件人与发件人交谈,所以如果你试图阻止任何人知道对话的任何一半,那么这将行不通。
作为一种解决方法,接收者可以准备一个新的公钥(可能使用非常短的到期日期)并使用该公钥加密该文件。因此,即使仍然可以确定文件是为哪个密钥加密的,但该密钥是新的,因此与任何人都没有关联。