PGP (GPG) ことはじめ - GPG 使ってみる編

GPG の基本的な使い方をまとめる。

前回の続きで、鍵の作成だったりファイルの暗号化だったり鍵の管理だったり GPG の基本的な使い方をまとめる。

自分が試したことを思い出すための記録的な想定でまとめている。

はじめに

今回使った GPG のバージョンは以下。

❯ gpg --version
gpg (GnuPG) 2.4.5
libgcrypt 1.10.3-unknown
Copyright (C) 2024 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/shida/.gnupg
サポートしているアルゴリズム:
公開鍵: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
暗号方式: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256,
      TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256
ハッシュ: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
圧縮: 無圧縮, ZIP, ZLIB, BZIP2

以降は自分が理解するために色々試したメモになるが、基本的に man gpg に書いているものなので、今回使っていないオプション等詳細はそちらを参照。

鍵の作成

以下の鍵3本の構成で作成する。

主鍵 : Certification
- 副鍵 : Signing
- 副鍵 : Encryption

暗号方式（鍵の種類）については使えるものの中から強そうなものを適当に選んでいる。これについては補足参照。

主鍵の作成

主鍵の作成は --full-generate-key|--full-gen-key や --generate-key|--gen-key で行う。

使うのはどちらでも良いが、 --generate-key は鍵の構成や種類、有効期限等の設定を GPG に任せる形になり、 --full-generate-key はその辺を自分で自由に設定できる。今回はどういう設定ができるのかを見てみる意図もあり --full-generate-key の方を使う。また、 --expert を指定することで鍵の種類（どの機能持たせるか）や使用する楕円曲線の選択肢が増えたり、より細かい設定ができるようになる。

ということでこんな感じで作成する。

❯ gpg --expert --full-generate-key
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

ご希望の鍵の種類を選択してください:
   (1) RSA と RSA
   (2) DSA と Elgamal
   (3) DSA (署名のみ)
   (4) RSA (署名のみ)
   (7) DSA (機能をあなた自身で設定)
   (8) RSA (機能をあなた自身で設定)
   (9) ECC (署名と暗号化) *デフォルト
  (10) ECC (署名のみ)
  (11) ECC (機能をあなた自身で設定)
  (13) 既存の鍵
  (14) カードに存在する鍵
あなたの選択は? 11

このECC鍵にありうる操作: Sign Certify Authenticate
現在の認められた操作: Sign Certify

   (S) 署名機能を反転する
   (A) 認証機能を反転する
   (Q) 完了

あなたの選択は? S

このECC鍵にありうる操作: Sign Certify Authenticate
現在の認められた操作: Certify

   (S) 署名機能を反転する
   (A) 認証機能を反転する
   (Q) 完了

あなたの選択は? Q
ご希望の楕円曲線を選択してください:
   (1) Curve 25519 *デフォルト
   (2) Curve 448
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
あなたの選択は? 5
鍵の有効期限を指定してください。
         0 = 鍵は無期限
      <n>  = 鍵は n 日間で期限切れ
      <n>w = 鍵は n 週間で期限切れ
      <n>m = 鍵は n か月間で期限切れ
      <n>y = 鍵は n 年間で期限切れ
鍵の有効期間は? (0)0
鍵は無期限です
これで正しいですか? (y/N) y

GnuPGはあなたの鍵を識別するためにユーザIDを構成する必要があります。

本名: Alice
電子メール・アドレス: [email protected]
コメント:
次のユーザIDを選択しました:
    "Alice <[email protected]>"

名前(N)、コメント(C)、電子メール(E)の変更、またはOK(O)か終了(Q)? o
たくさんのランダム・バイトの生成が必要です。キーボードを打つ、マウスを動か
す、ディスクにアクセスするなどの他の操作を素数生成の間に行うことで、乱数生
成器に十分なエントロピーを供給する機会を与えることができます。
gpg: 失効証明書を '/home/shida/.gnupg/openpgp-revocs.d/3BBD40F853C9A1C1410C886ED7817D5403305F41.rev' に保管しました。
公開鍵と秘密鍵を作成し、署名しました。

pub   nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid                      Alice <[email protected]>

上記のコマンドログからだと分からないが、途中でパスフレーズの設定を要求される。環境にもよるがデスクトップ環境を使っていれば別途ウィンドウが開いていると思うのでそっちで入力する。この辺りは gpg-agent の設定で変更できる（補足参照）

これで鍵（秘密鍵と公開鍵）が作成され、自分の鍵束に保存された。

主鍵の確認

作った鍵は --list-keys|--list-public-keys|-k (公開鍵）や --list-secret-keys|-K （秘密鍵）で確認できる。

❯ gpg --list-secret-keys [email protected]
sec   nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  究極  ] Alice <[email protected]>

❯ gpg --list-keys [email protected]
pub   nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  究極  ] Alice <[email protected]>

今回はリストするユーザをメールアドレス（ uid ）で指定しているが、他人のものも含めて鍵束にある鍵を全てリストしたい場合は単に uid や keyid 等を指定せずに実行すればいい。

GPG で鍵を識別する際、上記ではメールアドレスを使っているが他にも色々使える。

uid
- 鍵に設定した本名やメールアドレス等
- 今回作った鍵で言えば alice や [email protected] がそう
keyid
- リスト時に --keyid-format long 等を付ければ確認できる
keygrip
- リスト時に --with-keygrip を付ければ確認できる
fingerprint
- 上記出力の2行目に出てるヤツがそう

ただ、後述する --edit-key から派生する操作以外の場面では鍵の keyid 等を指定した場合も鍵指定では無くユーザを指定したような動作をすることが多い ¹ ので、基本的には keyid や fingerprint 等を確認してコピペしなくても uid での指定で事足りる。（タブ補完も効くし）

副鍵の作成

次に副鍵を2本（署名用と暗号化用）作成する。

副鍵の作成時には --edit-key から派生する操作で行う事になる。

実際に鍵を2本作成する様子が以下。

# 副鍵を作成するユーザを選択（自分が秘密鍵を持ってる鍵である必要がある）
❯ gpg --expert --edit-key [email protected]
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

秘密鍵が利用できます。

sec  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C
     信用: 究極        有効性: 究極
[  究極  ] (1). Alice <[email protected]>

# ユーザの主鍵にぶら下げる形で副鍵を追加（署名用）
gpg> addkey
ご希望の鍵の種類を選択してください:
   (3) DSA (署名のみ)
   (4) RSA (署名のみ)
   (5) Elgamal (暗号化のみ)
   (6) RSA (暗号化のみ)
   (7) DSA (機能をあなた自身で設定)
   (8) RSA (機能をあなた自身で設定)
  (10) ECC (署名のみ)
  (11) ECC (機能をあなた自身で設定)
  (12) ECC (暗号化のみ)
  (13) 既存の鍵
  (14) カードに存在する鍵
あなたの選択は? 10
ご希望の楕円曲線を選択してください:
   (1) Curve 25519 *デフォルト
   (2) Curve 448
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
あなたの選択は? 5
鍵の有効期限を指定してください。
         0 = 鍵は無期限
      <n>  = 鍵は n 日間で期限切れ
      <n>w = 鍵は n 週間で期限切れ
      <n>m = 鍵は n か月間で期限切れ
      <n>y = 鍵は n 年間で期限切れ
鍵の有効期間は? (0)0
鍵は無期限です
これで正しいですか? (y/N) y
本当に作成しますか? (y/N) y
たくさんのランダム・バイトの生成が必要です。キーボードを打つ、マウスを動か
す、ディスクにアクセスするなどの他の操作を素数生成の間に行うことで、乱数生
成器に十分なエントロピーを供給する機会を与えることができます。

sec  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C
     信用: 究極        有効性: 究極
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S
[  究極  ] (1). Alice <[email protected]>

# 副鍵を追加（暗号化用）
gpg> addkey
ご希望の鍵の種類を選択してください:
   (3) DSA (署名のみ)
   (4) RSA (署名のみ)
   (5) Elgamal (暗号化のみ)
   (6) RSA (暗号化のみ)
   (7) DSA (機能をあなた自身で設定)
   (8) RSA (機能をあなた自身で設定)
  (10) ECC (署名のみ)
  (11) ECC (機能をあなた自身で設定)
  (12) ECC (暗号化のみ)
  (13) 既存の鍵
  (14) カードに存在する鍵
あなたの選択は? 12
ご希望の楕円曲線を選択してください:
   (1) Curve 25519 *デフォルト
   (2) Curve 448
   (3) NIST P-256
   (4) NIST P-384
   (5) NIST P-521
   (6) Brainpool P-256
   (7) Brainpool P-384
   (8) Brainpool P-512
   (9) secp256k1
あなたの選択は? 5
鍵の有効期限を指定してください。
         0 = 鍵は無期限
      <n>  = 鍵は n 日間で期限切れ
      <n>w = 鍵は n 週間で期限切れ
      <n>m = 鍵は n か月間で期限切れ
      <n>y = 鍵は n 年間で期限切れ
鍵の有効期間は? (0)0
鍵は無期限です
これで正しいですか? (y/N) y
本当に作成しますか? (y/N) y
たくさんのランダム・バイトの生成が必要です。キーボードを打つ、マウスを動か
す、ディスクにアクセスするなどの他の操作を素数生成の間に行うことで、乱数生
成器に十分なエントロピーを供給する機会を与えることができます。

sec  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C
     信用: 究極        有効性: 究極
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S
ssb  nistp521/820B01AA8C2BDD46
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  究極  ] (1). Alice <[email protected]>

