web-dev-qa-db-ja.com

受信者のキーIDを含めずにgpgを使用してファイルを暗号化するにはどうすればよいですか？

この質問 で説明されているように、OpenPGP暗号化ファイルには、対象となる受信者の公開暗号鍵の鍵IDが含まれます。

結果の暗号化されたファイルからその情報を削除する方法はありますか？ gpgには、その情報を含めないオプションがありますか？

そうでない場合、どのような回避策が推奨されますか？特定の受信者のファイルを暗号化し、受信者または送信者の身元を明かさずに第三者と共有したい。

（受信者の公開鍵は広く共有され、受信者の実際のIDに関連付けられていると想定される場合があります。）

privacypgpgnupg
31
Flimm

これを行うには、gpgの-R（または--hidden-recipient）フラグを使用します。 この回答の詳細

33
kbs

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は、このようにキーごとに2回以上プロンプトを表示しません。

この問題を軽減するためのソフトウェア（メールクライアントなど）を受信するために可能な手法はいくつかあります。私が知っている最も実用的な方法は、匿名の受信者であると予想される鍵（たとえば、メールを受信したメールアドレス）を使用して一時的な鍵リングを生成することです。それらの鍵で失敗した場合、すべてのユーザーの秘密鍵を試すために、鍵リングを変更せずに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.

プライバシーに興味がある場合は、別のオプションに興味があるかもしれません。電子メールを送信するときにOSとソフトウェアのバージョンを出力することは、プライバシーにとって文字通り役に立たず、まったく悪いことです。

   --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のベストプラクティスの一般的な概要については、 この入門ラボによる入門 を確認してください。

18
user9651

特定のプログラムでその情報を取り除くことができるかどうかはわかりませんが、問題が発生する理由はわかりません。回避策として、受信者は秘密鍵で新しい公開鍵に署名し、送信者の公開鍵で新しい公開鍵を暗号化し、送信者が送信に使用できる新しい公開鍵を送信者に送信します。このようにして、新しい「セッション」公開鍵は世界中に決して公開されず、それを受信者にリンクする方法はありません。

ただし、受信者が送信者と話したことを誰かが知っている可能性はまだあります。そのため、会話のどちらかが発生していることを誰かが知らないようにしようとすると、これは機能しません。

3
AJ Henderson

回避策として、受信者は新しい公開鍵を準備し（非常に短い有効期限を使用している可能性があります）、そのファイルをこれで暗号化することができます。したがって、ファイルが暗号化されているキーを特定することは可能ですが、そのキーは新しいため、誰にも関連付けられていません。

1
Vucar Timnärakrul