☰

GPGキーとサブキーについてまだ混乱しています

tag-icon • tag-icon command-line encryption gnupg
GPGキーとサブキーについてまだ混乱しています

新しいキーを生成しました

gpg --quick-generate-key

さて、私が

gpg --list-keys[メールアドレス]

次のようなものが表示されます:

pub   rsa2048 2020-01-29 [SC] [expires: 2022-01-28]
      DEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF
uid           [ultimate] [email protected]
sub   rsa2048 2020-01-29 [E]

しかし、私がこれをすると:

gpg --edit-key[メールアドレス]

次のような結果になります。

gpg (GnuPG) 2.2.17; Copyright (C) 2019 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa2048/DEADBEEFDEADBEEF
     created: 2020-01-29  expires: 2022-01-28  usage: SC  
     trust: ultimate      validity: ultimate
ssb  rsa2048/BEEFDEADBEEFDEAD
     created: 2020-01-29  expires: never       usage: E   
[ultimate] (1). [email protected]

キーとサブキーの概念はある程度は理解しているつもりでしたが、それでもまだ意味がわかりません。

  1. 出力では、一方では公開鍵が表示され、他方では秘密鍵が表示されるのはなぜですか?
  2. 最初のケースでは公開鍵 ( pub) が署名 ( ) が可能と示され、2 番目のケースでは秘密鍵 ( ) が暗号化 ( ) が可能と示されるのはなぜでしょうか。これは、公開鍵暗号 101 で学んだことと矛盾していませんか。SssbE

答え1

出力では、一方では公開鍵が表示され、他方では秘密鍵が表示されるのはなぜですか?

--edit-keyGnuPG 2.1 以降では、このコマンドはこれまで常に実行されていたため、秘密キーを表示すると思われます。

GnuPG 1.x では (そして同様にオリジナルの PGP 2.x でも)、完全に独立した 2 つのキーリング (公開と秘密) がありました。一部の操作は一方に対して機能し、一部は他方に対して機能しました。つまり、異なるファイルから読み取る点を除けば--list-secret-keysまったく同じで--list-keys、--edit-keys2 つのビューを切り替えるサブコマンドがありました。

最初のケースでは公開鍵 (pub) が署名可能 (S) として表示され、2 番目のケースでは秘密鍵 (ssb) が暗号化可能 (E) として表示されるのはなぜでしょうか。これは、公開鍵暗号 101 で学んだことと矛盾していませんか。

いいえ。出力はPGPオブジェクト内の「キー」を表します。純粋な暗号的な意味での「キー」ではありません。使用フラグはそれがどのようなPGP操作であるかを表します。意味「内部」キーが数学的にどのような暗号化操作を実行できるかだけでなく、その使用目的も異なります。つまり、公開半分と秘密半分のどちらを見ているかによって、それらは変化しません。

たとえば、サンプルの PGP キーブロックには 2 つの RSA キーペアが含まれており、技術的にはどちらも署名/検証と暗号化/復号化が可能です。ただし、2 つ持つことの全体的なポイントは、それらの目的を別々にしておくことです。つまり、GnuPG が署名用のサブキーを使用して暗号化を実行することは望ましくないため、使用フラグによってそれが除外されます。

(メッセージまたは署名で既にどのキーを使用するかが示されているため、「復号化」または「検証」用の個別のフラグはありません。)

これは、同じ操作 (署名または検証) にマッピングされるが、異なるコンテキストで複数の使用フラグが存在する可能性があることも意味します。

  • 「S」は、メッセージやファイル（電子メールなど）の署名にキーを使用できるようにします。
  • 「C」は、キーを他のキー/サブキーの署名（認証）に使用できるようにします。
  • 「A」は、キーを認証チャレンジの署名に使用できるようにします (TLS または SSHv2 の場合と同様)。

これら 3 つは暗号という意味では同じ種類のデジタル署名を作成しますが、ポリシー上の理由からキー自体は別々になっていることがよくあります。(たとえば、「証明」キーは「認証」キーよりもはるかに強力に保護する必要があります。)

関連情報