# 変更を保存
gpg> save

最後の save のタイミングで鍵が保存されるので、保存しないまま quit すると破棄される。（「変更を保存しますか？」という確認はある）

また、それぞれの副鍵で「本当に作成しますか？」のタイミングでパスフレーズの入力を要求されるが、副鍵毎にパスフレーズを設定するわけではなく、主鍵作成時に設定したものを入力する。

副鍵の確認

前述の save 直前の表示でも分かるが、ちゃんと保存されているかという意味で一応確認しておく。

❯ gpg --list-secret-keys [email protected]
sec   nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  究極  ] Alice <[email protected]>
ssb   nistp521 2024-03-24 [S]
ssb   nistp521 2024-03-24 [E]

❯ gpg --list-keys [email protected]
pub   nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  究極  ] Alice <[email protected]>
sub   nistp521 2024-03-24 [S]
sub   nistp521 2024-03-24 [E]

どちらも主鍵にぶら下がる形で副鍵2本できているのが確認できる。

また、鍵の行末の鉤括弧部分でどの機能を持っている鍵なのか分かる。

[C]ertify : 証明機能
[S]ign : 署名機能
[E]ncrypt : 暗号化機能
[A]uthenticate : 認証機能
- 今回は作ってないが

ということで、主鍵副鍵の作成は完了。

鍵を使った暗号化や署名

鍵ができたので基本的な操作を一通りやってみる。

データの暗号化と復号

適当なファイルを作って暗号化、復号してみる。

コマンドとしては、 --encrypt|-e で暗号化、 --decrypt|-d で復号ができる。暗号化する時は --recipient|-r で受取人（復号できる秘密鍵を持っている人）を指定する。復号する時は対応する秘密鍵が自動で選ばれるので特に指定は無い。

# 適当なファイルを用意
❯ cat file
this is a pen

# 暗号化（暗号化したファイルは {ファイル名}.gpg というファイル名で作成される）
❯ gpg --encrypt --recipient [email protected] file

# 暗号化されていることを確認
❯ cat file.gpg
���
   ��+�F#7S���?���8Z;��z        }J=�ր��m*�O.�Aw7�IG5��GR�s%Ƶ�H��!�      8z���9ƴO�+[=    �p?�H�"~L��6�x=ъ�D� 1߲h�g�_!��tY���'���}
m�W�4�����࡝`�f��M˿^�B�_C��l�Lp��'��V    G��B�(Ԛ-"       y�'#6eg�U��P�.�HIa����5W�ym��\�y;�Ps�Ȃa�@��6+�����{�W&�v��             `50� �vH��

# 復号（復号結果が標準出力に出るのでリダイレクトしている）
❯ gpg --decrypt file.gpg > decrypted_file
gpg: nistp521鍵, ID 820B01AA8C2BDD46, 日付2024-03-24に暗号化されました
      "Alice <[email protected]>"

# 復号結果の確認
❯ cat decrypted_file
this is a pen

いくつかポイントがあるが、

今回は自分の鍵で暗号化しているが、実際に使う場合は大抵相手の鍵になる
- 自分の公開鍵で暗号化して相手が読めない、みたいなことにならないように注意する
- 受取人は -r {受取人} -r {受取人} みたいな感じ並べれば複数指定もできる
--armor|-a を使う事で暗号化後のデータを ASCII 形式にすることもできる
- ファイルとして扱う分にはバイナリでも困らないが、メール本文に貼り付けるとかデータをテキストでそのまま渡したい時にバイナリだと若干扱い難いので、そういう場合は ASCII 形式にすると扱いやすい
- ASCII 形式の場合はファイル名が {ファイル名}.asc になる
上記では --decrypt を指定して復号しているが、実はコレも省略できる
- その場合はリダイレクトしなくとも拡張子を取ったファイル名に出力される

ということで、少し違うパターンでもう一回。

# ASCII 形式で暗号化
❯ gpg -e -r [email protected] -a file

# 暗号化されていることを確認
❯ cat file.asc
-----BEGIN PGP MESSAGE-----

hMIDggsBqowr3UYSBCMEAaY49RndGhVaDvOY3zEoipI0fFuxS189M7SdmcR0ywij
5zLqmQadIEhmG33yQQIir6r+V2ohWoeLPzF+9jEJVmYbAMePHkDQaOSY+V+ZnKWi
GxPu88ziU+sQbtPjLUemo3CotDZAlIfd3I6UJK8HFIe1Jym7hvm+b3cv91htTNBN
fatOMICEX3gRVnTvYVnDRXaPKozKjUCD6IYjq2FTbdIpBh0cmcGXbWdXw9MDdula
TiU0sdRWAQkCEPZHZtazUroxS9d99aqwGTeYY3DJ8UJHx0/oP2678q6I0rHczZI0
F1764/Ph+KHKjni/2Q0waHEgtIqtKq5NV50G3FGlkwjbC+3EDaTfQoj4s60=
=BGuZ
-----END PGP MESSAGE-----

# 復号
❯ gpg file.asc
gpg: *警告*: コマンドが指定されていません。なにを意味しているのか当ててみます ...
gpg: nistp521鍵, ID 820B01AA8C2BDD46, 日付2024-03-24に暗号化されました
      "Alice <[email protected]>"
ファイル'file'は既に存在します。上書きしますか? (y/N) y

# 復号結果の確認
❯ cat file
this is a pen

対象暗号での暗号化と復号

若干余談っぽくはなるが、 GPG では公開鍵を使った暗号化/復号だけではなくて、対象暗号を用いた暗号化/復号も可能なので一応触れておく。

こんな感じで --symmetric|-c を使う事で、鍵では無くパスフレーズでの暗号化/復号ができる。

# 適当なファイル
❯ cat test
this is a pen

# 対象暗号での暗号化（このログからだと見えないがパスフレーズが要求される）
❯ gpg --symmetric -a test

# 暗号化したファイル
❯ cat test.asc 
-----BEGIN PGP MESSAGE-----

jA0ECQMIUlOIVSsIOPb/0kYB+z5UUgz9lVO1eqOPGxjcWvhO075MExbd6QGP0JgC
kLS5dDekx9c2BuSFN44foeqWWX1j5u6KxhFVt1mgOk4j4q3qwZ8V
=qLNd
-----END PGP MESSAGE-----

# オリジナルファイルを削除
❯ rm test

# 復号
❯ gpg --decrypt test.asc 
gpg: AES256.CFB暗号化済みデータ
gpg: 1 個のパスフレーズで暗号化
this is a pen

ちなみにこういったパスフレーズに関しても gpg-agent が一定時間記憶しているようで、上記を一気にやるとパスフレーズを入力せずに復号できたりする。キャッシュの有効期限が切れるまで待ったり、別 PC で復号しようとするとちゃんとパスフレーズを要求される。

署名と検証

署名/検証の場合は暗号化/復号に比べて少し複雑で、大きく分けて3つのパターンがある。

単純署名（仮）
- --sign
- オリジナルデータに署名して、署名済のファイルを作成するパターン
分遺署名
- --detach-sign|-b
- オリジナルデータとは別で署名ファイルを作成するパターン
平文署名
- --clear-sign|--clearsign
- オリジナルデータに署名をくっつけるパターン

それぞれ見ていく。バイナリファイルを cat したものを貼り付けるのが若干しんどいので、以降は全部 ASCII 形式でやっていく。

単純署名（仮）

この形式に何か名前があるのかは分からなかったが、他と区別する意味でここではひとまずこう呼ぶ。

実際に署名操作をやってみるとこんな感じになる。

# 単純署名（仮）を作成
❯ gpg --sign -a file

# 単純署名の中身
❯ cat file.asc
-----BEGIN PGP MESSAGE-----

owGbwMvMwCX8g+FV4TzN20WMaySSWNIyc1JT/+/vLMnILFYAokSFgtQ8ro6dLAzC
XAyyYoossoyXOzeYbJzwSfJAAkwnKxNICwMXpwBMhGsbEyfjp5YbfzkT+MI/qW4v
v2+oyPz8PKvURfOS1RPi7kdPlOGLfan7hEX3qoWeqtr6vdM33PrWVPX2SrWE18OQ
syreG9PSzNyAZpQ9lSuKV0xxCJ46x9tzmv/zQx/ilPn3cnlPl+vft37H0RNmebeP
vm6ynRV/+PoaNy3h31P2F4kV7/y+2MX3cK7h6cRbvwE=
=Qc1M
-----END PGP MESSAGE-----

# 署名の検証とオリジナルデータの分離
❯ gpg --verify --output cleartext file.asc
gpg: 2024年03月24日 14時52分09秒 JSTに施された署名
gpg:                ECDSA鍵1D01D389B034B190F219C060F800EA719E29DB72を使用
gpg: "Alice <[email protected]>"からの正しい署名 [究極]
gpg: *警告*: 分遣署名ではありません。ファイル「file」は検証され*ませんでした*!

# オリジナルデータの確認
❯ cat cleartext
this is a pen

こんな感じでオリジナルデータと署名がセットになったファイルが作成される。

署名したファイルだけ見ると一見暗号化されてるようにも見えるが、オリジナルデータは圧縮されているだけなのでデータは誰でも読むことができる。

先の暗号化とセットで使うこともでき、その場合は gpg -s -e -r {受取人} {ファイル} みたいな感じでまとめて指定すると暗号化と署名をまとめて行える。

分遺署名

単純署名だとオリジナルデータと署名データがセットになった1つのファイルが作られるが、署名データをオリジナルデータとは別ファイルでを作成するのがこの分遺署名になる。

# 分遺署名を作成
❯ gpg --detach-sign -a file

# 分遺署名の中身
❯ cat file.asc
-----BEGIN PGP SIGNATURE-----

iLgEABMKAB0WIQQdAdOJsDSxkPIZwGD4AOpxninbcgUCZf/BngAKCRD4AOpxninb
clR4AgdtAcQfuuxVUf2AyRLYSLL4eMS2mZ6eRpieIEFXaRSWh6Bi9PMSs/m84wGP
r3kcYA2uOB2a+H8TzIX1uavEEd7V8AIJATa+BK66MtC26l7OZ+iJES7YXiWqsDNM
UK1zuOgQOt4oZ7z2n+IicFCx49VJp/BAWhSYQmf89ioXzmhVufYlJpvJ
=Oubv
-----END PGP SIGNATURE-----

# 分遺署名の検証
❯ gpg --verify file.asc
gpg: 署名されたデータが'file'にあると想定します
gpg: 2024年03月24日 15時01分02秒 JSTに施された署名
gpg:                ECDSA鍵1D01D389B034B190F219C060F800EA719E29DB72を使用
gpg: "Alice <[email protected]>"からの正しい署名 [究極]

単純署名と違ってファイルを受け取った側がオリジナルデータと署名を分離したりする必要が無いので使い勝手が良く、インターネット上でファイルを配布する際によく使われている。（今回は ASCII 形式にしているので {ファイル名}.asc になっているが、バイナリだと分遺署名のファイル名は {ファイル名}.sig になりこのファイル名だと結構見覚えがあると思う）

当然だがオリジナルファイルが無いと署名を検証する対象がないのでこうなる。

❯ rm file

❯ gpg --verify file.asc
gpg: 署名されたデータがありません
gpg: can't hash datafile: データがありません

平文署名

単純署名（仮）と同じくオリジナルデータと署名がセットになった1ファイルを作成するが、オリジナルデータを圧縮しないパターンになる。言葉での説明だと分かり難いが中身を見ると分かりやすい。

# 平文署名を作成
❯ gpg --clearsign -a file

# 平文署名の中身
❯ cat file.asc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

this is a pen
-----BEGIN PGP SIGNATURE-----

iLgEARMKAB0WIQQdAdOJsDSxkPIZwGD4AOpxninbcgUCZf/FcgAKCRD4AOpxninb
ctvtAgiia+v8a2OeDlYOs5cmfZk8gDG1shnteUgpBX/SiHEfS73FZGUFzLgCqK6q
a077ti7vbQkXZpoKeSLPURYJP/6gxgIJAf1oL1PA3zZTdtJfGjP/LSdWrMuEpEOQ
hQFLw4Qw5MYD04gtvRhLbbt42YBeDKBi9PE+KRrBMpfOMJogUB7LdaH+
=Lddd
-----END PGP SIGNATURE-----

# 平文署名の検証とオリジナルデータの分離
❯ gpg --verify --output cleartext file.asc
gpg: 2024年03月24日 15時17分22秒 JSTに施された署名
gpg:                ECDSA鍵1D01D389B034B190F219C060F800EA719E29DB72を使用
gpg: "Alice <[email protected]>"からの正しい署名 [究極]
gpg: *警告*: 分遣署名ではありません。ファイル「file」は検証され*ませんでした*!

# 分離したオリジナルデータの確認
❯ cat cleartext
this is a pen

こんな感じで署名とオリジナルデータが一つにファイルになり、かつ中身もそのまま読めるのが平文署名になる。

ただ、 man gpg にこんな感じで書いている様に、基本的には平文署名を使うよりは分遺署名を使うのが推奨らしい。

Note: When verifying a cleartext signature, gpg verifies only what makes up the cleartext signed data and not any extra data outside of the cleartext signature or the header lines directly following the dash marker line. The option –output may be used to write out the actual signed data, but there are other pitfalls with this format as well. It is suggested to avoid cleartext signatures in favor of detached signatures.

ちなみに検証時に分遺署名ではないという警告が出ているが、これは同一ディレクトリに平文署名ファイル file.asc と、オリジナルファイル file が両方存在するため。 file を削除した上で同じ様に検証すれば出ない、くらいのものでこの分遺署名を推奨云々とは関係無い。

鍵の運用

鍵の運用に関する操作についてもまとめておく。

鍵のエクスポート

鍵をファイルやテキストデータとしてエクスポートする。

公開鍵と秘密鍵でそれぞれ別のコマンドを使う。

公開鍵のエクスポート

公開鍵のエクスポートには --export を使ってこんな感じ。

# 指定したユーザの公開鍵をエクスポート（ nistp521 の主鍵1本+副鍵2本だとこのくらいのサイズ）
❯ gpg --export -a [email protected]
-----BEGIN PGP PUBLIC KEY BLOCK-----

mJMEZf+PpBMFK4EEACMEIwQBf+BTTR/PcEKeCol47ukZElmoG/okyc1gXRId+mAQ
TtcW+XfeS/pDMimDdhqB1pgcSExx0TiWkHAAfXKqGXCPnA4Adwg0OZlzp9+m/JgL
ZtkYaTrmUiZhSLeU8EU8dh1i3GRD8AOClMzN508l27MPFmxXHxS4b3m2LgfTlALQ
aagxGE60GUFsaWNlIDxhbGljZUBleGFtcGxlLmNvbT6I1gQTEwoAOxYhBDu9QPhT
yaHBQQyIbteBfVQDMF9BBQJl/4+kAhsBBQsJCAcCAiICBhUKCQgLAgQWAgMBAh4H
AheAAAoJENeBfVQDMF9BxQsCCQGjdOOWt0kGlCOFJPjzWaFDSCjRr3NdI9QNntV5
Nwil/q2DgeFi7NlGFHkVrYIxqFFhir/OgMFSW0UESPcD0IHewgIIlxEJu0vO5qyG
7GVVC0glQS2HRQB69llfqpnM82eQfMNeAZNEmUfWYd3hIhdCveZo2PE9miviNXq2
bNWPDbrZ0fO4kwRl/5C1EwUrgQQAIwQjBABgRYZcFds+3eSgfQvwfVUb02N9eEwd
R72vh9K7nk235tOfw0R/+iYFipUllv/8JCUYx87hn0n+8Fe8MlStWwT+YQBHPLgd
vSv5nkFaLeoqPfw7+8wozZy8a/KMNSWSL5+UuTD320w/GBZSrTCMaDLxKKiMdQoR
y99cBnt6iS2RUNU21okBdgQYEwoAIBYhBDu9QPhTyaHBQQyIbteBfVQDMF9BBQJl
/5C1AhsCAMUJENeBfVQDMF9BuiAEGRMKAB0WIQQdAdOJsDSxkPIZwGD4AOpxninb
cgUCZf+QtQAKCRD4AOpxninbcstFAgkB9nYuzkcmcnTm6YDAwoJ5wIsHQM4DfCvS
DlYhEgD4LSNesMOCvZuNwLbUvQbzxTVWZCEyv+pv4iiKdGKz4KbXrY4CCQHAvPyX
31/CmkuP5GQn5vhaTdTySOZGa8t4ArLWdairiibR1qdE0Yw1K51k2/fT/+kL0VrI
eh4V1VW7gK2l5yL2bN01AgjvLbpmqGUiz/OFLBXIcX345RKLhP9lm6JEMz0K0BEU
YH6Hwbeb+og/yqs3foJpNO/ApoWckDv9nLOxoH1dMXEe4gIJAScXCjBCVnqKcFoP
1rZguFyfQJuJjK1KEbPJggLyZt04pVCvzgaJcfI9zFDRisqX6JZ24C8ootwqXyxU
sf7DqcHyuJcEZf+Q9hIFK4EEACMEIwQBpWTqtd6VZjNQTaLIveSgUoOucUuNhZF6
MtavCo2VvjPU9gqWScnRj3nxcdcH0OgVr/sqmkAV9neYahA5UmNG9BcAJeMjMuxk
zppOPjdTZpTbyb28xHEW/nfF/nWGXiAg44l8++Bxzdm3mo4ax8CPyTlhhdrD39Tj
18L36eyzEGSEEckDAQoJiLsEGBMKACAWIQQ7vUD4U8mhwUEMiG7XgX1UAzBfQQUC
Zf+Q9gIbDAAKCRDXgX1UAzBfQUCbAgiJr167rbsyB3VDZMvKPnnqIJDiUKCkLUWa
2RfYVSd6sPwzXEKk6OPF/g6xJFrDqudym7jBppqB86+TFlsTBbFXBgIJARN8KTEb
ybyjBLEAWdW0cr/vvYt8c3R7s/wuoFOSxsWdVlI3iwsSKJfUNt5AOZajxS8LiIMc
0QsM+TdO9dHJZg4l
=SSYD
-----END PGP PUBLIC KEY BLOCK-----

標準出力に出るのでファイルにする場合はリダイレクトしても良いし --output を使っても良い。

エクスポート対象を指定する場合は uid や keyid が使えるが、 keyid で指定してもエクスポートは指定した鍵だけではなくユーザ単位（主鍵副鍵まとめて）でのエクスポートになる。

また今回は自分の公開鍵だけエクスポートしているが、他の人のものも含めて鍵束にある公開鍵をまとめてエクスポートする場合は単純にユーザの指定を省略すれば良い。

秘密鍵のエクスポート

秘密鍵の場合は --export-secret-keys を使う。

# 指定したユーザの秘密鍵をエクスポート
❯ gpg --export-secret-keys -a [email protected]
-----BEGIN PGP PRIVATE KEY BLOCK-----

lQEHBGX/j6QTBSuBBAAjBCMEAX/gU00fz3BCngqJeO7pGRJZqBv6JMnNYF0SHfpg
EE7XFvl33kv6QzIpg3YagdaYHEhMcdE4lpBwAH1yqhlwj5wOAHcINDmZc6ffpvyY
C2bZGGk65lImYUi3lPBFPHYdYtxkQ/ADgpTMzedPJduzDxZsVx8UuG95ti4H05QC
0GmoMRhO/gcDApvkIdZ9Iij6/yul7+ekqiO9D4OYtEAxSTC462cvemCEVXZQ+tdD
maN0ydfZiLd/WvteQyYepDidlfE4Ff4XI4qYwVmGQE/+K5yDevsjITc4AgAXMsut
ytXajlS3POTeNg+5o8migb7c8DK5ioxATTy0GUFsaWNlIDxhbGljZUBleGFtcGxl
LmNvbT6I1gQTEwoAOxYhBDu9QPhTyaHBQQyIbteBfVQDMF9BBQJl/4+kAhsBBQsJ
CAcCAiICBhUKCQgLAgQWAgMBAh4HAheAAAoJENeBfVQDMF9BxQsCCQGjdOOWt0kG
lCOFJPjzWaFDSCjRr3NdI9QNntV5Nwil/q2DgeFi7NlGFHkVrYIxqFFhir/OgMFS
W0UESPcD0IHewgIIlxEJu0vO5qyG7GVVC0glQS2HRQB69llfqpnM82eQfMNeAZNE
mUfWYd3hIhdCveZo2PE9miviNXq2bNWPDbrZ0fOdAQgEZf+QtRMFK4EEACMEIwQA
YEWGXBXbPt3koH0L8H1VG9NjfXhMHUe9r4fSu55Nt+bTn8NEf/omBYqVJZb//CQl
GMfO4Z9J/vBXvDJUrVsE/mEARzy4Hb0r+Z5BWi3qKj38O/vMKM2cvGvyjDUlki+f
lLkw99tMPxgWUq0wjGgy8SiojHUKEcvfXAZ7eoktkVDVNtb+BwMCCvndPyAyDYj/
iDH3f7EfAQ7vr4CvqCIZTSdsSjJeukR7HPwN2k+TF+57rUp/yID7plyAh/C3o6Jd
nMixzRZQfSqUpvHRk+KEKtCk/5/vnH6AKK22tKTVJ3GusHpAFG4mVa2O0EhCvmbj
DDEZ5EOgcNqJAXYEGBMKACAWIQQ7vUD4U8mhwUEMiG7XgX1UAzBfQQUCZf+QtQIb
AgDFCRDXgX1UAzBfQbogBBkTCgAdFiEEHQHTibA0sZDyGcBg+ADqcZ4p23IFAmX/
kLUACgkQ+ADqcZ4p23LLRQIJAfZ2Ls5HJnJ05umAwMKCecCLB0DOA3wr0g5WIRIA
+C0jXrDDgr2bjcC21L0G88U1VmQhMr/qb+IoinRis+Cm162OAgkBwLz8l99fwppL
j+RkJ+b4Wk3U8kjmRmvLeAKy1nWoq4om0danRNGMNSudZNv30//pC9FayHoeFdVV
u4Ctpeci9mzdNQII7y26ZqhlIs/zhSwVyHF9+OUSi4T/ZZuiRDM9CtARFGB+h8G3
m/qIP8qrN36CaTTvwKaFnJA7/ZyzsaB9XTFxHuICCQEnFwowQlZ6inBaD9a2YLhc
n0CbiYytShGzyYIC8mbdOKVQr84GiXHyPcxQ0YrKl+iWduAvKKLcKl8sVLH+w6nB
8p0BCwRl/5D2EgUrgQQAIwQjBAGlZOq13pVmM1BNosi95KBSg65xS42FkXoy1q8K
jZW+M9T2CpZJydGPefFx1wfQ6BWv+yqaQBX2d5hqEDlSY0b0FwAl4yMy7GTOmk4+
N1NmlNvJvbzEcRb+d8X+dYZeICDjiXz74HHN2beajhrHwI/JOWGF2sPf1OPXwvfp
7LMQZIQRyQMBCgn+BwMCuG9g02+T16j/Zycfv05BKAuSIi0GpyhZWyjfo+TNjnh2
ILR2w7xd+DbjZJONhArbC5cSGFqSMwfwCRRZiz9BsXlEslse6dpHYIpuLFSblb6Q
4xPgE2pVdchXSRJoStYJlSDhN7TxY+rooDMgoF8zJ4i7BBgTCgAgFiEEO71A+FPJ
ocFBDIhu14F9VAMwX0EFAmX/kPYCGwwACgkQ14F9VAMwX0FAmwIIia9eu627Mgd1
Q2TLyj556iCQ4lCgpC1FmtkX2FUnerD8M1xCpOjjxf4OsSRaw6rncpu4waaagfOv
kxZbEwWxVwYCCQETfCkxG8m8owSxAFnVtHK/772LfHN0e7P8LqBTksbFnVZSN4sL
EiiX1DbeQDmWo8UvC4iDHNELDPk3TvXRyWYOJQ==
=UVIW
-----END PGP PRIVATE KEY BLOCK-----

今回は実際に使う予定の無い鍵なのでそのまま貼っているが、秘密鍵なので当たり前だが扱いには注意する。

使い方は見ての通り公開鍵のエクスポートとほぼ同じ。ただ秘密鍵の場合は --export-secret-subkeys という副鍵のものだけエクスポートするコマンドもある。 GPG の鍵の運用として、主鍵の秘密鍵をオフライン保管するという事がしばしば行われているのでそれ用と思われる。

# 指定したユーザの副鍵の秘密鍵をエクスポート
❯ gpg --export-secret-subkeys -a [email protected]
-----BEGIN PGP PRIVATE KEY BLOCK-----

lJsEZf+PpBMFK4EEACMEIwQBf+BTTR/PcEKeCol47ukZElmoG/okyc1gXRId+mAQ
TtcW+XfeS/pDMimDdhqB1pgcSExx0TiWkHAAfXKqGXCPnA4Adwg0OZlzp9+m/JgL
ZtkYaTrmUiZhSLeU8EU8dh1i3GRD8AOClMzN508l27MPFmxXHxS4b3m2LgfTlALQ
aagxGE7/AGUAR05VAbQZQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPojWBBMTCgA7
FiEEO71A+FPJocFBDIhu14F9VAMwX0EFAmX/j6QCGwEFCwkIBwICIgIGFQoJCAsC
BBYCAwECHgcCF4AACgkQ14F9VAMwX0HFCwIJAaN045a3SQaUI4Uk+PNZoUNIKNGv
c10j1A2e1Xk3CKX+rYOB4WLs2UYUeRWtgjGoUWGKv86AwVJbRQRI9wPQgd7CAgiX
EQm7S87mrIbsZVULSCVBLYdFAHr2WV+qmczzZ5B8w14Bk0SZR9Zh3eEiF0K95mjY
8T2aK+I1erZs1Y8NutnR850BCARl/5C1EwUrgQQAIwQjBABgRYZcFds+3eSgfQvw
fVUb02N9eEwdR72vh9K7nk235tOfw0R/+iYFipUllv/8JCUYx87hn0n+8Fe8MlSt
WwT+YQBHPLgdvSv5nkFaLeoqPfw7+8wozZy8a/KMNSWSL5+UuTD320w/GBZSrTCM
aDLxKKiMdQoRy99cBnt6iS2RUNU21v4HAwIYAoVJw2Sq+f+FDR3HrQkr5SNV1S+2
57gtgeWnqZ188pRBKPUKvGCcy9SYo2ZaMxNvjKfmYXAvLZHANgd1nY0OQzVdyjjC
xNs+ycciIoLxxykr9rtznIw+pNG/40WVuQno+s5z7Nr5Ym+ApZmTB+zLZ4kBdgQY
EwoAIBYhBDu9QPhTyaHBQQyIbteBfVQDMF9BBQJl/5C1AhsCAMUJENeBfVQDMF9B
uiAEGRMKAB0WIQQdAdOJsDSxkPIZwGD4AOpxninbcgUCZf+QtQAKCRD4AOpxninb
cstFAgkB9nYuzkcmcnTm6YDAwoJ5wIsHQM4DfCvSDlYhEgD4LSNesMOCvZuNwLbU
vQbzxTVWZCEyv+pv4iiKdGKz4KbXrY4CCQHAvPyX31/CmkuP5GQn5vhaTdTySOZG
a8t4ArLWdairiibR1qdE0Yw1K51k2/fT/+kL0VrIeh4V1VW7gK2l5yL2bN01Agjv
LbpmqGUiz/OFLBXIcX345RKLhP9lm6JEMz0K0BEUYH6Hwbeb+og/yqs3foJpNO/A
poWckDv9nLOxoH1dMXEe4gIJAScXCjBCVnqKcFoP1rZguFyfQJuJjK1KEbPJggLy
Zt04pVCvzgaJcfI9zFDRisqX6JZ24C8ootwqXyxUsf7DqcHynQELBGX/kPYSBSuB
BAAjBCMEAaVk6rXelWYzUE2iyL3koFKDrnFLjYWRejLWrwqNlb4z1PYKlknJ0Y95
8XHXB9DoFa/7KppAFfZ3mGoQOVJjRvQXACXjIzLsZM6aTj43U2aU28m9vMRxFv53
xf51hl4gIOOJfPvgcc3Zt5qOGsfAj8k5YYXaw9/U49fC9+nssxBkhBHJAwEKCf4H
AwJJfaPhOTPXBv9wDqn2FWQeIFc3Xt2d/3vEpMNS6kwgdMYmn07H388KHdobAZs5
c42u9mSeVkYodclDsfemZklmfn9tTX9XVBiJrFV9yhPNsQvDeB8Gsk5bK9IsJjs2
BrGiiFOD8lUCg7vaYp66s40ZiLsEGBMKACAWIQQ7vUD4U8mhwUEMiG7XgX1UAzBf
QQUCZf+Q9gIbDAAKCRDXgX1UAzBfQUCbAgiJr167rbsyB3VDZMvKPnnqIJDiUKCk
LUWa2RfYVSd6sPwzXEKk6OPF/g6xJFrDqudym7jBppqB86+TFlsTBbFXBgIJARN8
KTEbybyjBLEAWdW0cr/vvYt8c3R7s/wuoFOSxsWdVlI3iwsSKJfUNt5AOZajxS8L
iIMc0QsM+TdO9dHJZg4l
=+8QE
-----END PGP PRIVATE KEY BLOCK-----

鍵のインポート

エクスポートした鍵をインポートする。

操作は秘密鍵でも公開鍵でも --import で行える。違いとしては秘密鍵の場合はパスフレーズを要求されるくらい。

ちなみに秘密鍵をインポートすると公開鍵も自動で生成して鍵束に組み込んでくれる。

# インポート前（鍵が無いことを確認）
❯ gpg --list-secret-keys

❯ gpg --list-keys [email protected]
gpg: error reading key: 公開鍵がありません

# インポートする秘密鍵ファイル（先にエクスポートしたヤツ）
❯ head [email protected] 
-----BEGIN PGP PRIVATE KEY BLOCK-----

lQEHBGX/j6QTBSuBBAAjBCMEAX/gU00fz3BCngqJeO7pGRJZqBv6JMnNYF0SHfpg
EE7XFvl33kv6QzIpg3YagdaYHEhMcdE4lpBwAH1yqhlwj5wOAHcINDmZc6ffpvyY
C2bZGGk65lImYUi3lPBFPHYdYtxkQ/ADgpTMzedPJduzDxZsVx8UuG95ti4H05QC
0GmoMRhO/gcDAnIPWAiF7K3Y//vaaAarUdF23Etvml+7qEEmztbgjYK24CnZ0cSq
5ho6ODuzZBETmOCm/i4tiUENz8UTsaKii2luElB1XQURSdnLzIM1JgIGii4gWX8g
EQvck2WP789NRr1qggQFi9N7eDTV6uQjBS20GUFsaWNlIDxhbGljZUBleGFtcGxl
LmNvbT6I1gQTEwoAOxYhBDu9QPhTyaHBQQyIbteBfVQDMF9BBQJl/4+kAhsBBQsJ
CAcCAiICBhUKCQgLAgQWAgMBAh4HAheAAAoJENeBfVQDMF9BxQsCCQGjdOOWt0kG

# インポート
❯ gpg --import [email protected]
gpg: 鍵D7817D5403305F41: 公開鍵"Alice <[email protected]>"をインポートしました
gpg: 鍵D7817D5403305F41: 秘密鍵をインポートしました
gpg:           処理数の合計: 1
gpg:             インポート: 1
gpg:       秘密鍵の読み込み: 1
gpg:     秘密鍵のインポート: 1

# インポート後の鍵
❯ gpg --list-secret-keys 
/home/shida/.gnupg/pubring.kbx
------------------------------
sec   nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  不明  ] Alice <[email protected]>
ssb   nistp521 2024-03-24 [S]
ssb   nistp521 2024-03-24 [E]

❯ gpg --list-keys [email protected]
pub   nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  不明  ] Alice <[email protected]>
sub   nistp521 2024-03-24 [S]
sub   nistp521 2024-03-24 [E]

インポートした鍵の有効性が「不明」になってしまっているので設定が必要だが、これについては後述。

鍵の失効

GPG で使わなくなった鍵の失効方法について。

今回自分が作った鍵みたいなモノはともかくとして、基本的に誰かとのやり取りに使った鍵であれば鍵（秘密鍵）を削除してしまう前に失効する必要がある。

鍵を使わなくなる状況としては色々考えられるが、秘密鍵を流出させてしまったとかであれば当然誰かに悪用/誤用されないように失効する必要があるし、事故っては無いけど使わなくなった（パスフレーズを忘れたとかも含む）から消すみたいな場合でも、万が一漏れててそれに気付いてない、みたいな可能性を考えるとやはり失効しておくのが望ましい。

鍵を失効させる方法としては、その場で失効させる方法と事前に用意した失効証明を使う方法の2種類があり、それぞれの違いをざっくりまとめるとこんな感じになる。

その場で失効させる方法
- --edit-key からの派生コマンドを使ってその場で失効させる
- 主鍵副鍵まとめて失効する場合でも、特定の副鍵のみ失効する場合でも使える
- 主鍵の秘密鍵が手元に無い場合や、パスフレーズを忘れてしまった場合は使えない
失効証明を使うする方法
- 失効証明を作成して、失効したいタイミングでそれをインポートする事で失効させる
- 主鍵副鍵まとめて失効する場合でのみ使える
- 秘密鍵やパスフレーズの紛失に備えて失効証明を予め作成しておく場合は、その時まで大事に保管しておく必要がある

それぞれ見ていく。

その場で失効させる方法

今回作った鍵の内、暗号化用の副鍵を失効させる場合を例にすると、実際のコマンドはこんな感じになる。

# 失効前の鍵の状態
❯ gpg --list-keys [email protected]
pub   nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  不明  ] Alice <[email protected]>
sub   nistp521 2024-03-24 [S]
sub   nistp521 2024-03-24 [E]


# 指定したユーザの鍵を操作
❯ gpg --edit-key [email protected]
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

秘密鍵が利用できます。

sec  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C
     信用: 不明の     有効性: 不明の
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S
ssb  nistp521/820B01AA8C2BDD46
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  不明  ] (1). Alice <[email protected]>

# 失効させる鍵を選択
gpg> key 820B01AA8C2BDD46

sec  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C
     信用: 不明の     有効性: 不明の
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S
ssb* nistp521/820B01AA8C2BDD46
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  不明  ] (1). Alice <[email protected]>

# 失効
gpg> revkey
この副鍵を本当に失効しますか? (y/N) y
失効の理由を選択してください:
  0 = 理由は指定されていません
  1 = 鍵(の信頼性)が損なわれています
  2 = 鍵がとりかわっています
  3 = 鍵はもはや使われていません
  Q = キャンセル
あなたの決定は? 0
予備の説明を入力。空行で終了:
> 失効のテスト
>
失効理由: 理由は指定されていません
失効のテスト
よろしいですか? (y/N) y

sec  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C   
     信用: 不明の     有効性: 不明の
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S   
2024-03-24で?鍵D7817D5403305F41 Alice <[email protected]>によって以下の鍵は、失効されました
ssb  nistp521/820B01AA8C2BDD46
     作成: 2024-03-24  失効: 2024-03-24  利用法: E   
[  不明  ] (1). Alice <[email protected]>

# 操作内容の保存
gpg> save

# 失効後の確認
❯ gpg --list-keys [email protected]
pub   nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  不明  ] Alice <[email protected]>
sub   nistp521 2024-03-24 [S]

ということで失効させられる。

副鍵ではなく、鍵全体を失効させる場合は key での副鍵指定を行わずに revkey を実行すれば良い。

既に公開鍵を誰かに渡していて、その人にも失効してもらいたい場合は失効させた状態で再度 --export で鍵全体をエクスポートして、それを相手にインポートして貰えば相手側でも失効できる。

失効証明を使う方法

予め失効証明を発行しておいて、それをインポートすることで失効させる方法になる。

コマンドとしてはこんな感じ。

# 失効前の鍵の状態
❯ gpg --list-keys [email protected]
pub   nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  不明  ] Alice <[email protected]>
sub   nistp521 2024-03-24 [S]
sub   nistp521 2024-03-24 [E]


# 失効証明書の作成（今回はファイルに出している）
❯ gpg --generate-revocation --output revocation [email protected]

sec  nistp521/D7817D5403305F41 2024-03-24 Alice <[email protected]>

この鍵に対する失効証明書を作成しますか? (y/N) y
失効の理由を選択してください:
  0 = 理由は指定されていません
  1 = 鍵(の信頼性)が損なわれています
  2 = 鍵がとりかわっています
  3 = 鍵はもはや使われていません
  Q = キャンセル
(ここではたぶん1を選びたいでしょう)
あなたの決定は? 0
予備の説明を入力。空行で終了:
> 失効のテスト
> 
失効理由: 理由は指定されていません
失効のテスト
よろしいですか? (y/N) y
ASCII外装出力を強制します。
失効証明書を作成しました。

みつからないように隠せるような媒体に移してください。もし_悪者_がこの証明書への
アクセスを得ると、あなたの鍵を使えなくすることができます。
媒体が読出し不能になった場合に備えて、この証明書を印刷して保管するのが賢明です。
しかし、ご注意ください。あなたのマシンの印字システムは、他の人がアクセスできる
場所にデータをおくことがあります!

# 失効証明書の中身
❯ cat revocation 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: This is a revocation certificate

iM0EIBMKADIWIQQ7vUD4U8mhwUEMiG7XgX1UAzBfQQUCZgCkXhQdAOWkseWKueOB
ruODhuOCueODiAAKCRDXgX1UAzBfQWysAgkBImcLQeK/p0uVNJSw5L36DVVpwpQQ
pTp7lox9Oajcuh9kkN+W0hOXQGASmPRPvMjkVQ7xviARhGjBnN5LjSIK8O8CCJ5r
+J3TQu+icIGOm2qab57RGYXHXwe1g+WX4CI8Jzux06z9tza0swEFut0MjPVT6lUB
eTz0DqJrC47d3arBXY9e
=X8Lh
-----END PGP PUBLIC KEY BLOCK-----

# 失効証明書のインポート
❯ gpg --import revocation 
gpg: 鍵D7817D5403305F41:"Alice <[email protected]>"失効証明書をインポートしました
gpg:           処理数の合計: 1
gpg:         新しい鍵の失効: 1
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: 深さ: 0  有効性:   1  署名:   0  信用: 0-, 0q, 0n, 0m, 0f, 1u

# 失効証明書インポート後の鍵の状態
❯ gpg --list-keys [email protected]
pub   nistp521 2024-03-24 [C] [失効: 2024-03-24]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  失効  ] Alice <[email protected]>

この失効証明を使う方法であれば、主鍵の秘密鍵をなくしてしまったりパスフレーズを忘れてしまった場合でも失効させることができる。ただし注意書きにもある様に、失効証明を流出させてしまうと他人が自分の鍵を勝手に失効させる事ができてしまうので、失効証明は主鍵の秘密鍵と同じくらい大事に保管しておく必要がある。

鍵の削除

鍵を鍵束から削除する方法について。

自分が失効させた自分の鍵でも、他人が失効させた他人の鍵でも、鍵の信頼性が失われたところで鍵束に鍵は残る。一応鍵束に残しておけば、過去に行った/行われた署名が当時有効だったかの検証ができたり ² 、やり取りしていた暗号データを後から復号できたりといったメリットはあるが、そういった事をしないのであれば残してても仕方ないので必要に応じて削除する。 ³

またそういった鍵の片付け以外でも、主鍵の秘密鍵だけオフライン保管するような鍵運用の場合にも行う。

鍵を削除するパターン

実際に鍵束から鍵を削除するパターンとして概ね3つくらい考えられる。

ユーザの全ての鍵を削除する
主鍵の秘密鍵だけ削除する
特定の副鍵を削除する

この内、主鍵を含めて削除（主鍵副鍵含めた全ての鍵、主鍵の秘密鍵だけ）したい場合と、特定の副鍵だけ削除したい場合で若干操作が異なるのでそれぞれで見る。

主鍵を含めて削除する（主鍵副鍵含めた全ての鍵、主鍵の秘密鍵だけ）

この場合は秘密鍵、公開鍵の順でそれぞれ削除操作を行う必要があり、秘密鍵の削除は --delete-secret-keys 、公開鍵の削除は --delete-keys で行う。

今回は例として主鍵の秘密鍵のみ削除する場合。

# 削除前の状態
❯ gpg --list-secret-keys [email protected]
sec   nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  不明  ] Alice <[email protected]>
ssb   nistp521 2024-03-24 [S]
ssb   nistp521 2024-03-24 [E]


# 主鍵の秘密鍵の削除（主鍵の削除後に副鍵を削除するかの確認に移るので拒否）
❯ gpg --delete-secret-keys [email protected]
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


sec  nistp521/D7817D5403305F41 2024-03-24 Alice <[email protected]>

この鍵を鍵リングから削除しますか? (y/N) y
これは秘密鍵です! 本当に削除しますか? (y/N) y
gpg: 秘密副鍵: の削除に失敗しました: 操作がキャンセルされました
gpg: [email protected]: delete key failed: 操作がキャンセルされました

# 削除後（秘密鍵）
❯ gpg --list-secret-keys [email protected]
sec#  nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  不明  ] Alice <[email protected]>
ssb   nistp521 2024-03-24 [S]
ssb   nistp521 2024-03-24 [E]

ターミナルのログだと分かりにくいが、実行すると鍵毎に削除するかどうかの確認があり今回は主鍵のみ削除した形。主鍵の秘密鍵を削除した状態だと、こんな感じで sec の後ろに # が付くので削除できたかはこれで確認できる。

削除する際の鍵の指定は uid でも keyid でも可能だが、動きとしてはどちらも指定したユーザの鍵全体に対しての操作になる。（主鍵では無く副鍵の keyid を指定した場合も同様）具体的には、指定したユーザの鍵に対して上から順に削除確認があって No にしたタイミングで処理が止まる。全て削除したい場合は全部 Yes と答えて行けばいいし、例の様に主鍵の秘密鍵だけ削除したい場合は最初に聞かれる主鍵の削除の確認だけ Yes と答えて後は No にする。

こういった動きをするため、鍵の並びにもよるがこの操作だと特定の副鍵だけ削除といったことはできない。

特定の副鍵のみ削除する

ということで特定の副鍵のみ削除する方法だが、この場合は副鍵を作成した時と同じ様に --edit-key からの派生コマンドを使う。

ここでは最初に発行した鍵の内、暗号化機能を持たせた鍵のみ削除する例。

# 指定したユーザの鍵を操作する
❯ gpg --edit-key [email protected]
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

秘密副鍵が利用できます。

pub  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C
     信用: 不明の     有効性: 不明の
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S
ssb  nistp521/820B01AA8C2BDD46
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  不明  ] (1). Alice <[email protected]>

# 副鍵を選択（今回は暗号化用を選択、選択中の鍵には * が付く）
gpg> key 820B01AA8C2BDD46

pub  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C
     信用: 不明の     有効性: 不明の
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S
ssb* nistp521/820B01AA8C2BDD46
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  不明  ] (1). Alice <[email protected]>

# 選択中の鍵を削除
gpg> delkey
この鍵を本当に削除しますか? (y/N) y

pub  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C
     信用: 不明の     有効性: 不明の
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S
[  不明  ] (1). Alice <[email protected]>

# 操作を保存
gpg> save

# 削除後の鍵を確認（公開鍵、秘密鍵が両方削除されているのが分かる）
❯ gpg --list-keys [email protected]
pub   nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  不明  ] Alice <[email protected]>
sub   nistp521 2024-03-24 [S]


❯ gpg --list-secret-keys [email protected]
sec#  nistp521 2024-03-24 [C]
      3BBD40F853C9A1C1410C886ED7817D5403305F41
uid           [  不明  ] Alice <[email protected]>
ssb   nistp521 2024-03-24 [S]

という感じで、主鍵を削除する場合と若干操作は異なるが特定の副鍵だけ削除することもできる。

鍵の有効度、所有者信頼の設定

鍵への有効性の設定方法について。

以下3つのパターンで分けてそれぞれ見る。

自分の鍵を設定する（Validity, OwnerTrust）
他人の鍵の有効性を設定する場合（Validity）
他人の信用を設定する場合（OwnerTrust）

自分の鍵を設定する（Validity, OwnerTrust）

鍵のインポートのところで少し触れたが、自分で作った鍵でも別 PC 等でインポートした場合は有効性が不明に設定される。

❯ gpg --edit-key [email protected] 
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

秘密鍵が利用できます。

sec  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C   
     信用: 不明の     有効性: 不明の
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S   
ssb  nistp521/820B01AA8C2BDD46
     作成: 2024-03-24  有効期限: 無期限      利用法: E   
[  不明  ] (1). Alice <[email protected]>

GPG では他人の鍵の有効性を設定するために、自分の鍵（究極的に信頼出来る鍵）で他人の鍵に署名を行う必要があるが、その署名するための鍵が無いということになる。

ということで他人の鍵の有効性や信用を設定する前に、自分の鍵として設定する方法について。

この場合は、 --edit-key から信用の設定をすることで間接的に有効性も設定することができる。実際に設定した様子としてはこんな感じ。

# 変更前の鍵の状態（有効性も信用も不明になっている）
❯ gpg --edit-key [email protected]
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

秘密鍵が利用できます。

sec  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C   
     信用: 不明の     有効性: 不明の
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S   
ssb  nistp521/820B01AA8C2BDD46
     作成: 2024-03-24  有効期限: 無期限      利用法: E   
[  不明  ] (1). Alice <[email protected]>

# 選択中の鍵の信用を設定する（ 5 = 究極的に信用する）
gpg> trust
sec  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C   
     信用: 不明の     有効性: 不明の
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S   
ssb  nistp521/820B01AA8C2BDD46
     作成: 2024-03-24  有効期限: 無期限      利用法: E   
[  不明  ] (1). Alice <[email protected]>

他のユーザの鍵を正しく検証するために、このユーザの信用度を決めてください
(パスポートを見せてもらったり、他から得たフィンガープリントを検査したり、などなど)

  1 = 知らない、または何とも言えない
  2 = 信用し ない
  3 = まぁまぁ信用する
  4 = 充分に信用する
  5 = 究極的に信用する
  m = メーン・メニューに戻る

あなたの決定は? 5
本当にこの鍵を究極的に信用しますか? (y/N) y

sec  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C   
     信用: 究極        有効性: 不明の
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S   
ssb  nistp521/820B01AA8C2BDD46
     作成: 2024-03-24  有効期限: 無期限      利用法: E   
[  不明  ] (1). Alice <[email protected]>
プログラムを再起動するまで、表示された鍵の有効性は正しくないかもしれない、
ということを念頭においてください。

# 一旦終了（鍵の有効性の表示反映のため）
gpg> quit

# 再度鍵の状態を確認（信用、有効性が共に「究極」になっている）
❯ gpg --edit-key [email protected] 
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

秘密鍵が利用できます。

sec  nistp521/D7817D5403305F41
     作成: 2024-03-24  有効期限: 無期限      利用法: C   
     信用: 究極        有効性: 究極
ssb  nistp521/F800EA719E29DB72
     作成: 2024-03-24  有効期限: 無期限      利用法: S   
ssb  nistp521/820B01AA8C2BDD46
     作成: 2024-03-24  有効期限: 無期限      利用法: E   
[  究極  ] (1). Alice <[email protected]>

gpg>

ということで自分の鍵については、こんな感じで作成した場合と同じ様に究極的に信頼する自分の鍵として設定できる。

他人の鍵の有効性を設定する場合（Validity）

GPG で鍵の有効性を設定するには自分の鍵で署名するもしくは信用できる人の鍵で署名される必要があるのだが、先の自分の鍵についてはその署名する鍵が無い状態だったので若干例外的な方法になった。

ということで、次はちゃんと自分の鍵で署名することで有効性を設定する方法を見る。今回は Alice を自分として Bob の鍵の有効性を設定する例になる。

# Bob の鍵（有効性、信頼性が共に不明）
❯ gpg --edit-key [email protected]
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  nistp521/9C01CED50692C931
     作成: 2024-03-24  有効期限: 無期限      利用法: SC
     信用: 不明の     有効性: 不明の
sub  nistp521/5E65B12213CABE80
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  不明  ] (1). Bob <[email protected]>

# Alice の鍵で Bob の鍵に署名
gpg> sign

pub  nistp521/9C01CED50692C931
     作成: 2024-03-24  有効期限: 無期限      利用法: SC
     信用: 不明の     有効性: 不明の
  主鍵フィンガープリント: 64B0 AF6F 17F8 6AD4 23C4  642D 9C01 CED5 0692 C931

     Bob <[email protected]>

本当にこの鍵にあなたの鍵"Alice <[email protected]>"で署名してよいですか
(D7817D5403305F41)

本当に署名しますか? (y/N) y

# 変更を保存
gpg> save

# 改めて Bob の鍵を確認（有効性が充分になっている）
❯ gpg --edit-key [email protected]
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


gpg: 信用データベースの検査
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: 深さ: 0  有効性:   1  署名:   1  信用: 0-, 0q, 0n, 0m, 0f, 1u
gpg: 深さ: 1  有効性:   1  署名:   0  信用: 1-, 0q, 0n, 0m, 0f, 0u
pub  nistp521/9C01CED50692C931
     作成: 2024-03-24  有効期限: 無期限      利用法: SC
     信用: 不明の     有効性: 充分
sub  nistp521/5E65B12213CABE80
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  充分  ] (1). Bob <[email protected]>

gpg> quit

ということで、 Bob の鍵を正当な鍵として設定できる。

今回は署名に sign を使ったが、署名の仕方にはいくつかバリエーションがあり man gpg の --edit-key 辺りに説明が書いてある。慣れるまではとりあえず sign か lsign を使って、慣れてきたら他の署名方法も考えてみる、くらいが良さそう。

鍵への署名方法のバリエーション（折りたたみ）

              sign   Make  a  signature on key of user name. If the key is not yet signed by the default user (or the users given with -u), the program displays the information of the key again, together with its fingerprint and asks
                     whether it should be signed. This question is repeated for all users specified with -u.

              lsign  Same as "sign" but the signature is marked as non-exportable and will therefore never be used by others. This may be used to make keys valid only in the local environment.

              nrsign Same as "sign" but the signature is marked as non-revocable and can therefore never be revoked.

              tsign  Make a trust signature. This is a signature that combines the notions of certification (like a regular signature), and trust (like the "trust" command). It is generally useful in distinct communities or groups to
                     implement the concept of a Trusted Introducer.  For more information please read the sections ‘‘Trust Signature'' and ‘‘Regular Expression'' in RFC-4880.

              Note that "l" (for local / non-exportable), "nr" (for non-revocable, and "t" (for trust) may be freely mixed and prefixed to "sign" to create a signature of any type desired.

ちなみに鍵に行った署名をやっぱナシとする場合は、 --edit-key 派生からの delsig での削除や revsig での失効証明が使える。以下は delsig での例。

# Bob の鍵の状態（有効性が充分になっている）
❯ gpg --edit-key [email protected]
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  nistp521/9C01CED50692C931
     作成: 2024-03-24  有効期限: 無期限      利用法: SC
     信用: 不明の     有効性: 充分
sub  nistp521/5E65B12213CABE80
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  充分  ] (1). Bob <[email protected]>

# (1) Bob を選択
gpg> uid 1

pub  nistp521/9C01CED50692C931
     作成: 2024-03-24  有効期限: 無期限      利用法: SC
     信用: 不明の     有効性: 充分
sub  nistp521/5E65B12213CABE80
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  充分  ] (1)* Bob <[email protected]>

# 署名を削除（何故か Bob 自身の自己署名も削除しようとするが、 Alice で行った署名のみ Yes にする）
gpg> delsig
uid  Bob <[email protected]>
sig!3        9C01CED50692C931 2024-03-24  [自己署名]
この正しい署名を削除しますか? (y/N/q)N
uid  Bob <[email protected]>
sig!         D7817D5403305F41 2024-03-25  Alice <[email protected]>
この正しい署名を削除しますか? (y/N/q)y
1個の署名を削除しました。

# 変更を保存
gpg> save

# Bob の鍵を改めて確認（有効性が不明になっている）
❯ gpg --edit-key [email protected]
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


gpg: 信用データベースの検査
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: 深さ: 0  有効性:   1  署名:   0  信用: 0-, 0q, 0n, 0m, 0f, 1u
pub  nistp521/9C01CED50692C931
     作成: 2024-03-24  有効期限: 無期限      利用法: SC
     信用: 不明の     有効性: 不明の
sub  nistp521/5E65B12213CABE80
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  不明  ] (1). Bob <[email protected]>

他人の信用を設定する場合（OwnerTrust）

自分の鍵で行ったので今更な気もするが、鍵の信用を設定する方法になる。

要は Web of Trust の設定になるが、この辺の話は前回の記事の Web of Trust 辺りを参照。上記で鍵の正当性を確認したユーザ Bob を充分に信頼すると設定する。やることとしては最初に自分の鍵の信用を設定した場合とほぼ同じ。

# 設定前の状態（信用が不明）
❯ gpg --edit-key [email protected]
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  nistp521/9C01CED50692C931
     作成: 2024-03-24  有効期限: 無期限      利用法: SC
     信用: 不明の     有効性: 充分
sub  nistp521/5E65B12213CABE80
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  充分  ] (1). Bob <[email protected]>

# 信用の設定をする（今回は「充分に信用する」に設定する）
gpg> trust
pub  nistp521/9C01CED50692C931
     作成: 2024-03-24  有効期限: 無期限      利用法: SC
     信用: 不明の     有効性: 充分
sub  nistp521/5E65B12213CABE80
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  充分  ] (1). Bob <[email protected]>

他のユーザの鍵を正しく検証するために、このユーザの信用度を決めてください
(パスポートを見せてもらったり、他から得たフィンガープリントを検査したり、などなど)

  1 = 知らない、または何とも言えない
  2 = 信用し ない
  3 = まぁまぁ信用する
  4 = 充分に信用する
  5 = 究極的に信用する
  m = メーン・メニューに戻る

あなたの決定は? 4

pub  nistp521/9C01CED50692C931
     作成: 2024-03-24  有効期限: 無期限      利用法: SC
     信用: 充分        有効性: 充分
sub  nistp521/5E65B12213CABE80
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  充分  ] (1). Bob <[email protected]>
プログラムを再起動するまで、表示された鍵の有効性は正しくないかもしれない、
ということを念頭においてください。

# 一旦終了
gpg> quit

# 改めて Bob の信用を確認（充分になっている）
❯ gpg --edit-key [email protected]
gpg (GnuPG) 2.4.5; Copyright (C) 2024 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


gpg: 信用データベースの検査
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: 深さ: 0  有効性:   1  署名:   1  信用: 0-, 0q, 0n, 0m, 0f, 1u
gpg: 深さ: 1  有効性:   1  署名:   0  信用: 0-, 0q, 0n, 0m, 1f, 0u
pub  nistp521/9C01CED50692C931
     作成: 2024-03-24  有効期限: 無期限      利用法: SC
     信用: 充分        有効性: 充分
sub  nistp521/5E65B12213CABE80
     作成: 2024-03-24  有効期限: 無期限      利用法: E
[  充分  ] (1). Bob <[email protected]>

gpg>

という感じで、他人の信用を設定できる。ちなみに信用の設定は鍵への署名操作と違って save せずとも反映される。

最後の確認のところに「信用データベースの検査」という部分があるが、これは信用を設定しているユーザの署名情報から、自分が直接署名していない鍵の有効性を判定すルールである「信用モデル」を示している。今回は信用モデルとして pgp を使っていて、これを変更すれば鍵の有効性を判定するルールを変更できそうという事も分かる。

信用モデルの選択肢として何があるかは man gpg に書かれているので貼り付けておく。それぞれの信用モデルが具体的にどういうルールになっているかは今回細かく追ってないが、他人の信用を設定して使う場合はちゃんと確認しておいた方が良さそう。

信用モデル一覧（折りたたみ）

       --trust-model {pgp|classic|tofu|tofu+pgp|direct|always|auto}
              Set what trust model GnuPG should follow. The models are:

              pgp    This is the Web of Trust combined with trust signatures as used in PGP 5.x and later. This is the default trust model when creating a new trust database.

              classic
                     This is the standard Web of Trust as introduced by PGP 2.

              tofu

                     TOFU stands for Trust On First Use.  In this experimental trust model, the first time a key is seen, it is memorized.  If later another key with a user id with the same email address is seen, both keys are marked
                     as suspect.  In that case, the next time either is used, a warning is displayed describing the conflict, why it might have occurred (either the user generated a new key and failed to cross sign the  old  and  new
                     keys, the key is forgery, or a man-in-the-middle attack is being attempted), and the user is prompted to manually confirm the validity of the key in question.

                     Because  a potential attacker is able to control the email address and thereby circumvent the conflict detection algorithm by using an email address that is similar in appearance to a trusted email address, when‐
                     ever a message is verified, statistics about the number of messages signed with the key are shown.  In this way, a user can easily identify attacks using fake keys for regular correspondents.

                     When compared with the Web of Trust, TOFU offers significantly weaker security guarantees.  In particular, TOFU only helps ensure consistency (that is, that the binding between a key  and  email  address  doesn't
                     change).   A  major  advantage  of TOFU is that it requires little maintenance to use correctly.  To use the web of trust properly, you need to actively sign keys and mark users as trusted introducers.  This is a
                     time-consuming process and anecdotal evidence suggests that even security-conscious users rarely take the time to do this thoroughly and instead rely on an ad-hoc TOFU process.

                     In the TOFU model, policies are associated with bindings between keys and email addresses (which are extracted from user ids and normalized).  There are  five  policies,  which  can  be  set  manually  using  the
                     --tofu-policy option.  The default policy can be set using the --tofu-default-policy option.

                     The  TOFU  policies  are:  auto,  good, unknown, bad and ask.  The auto policy is used by default (unless overridden by --tofu-default-policy) and marks a binding as marginally trusted.  The good, unknown and bad
                     policies mark a binding as fully trusted, as having unknown trust or as having trust never, respectively.  The unknown policy is useful for just using TOFU to detect conflicts, but to never assign positive  trust
                     to  a  binding.  The final policy, ask prompts the user to indicate the binding's trust.  If batch mode is enabled (or input is inappropriate in the context), then the user is not prompted and the undefined trust
                     level is returned.

              tofu+pgp
                     This experimental trust model combines TOFU with the Web of Trust.  This is done by computing the trust level for each model and then taking the maximum trust level where the trust levels are ordered as  follows:
                     unknown < undefined < marginal < fully < ultimate < expired < never.

                     By  setting  --tofu-default-policy=unknown, this model can be used to implement the web of trust with TOFU's conflict detection algorithm, but without its assignment of positive trust values, which some security-
                     conscious users don't like.

              direct Key validity is set directly by the user and not calculated via the Web of Trust.  This model is solely based on the key and does not distinguish user IDs.  Note that when changing  to  another  trust  model  the
                     trust values assigned to a key are transformed into ownertrust values, which also indicate how you trust the owner of the key to sign other keys.

              always Skip  key  validation and assume that used keys are always fully valid. You generally won't use this unless you are using some external validation scheme. This option also suppresses the "[uncertain]" tag printed
                     with signature checks when there is no evidence that the user ID is bound to the key.  Note that this trust model still does not allow the use of expired, revoked, or disabled keys.

              auto   Select the trust model depending on whatever the internal trust database says. This is the default model if such a database already exists.  Note that a tofu trust model is not considered here and must be enabled
                     explicitly.

補足

GPG の設定

今回は GPG の設定は何もせず空の状態で実行しているが、各種設定ファイルを配置する事で挙動の調整もできる。

設定ファイルは ~/.gnupg/ に配置するが、このディレクトは環境変数として GNUPGHOME を設定することで変更もできる。ただ設定ファイルだけじゃなく秘密鍵のデータ等もここに含まれ、変に動かすとそのうち事故りそうな気がしたため自分はそのままにしている。

gpg.conf

基本の設定ファイルとしては ~/.gnupg/gpg.conf になる。

設定できる項目としては、 man gpg の OPTIONS にあるものから-- を除いたものが設定できる。例えば鍵のリスト時に --keyid-format long をデフォルトにしたければ、設定ファイルに keyid-format long を記述すれば良い。

とは言え、基本的にはデフォルトで良い感じの設定がされているっぽく今のところ何も設定していない。少しググった程度 ⁴ ではあるが、最低限コレは設定しとけみたいなものもあまりなく、あっても GPG の古いバージョン使ってるなら設定しておくと良い（今のバージョンだとデフォルトになってる）みたいなものが多かった。

「強い暗号アルゴリズムを使う」みたいな方向での設定もあるが、自分の場合その辺りの設定が妥当かどうかの判断が付かないので、変に自分で設定するよりは GPG のデフォルトに任せる方が良いか、ということで手は付けてない。

設定するとすれば、自分の鍵を作った後は default-key とかその辺りを設定しておくと便利そう、公開鍵サーバを使うなら keyserver とかその辺り、くらいな印象。いずれにしろ使ってて何か欲しくなったら改めて設定項目眺める、くらいのつもりでいる。

gpg-agent.conf

gpg-agent はざっくりとは GPG と他プログラムと連携するためのプログラム（のはず）。

パスフレーズの入力時や鍵削除時の確認等で、コマンドを叩いているターミナルとは別のウィンドウが開いたりしていたのもこのエージェントが仲介している。入力したパスフレーズを一定時間キャッシュしたり、 SSH に使う鍵を GPG で管理したりする際にも、このエージェントが仕事をする。で、このエージェントの設定に ~/.gnupg/gpg-agent.conf を使う。

今回はパスフレーズの入力をターミナル内で完結させるために pinentry-program の設定を追加した。

pinentry-program /usr/bin/pinentry-curses

反映にはエージェントのリロードを行う必要があり、以下コマンドで行う。

❯ gpg-connect-agent reloadagent /bye
OK

また gpg-agent の設定全てで必要になるわけでは無いが、上記の pinentry-program の設定をちゃんと動作させるために環境変数として GPG_TTY を設定しておく必要があるので、（Bash の場合） ~/.bashrc に以下の2行を追加しておく。

export GPG_TTY=$(tty)
gpg-connect-agent updatestartuptty /bye >/dev/null

これで、パスフレーズの入力等で別でウィンドウが開くことも無く、

pinentry 変更前のパスフレーズ入力画面 — pinentry 変更前 ( pinentry-gtk-2 )

こんな感じでターミナルで完結できる様になる。

pinentry-curses でのパスフレーズ入力画面 — pinentry 変更後 ( pinentry-curses )

鍵の種類と暗号強度

GPG で使える鍵の種類と暗号強度をまとめておく。

この辺をちゃんと理解するには前提知識が色々足りないし、今の所はちゃんと勉強する程のモチベーションも無いので、今回はあまり追わず暗号強度的に強そうなものを選んで使った。

暗号種別	鍵の種類と鍵長	暗号強度	補足
RSA	RSA 2048bit	112bit	GPG 2.4.5 での RSA 鍵のデフォルト鍵長
RSA	RSA 3072bit	128bit
RSA	RSA 4096bit	128〜192bit	GPG 2.4.5 での RSA 鍵の最大鍵長
DSA	DSA 2048bit	112bit	GPG 2.4.5 での DSA 鍵のデフォルト鍵長
DSA	DSA 3072bit	128bit	GPG 2.4.5 での DSA 鍵の最大鍵長
ECC	Curve 25519	128bit	GPG 2.4.5 でのデフォルト選択肢
ECC	Curve 448	224bit
ECC	NIST P-256	128bit
ECC	NIST P-384	192bit
ECC	NIST P-521	256bit
ECC	Brainpool P256	128bit
ECC	Brainpool P384	192bit
ECC	Brainpool P512	256bit
ECC	scp256k1	128bit

どのくらいの暗号強度が必要かについても自分ではイマイチ評価できなかったが、これについては CRYPTREC という日本政府主導のプロジェクトで評価しているものが見つかった。そこが2022年頃に行った評価では、 2040年くらいまでなら 128bit 以上の暗号強度、それ以降は 192bit 以上の暗号強度が一応の目安になるっぽい。

CRYPTREC | CRYPTREC暗号リスト(電子政府推奨暗号リスト)

おわりに

時間が掛かったが、色々試した分感覚はそれなりに掴めた気がする。 SSH 用の鍵管理だったり、 Git でのコミット署名だったり、公開鍵サーバの利用だったり、応用的なものはそのうち試してみようと思う。

参考

GPG で行える操作を全部試したわけではないが、少なくとも今回試したような基本的な操作の場合はそんな感じだった ↩︎
鍵を失効させた理由が秘密鍵の流出だった場合、流出から失効までのタイムラグをどう考えるかみたいな細かい話はあるが ↩︎
鍵束から削除する前にエクスポートしてどっかに保管しておくとかもアリだとは思う ↩︎
ArchWiki や Gentoo Wiki 、あとは「gpg best practice」とかでググって引っかかったものをいくつか ↩︎