「GnuPG」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(style fix)
 
(8人の利用者による、間の97版が非表示)
1行目: 1行目:
[[Category:セキュリティ]]
+
[[Category:暗号化]]
  +
[[Category:OpenPGP]]
  +
[[Category:メール]]
  +
[[Category:GNU]]
 
[[en:GnuPG]]
 
[[en:GnuPG]]
 
[[es:GnuPG]]
 
[[es:GnuPG]]
 
[[ru:GnuPG]]
 
[[ru:GnuPG]]
  +
[[zh-hans:GnuPG]]
[http://www.gnupg.org 公式サイト] によれば:
 
  +
[[zh-hant:GnuPG]]
  +
{{Related articles start}}
  +
{{Related|pacman-key}}
  +
{{Related|ディスク暗号化}}
  +
{{Related|アプリケーション一覧/セキュリティ#暗号化, 署名, ステガノグラフィー}}
  +
{{Related articles end}}
  +
[https://www.gnupg.org/ 公式サイト] によれば:
   
:GnuPG は RFC4880 (別名 [[Wikipedia:PGP|PGP]]) で定義される OpenPGP 標準の完全でフリーな実装です。GnuPG を使うことでデータや通信を暗号化したり署名することができます。多目的の鍵管理システムであり、あらゆる種類の公開鍵ディレクトリのアクセスモジュールです。GnuPG (またの名を GPG) は他のアプリケーションとの簡単に連携できる機能を備えたコマンドラインツールです。豊富なアプリケーションとライブラリが利用可能です。GnuPG のバージョン2は S/MIME と ssh のサポートも含んでいます。
+
:GnuPG は [https://tools.ietf.org/html/rfc4880 RFC4880] (別名 PGP) で定義される [http://openpgp.org/about/ OpenPGP] 標準の完全でフリーな実装です。GnuPG を使うことでデータや通信を暗号化したり署名することができます。多目的の鍵管理システムであり、あらゆる種類の公開鍵ディレクトリのアクセスモジュールです。GnuPG (またの名を GPG) は他のアプリケーションとの簡単に連携できる機能を備えたコマンドラインツールです。豊富なアプリケーションとライブラリが利用可能です。GnuPG のバージョン2は S/MIME と ssh のサポートも含んでいます。
  +
  +
{{Warning|GnuPG は [[OpenPGP]] 形式の実装として始まりました。しかし、近年、そのメンテナは [[OpenPGP#Standardization|OpenPGP 標準化の取り組み]]、GnuPG 固有の方法で形式を個別に拡張しています ([https://datatracker.ietf.org/doc/draft-koch-librepgp/ draft-koch-librepgp] を参照) これらの変更により、バージョン 2.4 以降の他の実装との互換性の問題が発生します。[[#OpenPGP の互換性]] を参照してください。}}
   
 
== インストール ==
 
== インストール ==
11行目: 23行目:
 
{{Pkg|gnupg}} をインストールしてください。
 
{{Pkg|gnupg}} をインストールしてください。
   
gnupg をインストールすると、GnuPG がパスフレーズエントリに使用するシンプルな PIN やパスフレーズエントリダイアログのコレクションである {{Pkg|pinentry}} もインストールされます。''pinentry'' はンボリックリンク {{ic|/usr/bin/pinentry}} によっ決められデフォルトでは {{ic|/usr/bin/pinentry-gtk-2}} になります。
+
gnupg をインストールすると、GnuPG がパスフレーズエントリに使用するシンプルな PIN やパスフレーズエントリダイアログのコレクションである {{Pkg|pinentry}} もインストールされます。シェルスクリプト {{ic|/usr/bin/pinentry}} は [[#pinentry]] で説明されいる順番でどの ''pinentry'' ダイアログを使用するかを決定します。
   
 
グラフィカルフロントエンドや GnuPG と連携するプログラムを使いたい場合は[[アプリケーション一覧/セキュリティ#暗号化, 署名, ステガノグラフィー]]を参照してください。
 
グラフィカルフロントエンドや GnuPG と連携するプログラムを使いたい場合は[[アプリケーション一覧/セキュリティ#暗号化, 署名, ステガノグラフィー]]を参照してください。
   
== 環境変数 ==
+
== 設定 ==
   
  +
=== 設定ファイルのディレクトリ ===
=== GNUPGHOME ===
 
   
{{ic|$GNUPGHOME}} 全ての設定ファイルを保存するディレクトリ指定するのに GnuPG によって使われます。デフォルトでは {{ic|$GNUPGHOME}} は設定されておらず、代わりに {{ic|$HOME}} が使われます。そのためインストール直後は {{ic|~/.gnupg}} ディレクトリが確認できます。[[自動起動|スタートアップファイル]]に次の行を記述することでデフォルト設定を変更できます:
+
GnuPG では {{ic|$GNUPGHOME}} によって全ての設定ファイルを保存するディレクトリ指定れます。デフォルトでは {{ic|$GNUPGHOME}} は設定されておらず、代わりに {{ic|$HOME}} が使われます。そのためインストール直後は {{ic|~/.gnupg}} ディレクトリが確認できます。[[自動起動|スタートアップファイル]]に次の行を記述することでデフォルト設定を変更できます:
   
 
export GNUPGHOME="''/path/to/directory''"
 
export GNUPGHOME="''/path/to/directory''"
   
  +
=== 設定ファイル ===
{{Note|デフォルトでは、gnupg ディレクトリの[[ファイルのパーミッションと属性|パーミッション]]は ''700'' に設定されており、ディレクトリのファイルのパーミッションは ''600'' に設定されています。ファイルの読み書きやアクセスの権限を持っているのはディレクトリの所有者だけです (''r'',''w'',''x'')。これはセキュリティ上の理由で設定されていることなので変更してはいけません。ディレクトリやファイルがこのセキュリティ対策に従っていない場合、ファイルやホームディレクトリのパーミッションが安全ではないという警告が表示されます。}}
 
   
  +
デフォルトの設定ファイルは {{ic|~/.gnupg/gpg.conf}} と {{ic|~/.gnupg/dirmngr.conf}} です。
== 設定ファイル ==
 
   
  +
デフォルトでは、gnupg ディレクトリの[[ファイルのパーミッションと属性|パーミッション]]は ''700'' に設定されており、ディレクトリのファイルのパーミッションは ''600'' に設定されています。ファイルの読み書きやアクセスの権限を持っているのはディレクトリの所有者だけです (''r'',''w'',''x'')。これはセキュリティ上の理由で設定されていることなので変更してはいけません。ディレクトリやファイルがこのセキュリティ対策に従っていない場合、ファイルやホームディレクトリのパーミッションが安全ではないという警告が表示されます。
デフォルトは {{ic|~/.gnupg/gpg.conf}} と {{ic|~/.gnupg/dirmngr.conf}} です。デフォルトの場所を変更したい場合は、{{ic|$ gpg --homedir ''path/to/file''}} と gpg を実行するか {{ic|$GNUPGHOME}} 変数を使って下さい。どんな長いオプションもこのファイルに追加します。2つのダッシュを書かないで、オプションや必要な引数の名前を書いて下さい。スケルトンファイルは {{ic|/usr/share/gnupgl}} にあります。gpg がなんらかの操作のため最初に起動されたとき、{{ic|~/.gnupg}} が存在しなければこれらのファイルが {{ic|~/.gnupg}} にコピーされます。[[#参照]] に他の例があります。
 
  +
  +
どんな長いオプションも設定ファイルに追加します。2つのダッシュを書かないで、オプションや必要な引数の名前を書いて下さい。スケルトンファイルは {{ic|/usr/share/doc/gnupg/}} にあります。gpg がなんらかの操作のため最初に起動されたとき、{{ic|~/.gnupg}} が存在しなければこれらのファイルが {{ic|~/.gnupg}} にコピーされます。[[#参照]] に他の例があります。
  +
  +
また、[[pacman]] がパッケージの署名の検証に使用する設定ファイルは別に存在します。詳しくは [[pacman-key]] を見てください。
  +
  +
=== 新規ユーザーのデフォルトオプション ===
  +
  +
新規ユーザーのデフォルトオプションを設定したい場合、{{ic|/etc/skel/.gnupg/}} に設定ファイルを配置してください。新しいユーザーが追加されると、{{ic|/etc/skel/.gnupg/}} から GnuPG のホームディレクトリにファイルがコピーされます。既存のユーザーのために新しい GnuPG ホームディレクトリを作成できる ''addgnupghome'' というスクリプトも存在します:
  +
  +
# addgnupghome user1 user2
  +
  +
上記のコマンドは {{ic|/home/user1/.gnupg}} と {{ic|/home/user2/.gnupg}} を作成してスケルトンディレクトリからファイルをコピーします。既に GnuPG のホームディレクトリが存在するユーザーはスキップされます。
   
 
== 使い方 ==
 
== 使い方 ==
   
  +
{{Note|コマンドに ''{{ic|<user-id>}}'' が必要なときは、鍵 ID、指紋、名前やメールアドレスの一部などを指定できます。これについて GnuPG は寛容です。}}
{{Note|
 
* コマンドに ''{{ic|<user-id>}}'' が必要なときは、鍵 ID、指紋、名前やメールアドレスの一部などを指定できます。これについて GnuPG は寛容です。
 
* 以下のステップのいくつかは、使用法によってはメールクライアントなどの外部プログラムにより提供されていることもあります。[[アプリケーション一覧/セキュリティ#暗号化, 署名, ステガノグラフィー]]も参照}}
 
   
=== 鍵の作成 ===
+
=== 鍵ペアの作成 ===
   
秘密鍵を生成するにはターミナルに次を入力:
+
ペアを生成するにはターミナルに次を入力:
   
 
$ gpg --full-gen-key
 
$ gpg --full-gen-key
43行目: 65行目:
 
{{Tip|{{ic|--expert}} を使うことで他の暗号を利用することができます ([[wikipedia:ja:楕円曲線暗号|楕円曲線暗号]]など)。}}
 
{{Tip|{{ic|--expert}} を使うことで他の暗号を利用することができます ([[wikipedia:ja:楕円曲線暗号|楕円曲線暗号]]など)。}}
   
  +
上記のコマンドを実行すると複数の質問がきかれます。大抵の場合、以下の設定が必要になります:
いくつか質問がきかれます。一般的に、ほとんどのユーザーは RSA (署名のみ) と RSA (暗号化のみ) の両方の鍵が必要になります。鍵長は2048ビットで十分です。4096ビットを使ったところで [https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096 "大した効果はありませんし、無駄に時間がかかるようになるだけです"] 。
 
   
  +
* RSA (署名のみ) と RSA (暗号化のみ) 鍵。
副鍵の有効期限の設定は技術的には必須ではありませんが、設定することは悪くありません。標準的なユーザーなら、1年間で十分でしょう。たとえ鍵束へのアクセスを失っても、他の人が有効でないことを知ることができるようになります。鍵を作成した後、新しい鍵を再発行しなくても満了日は延長することができます。
 
  +
* 鍵長は2048ビットで十分です。4096ビットを使ったところで [https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096 "大した効果はありませんし、無駄に時間がかかるようになるだけです"] 。
  +
* 副鍵の有効期限の設定は技術的には必須ではありませんが、設定することは悪くありません。標準的なユーザーなら、1年間で十分でしょう。たとえ鍵束へのアクセスを失っても、他の人が有効でないことを知ることができるようになります。鍵を作成した後、新しい鍵を再発行しなくても満了日は延長することができます。
  +
* 名前とメールアドレス。後で同じ鍵に別の識別子を追加できます (複数のメールアドレスが存在する場合など)。
  +
* コメントは必要ありません。コメントフィールドのセマンティクスは [https://lists.gnupg.org/pipermail/gnupg-devel/2015-July/030150.html 定義があやふや] なため、識別子としては限定的です。
  +
* 安全なパスフレーズを選ぶようにしてください ([[セキュリティ#パスワードの管理]]を参照)。
   
  +
{{Note|入力した名前とメールアドレスは鍵をインポートすれば誰でも確認できるようになります。}}
安全なパスフレーズを選ぶようにしてください ([[セキュリティ#パスワードの管理]]を参照)。
 
   
=== 秘密のバックアップ ===
+
=== 鍵一覧 ===
   
  +
* 公開鍵束の鍵の一覧:
秘密鍵をバックアップするには:
 
   
$ gpg --export-secret-keys --armor ''<user-id>'' > privkey.asc
+
$ gpg --list-keys
   
  +
* 秘密鍵束の鍵の一覧:
秘密鍵はロックされたコンテナや暗号化されたドライブなど安全な場所に置いてください。
 
   
  +
$ gpg --list-secret-keys
{{Warning|上記のエクスポートされたファイルにアクセスできる人は誰でも、''パスフレーズを知らなくても''あなたのふりをして文書を暗号化したり署名したりできます。}}
 
   
 
=== 公開鍵のエクスポート ===
 
=== 公開鍵のエクスポート ===
  +
  +
公開鍵暗号で交換されたメッセージの機密性を保証するのが gpg の主な利用法です。互いの鍵束の公開鍵を交換して、メッセージを暗号化するときに使用します。秘密鍵は必ず漏洩しないようにしてください。機密性が破れてしまいます。
   
 
他の人があなたに暗号化したメッセージを送れるようにするには、彼らがあなたの公開鍵を知っている必要があります。
 
他の人があなたに暗号化したメッセージを送れるようにするには、彼らがあなたの公開鍵を知っている必要があります。
   
(メールで送る場合などのために) ASCII 版の公開鍵を生成するには:
+
(メールで送る場合などのために) ASCII 版の公開鍵を {{ic|''public.key''}} ファイルとして生成するには:
   
$ gpg --armor --output public.key --export ''<user-id>''
+
$ gpg --output ''public.key'' --armor --export ''user-id''
   
あるいは、[[#鍵サーバを使用する|鍵サーバ]]で鍵を共有する方法もあります。
+
あるいは、[[#鍵サーバを使用する|鍵サーバ]]で鍵を共有する方法もあります。
   
  +
{{Tip|
{{Tip|{{ic|--no-emit-version}} を使うか、これを設定ファイルに書くことでバージョン番号の表示を抑制できます。}}
 
  +
* {{ic|--no-emit-version}} を使うか、これを設定ファイルに書くことでバージョン番号の表示を抑制できます。
  +
* {{ic|user-id}} を省略して、キーリング内のすべての公開鍵をエクスポートできます。これは、一度に複数の ID を共有したい場合や、別のアプリケーションにインポートする場合に便利です。例: [[Thunderbird#Use_OpenPGP_with_external_GnuPG|Thunderbird]]。}}
   
=== 鍵のインポート ===
+
=== 公開鍵のインポート ===
   
メッセージを暗号化して他の人に送るには、彼らの公開鍵が必要です。公開鍵を自分の公開鍵リングにインポートするには:
+
メッセージを暗号化して他の人に送るには、彼らの公開鍵が必要です。公開鍵 ({{ic|''public.key''}}) を自分の公開鍵リングにインポートするには:
   
 
$ gpg --import public.key
 
$ gpg --import public.key
   
あるいは、[[#鍵サーバを使用する|鍵サーバ]]で公開鍵を見つけます。
+
あるいは、[[#鍵サーバを使用する|鍵サーバ]]で公開鍵を見つけます。
   
  +
特定の Arch Linux パッケージをインストールするためにキー ID をインポートしたい場合は、[[pacman-key#キーリングの管理|キーリングの管理]] と [[Makepkg#署名チェック]] を参照してください。
=== 鍵サーバを使用する ===
 
   
  +
=== 鍵サーバーを使用する ===
自分の公開鍵を公共の PGP 鍵サーバに登録することで、他の人があなたに直接連絡することなしにあなたの鍵を入手できるようになります。
 
   
  +
==== 鍵の送信 ====
$ gpg --send-keys ''<key-id>''
 
   
  +
自分の公開鍵を公共の PGP 鍵サーバーに登録することで、他の人があなたに直接連絡することなしにあなたの鍵を入手できるようになります:
鍵サーバから鍵をインポートするには:
 
   
$ gpg --recv-keys ''<key-id>''
+
$ gpg --send-keys ''user-id''
   
  +
{{Warning|鍵を鍵サーバーに登録してから、サーバーから鍵を削除することはできません [https://pgp.mit.edu/faq.html]。 その理由は、[https://pgp.mit.edu/faq.html MIT PGP Public Key Server FAQ]で説明されています。}}
{{Warning|誰でも鍵サーバに鍵を送ることができます。そのため、ダウンロードした鍵が本当にその人のものであると信用してはいけません。入手した鍵の指紋を、持ち主が別の場所(ブログ、サイト、メール・電話で連絡するなど)で公開している指紋と比較してその鍵の真正性を確かめるべきです。複数の情報源を使うことでその鍵の信頼性は増します。[[Wikipedia:Public key fingerprint]] を参照。}}
 
  +
{{Note|関連するメールアドレスが公開されると、スパムメールの標的となる可能性があり、この場合、スパム対策用のフィルタリングが必要となる場合があります。}}
  +
  +
==== 鍵の検索と受信 ====
  +
  +
鍵サーバーの鍵の情報を確認したい場合、次のコマンドを実行:
  +
  +
$ gpg --search-keys ''user-id''
  +
  +
鍵サーバーから鍵をインポートするには:
  +
  +
$ gpg --recv-keys ''key-id''
  +
  +
{{Warning|
  +
* 誰でも鍵サーバーに鍵を送ることができます。そのため、ダウンロードした鍵が本当にその人のものであると信用してはいけません。入手した鍵の指紋を、持ち主が別の場所(ブログ、サイト、メール・電話で連絡するなど)で公開している指紋と比較してその鍵の真正性を確かめるべきです。複数の情報源を使うことでその鍵の信頼性は増します。[[Wikipedia:Public key fingerprint]] を参照。
  +
* ID が短いと衝突する可能性があります。インポートされた鍵には全て短い ID が割り当てられます。鍵を受け取るときに完全な指紋か長い鍵 ID を使うことで衝突を回避できます [https://lkml.org/lkml/2016/8/15/445]。
  +
}}
  +
  +
{{Tip|{{ic|auto-key-retrieve}} を {{ic|gpg.conf}} に追加すると、必要に応じて鍵サーバから鍵を自動的に取得しますが、これは '''プライバシー侵害''' と見なされる可能性があります。{{man|1|gpg}} の "web bug" を参照。}}
  +
  +
==== 鍵サーバー ====
  +
  +
最も一般的な鍵サーバーは次の通りです:
  +
  +
* [https://keyserver.ubuntu.com Ubuntu Keyserver]: 分散型、検証なし、キーは削除不可。
  +
* [https://keys.mailvelope.com Mailvelope Keyserver]: 中央型、E メール ID の検証、キーは削除可能。
  +
* [https://keys.openpgp.org keys.openpgp.org]: 中央型、E メール ID の検証、キーは削除可能。サードパーティの署名無し (つまり、Web of Trust のサポートは無し)。
  +
  +
[[Wikipedia:Key server (cryptographic)#Keyserver examples]] にその他の鍵サーバもあります。
  +
  +
代替の鍵サーバは、[[#設定ファイル]]のうちどれかで {{ic|keyserver}} オプションを使用することによって指定することができます。例えば:
  +
  +
{{hc|~/.gnupg/dirmngr.conf|
  +
keyserver hkp://keyserver.ubuntu.com
  +
}}
  +
  +
いつも使用しているサーバが思うように動かない時に、一時的に別のサーバを使用すると便利です。例えば、以下のようにして別のサーバを使用できます:
  +
  +
$ gpg --keyserver ''hkps://keys.openpgp.org/'' --search-keys ''user-id''
   
 
{{Tip|
 
{{Tip|
  +
* デフォルトの hkps 鍵サーバプールを使用していて、{{ic|gpg: keyserver receive failed: General error}} というメッセージで失敗する場合、{{ic|dirmngr.conf}} 内で {{ic|hkp-cacert /usr/share/gnupg/sks-keyservers.netCA.pem}} を使用して HKPS プールの検証証明書を設定し、古い dirmngr プロセスを kill してください。
* 代わりの鍵サーバは {{ic|pool.sks-keyservers.net}} で {{ic|--keyserver}} で指定できます。[[wikipedia:Key server (cryptographic)#Keyserver examples]] を参照
 
  +
* {{ic|gpg: keyserver receive failed: Connection refused}} というメッセージで失敗する場合、別の DNS サーバを使ってみてください。
* {{ic|--use-tor}} を使うと [[Tor]] で鍵サーバに接続できます。{{ic|hkp://jirk5u4osbsr34t5.onion}} は sks-keyservers プールの onion アドレスです。[https://gnupg.org/blog/20151224-gnupg-in-november-and-december.html GnuPG のブログ記事] を参照。}}
 
  +
* [[Tor#Torsocks]] で [[Tor]] 経由で鍵サーバに接続することもできます。また、{{ic|--use-tor}} コマンドラインオプションもあります。詳細は [https://gnupg.org/blog/20151224-gnupg-in-november-and-december.html] を参照してください。
  +
* {{ic|http_proxy}} [[環境変数]]を設定し、{{ic|dirmngr.conf}} 内で {{ic|honor-http-proxy}} を設定すれば、プロキシを使って鍵サーバに接続することもできます。また、設定ファイル内で {{ic|http-proxy ''host[:port]''}} を使えば、先の環境変数をオーバーライドすることができます。変更を適用するには、{{ic|dirmngr.service}} [[ユーザーユニット]]を[[再起動]]してください。
  +
* {{ic|gpg: keyserver receive failed: Server indicated a failure}} というメッセージで鍵サーバに接続できない場合、別のポートを使用するように gpg を設定する必要があるのかもしれません。例えば、Ubuntu の鍵サーバで80番ポートを使用するには、{{ic|keyserver hkp://keyserver.ubuntu.com:80}} と設定してください。
  +
}}
  +
  +
=== Web Key Directory ===
  +
  +
Web Key Service (WKS) プロトコルは、鍵配布のための新しい [https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/ 標準]で、電子メールドメインが [https://wiki.gnupg.org/WKD Web Key Directory (WKD)] という独自の鍵サーバーを提供するものです。電子メールアドレス (例 : {{ic|user@example.com}}) に暗号化するとき、GnuPG (>=2.1.16) は、公開鍵をローカル鍵束にまだ持っていなければ、 HTTPS でそのドメイン ({{ic|example.com}}) に照会します。オプション {{ic|auto-key-locate}} は、このメールアドレスのローカル鍵束に鍵がない場合、WKD プロトコルを使って鍵を探します。
  +
  +
# gpg --recipient ''user@example.org'' --auto-key-locate --encrypt ''doc''
  +
  +
WKD をサポートしているメールプロバイダーの一覧は [https://wiki.gnupg.org/WKD#Implementations GnuPG Wiki] を参照してください。メールアドレスのドメインを自分で管理している場合は、[https://wiki.gnupg.org/WKDHosting このガイド]に従って、自分のドメインで WKD を有効にすることができます。あなたの鍵が WKD で見つかるかどうかを確認するには、[https://metacode.biz/openpgp/web-key-directory このウェブインターフェイス]が使用できます。
   
 
=== 暗号化と復号化 ===
 
=== 暗号化と復号化 ===
   
  +
==== 非対称 ====
暗号化や復号化をするときは複数の秘密鍵を使用することが可能です。複数の鍵を使うときは使用する鍵を選択する必要があります。{{ic|-u ''<user-id>''}} オプションや {{ic|--local-user ''<user-id>''}} オプションを使うことで選択できます。このオプションを使うとデフォルトの鍵を使用する代わりに指定された鍵を使用します。
 
   
  +
暗号化や復号化をするときは複数の秘密鍵を使用することが可能です。複数の鍵を使うときは使用する鍵を選択する必要があります。{{ic|-u ''<user-id>''}} オプションや {{ic|--local-user ''<user-id>''}} オプションを使うことで選択できます。このオプションを使うとデフォルトの鍵を使用する代わりに指定された鍵を使用します。先に[[#鍵の作成]]が必要です。
(テキストでメッセージをコピー&ペーストするのに適している) ASCII armor を使ってファイルを暗号化するには、次を使用:
 
  +
  +
(テキストでメッセージをコピー&ペーストするのに適している) ASCII armor を使ってファイルを暗号化するには、次を使用:
   
 
$ gpg --encrypt --armor secret.txt
 
$ gpg --encrypt --armor secret.txt
107行目: 190行目:
 
{{Tip|
 
{{Tip|
 
* 受取人を変更したい場合は {{ic|-r ''<user-id>''}} (または {{ic|--recipient ''<user-id>''}}) オプションで変更できます。
 
* 受取人を変更したい場合は {{ic|-r ''<user-id>''}} (または {{ic|--recipient ''<user-id>''}}) オプションで変更できます。
  +
* 暗号メッセージに受取人の鍵 ID を入れたくないときは {{ic|--recipient}} のかわりに {{ic|-R ''<user-id>''}} または {{ic|--hidden-recipient ''<user-id>''}} を追加してください。メッセージの受取人を隠蔽して、トラフィックの解析に対する対抗策になります。
* Add {{ic|-R ''<user-id>''}} or {{ic|--hidden-recipient ''<user-id>''}} instead of {{ic|--recipient}} to not put the recipient key IDs in the encrypted message. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis.
 
  +
* バージョン番号を出力したくないときは {{ic|--no-emit-version}} を追加してください。または設定ファイルに同じ設定を追加してください。}}
* Add {{ic|--no-emit-version}} to avoid printing the version number, or add the corresponding setting to your configuration file.}}
 
   
 
{{Note|gnupg を使えば機密文書を暗号化できますが、一度に複数のファイルを暗号化することはできません。ディレクトリやファイルシステム全体を暗号化したいときは、[[TrueCrypt]] や [[EncFS]] などを使用するか、tarball にファイルをまとめて暗号化すると良いでしょう。}}
 
{{Note|gnupg を使えば機密文書を暗号化できますが、一度に複数のファイルを暗号化することはできません。ディレクトリやファイルシステム全体を暗号化したいときは、[[TrueCrypt]] や [[EncFS]] などを使用するか、tarball にファイルをまとめて暗号化すると良いでしょう。}}
   
ファイルを復号化するには、次を使用:
+
ファイルを復号化するには、次のコマンドを使用:
   
 
$ gpg --decrypt secret.txt.asc
 
$ gpg --decrypt secret.txt.asc
   
 
パスフレーズの入力が求められます。復号化するには送信者の公開鍵をインポートしてある必要があります。
 
パスフレーズの入力が求められます。復号化するには送信者の公開鍵をインポートしてある必要があります。
  +
  +
==== 対称 ====
  +
対称暗号化では鍵を生成する必要がなくパスフレーズだけでデータを暗号化できます。対称暗号化を使用するするには {{ic|--symmetric}} または {{ic|-c}} を使用します:
  +
  +
$ gpg -c ''doc''
  +
  +
例:
  +
  +
* パスフレーズを使って対称暗号で {{ic|''doc''}} を暗号化。
  +
* AES-256 暗号アルゴリズムを使ってパスフレーズを暗号化。
  +
* SHA-512 ダイジェストアルゴリズムを使ってパスフレーズをハッシュ化。
  +
* 65536回繰り返しパスフレーズをハッシュ化。
  +
  +
$ gpg -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 65536 ''doc''
  +
  +
対称暗号化された {{ic|''doc''.gpg}} をパスフレーズで復号化して {{ic|''doc''}} として同じディレクトリに出力するには:
  +
  +
$ gpg --output ''doc'' --decrypt ''doc''.gpg
  +
  +
==== ディレクトリ ====
  +
  +
ディレクトリの暗号化・復号化は {{man|1|gpgtar}} で行うことができます。
  +
  +
暗号化:
  +
$ gpgtar -c -o ''dir''.gpg ''dir''
  +
  +
復号化:
  +
$ gpgtar -d ''dir''.gpg
   
 
== 鍵の管理 ==
 
== 鍵の管理 ==
  +
  +
=== 秘密鍵のバックアップ ===
  +
  +
秘密鍵をバックアップするには以下を実行:
  +
  +
$ gpg --export-secret-keys --armor ''<user-id>'' > ''privkey.asc''
  +
  +
''gpg'' のリリース 2.1 からデフォルトの挙動が変わっており、たとえ鍵の作成時にパスワードを設定しなかった場合でも上記のコマンドを実行したときにパスフレーズによる保護が必須になっています。エクスポートされたファイルを入手してしまえば、パスフレーズを知らなくてもファイルを暗号化したり署名を加えることができてしまうためです。
  +
  +
{{Warning|パスフレーズは秘密鍵の最大の弱点となります。暗号化されたコンテナやドライブなど、秘密鍵は安全な場所に保管してください。}}
  +
  +
秘密鍵のバックアップをインポートするには:
  +
$ gpg --import ''privkey.asc''
  +
  +
=== 失効証明書のバックアップ ===
  +
  +
失効証明書は、新しく生成されたキーに対して自動的に生成されます。これらはデフォルトで {{ic|~/.gnupg/openpgp-revocs.d/}} にあります。証明書のファイル名は、取り消すキーのフィンガープリントです。
  +
失効証明書は、ユーザーが後で次を使用して手動で生成することもできます。
  +
  +
$ gpg --gen-revoke --armor --output ''revcert.asc'' ''user-id''
  +
  +
この証明書は、紛失または侵害された場合に [[#鍵の取り消し]] に使用できます。バックアップは、秘密鍵にアクセスできなくなったため、上記のコマンドで新しい失効証明書を生成できない場合に役立ちます。必要に応じて印刷して手で入力できるほど短いです。
  +
  +
{{Warning|失効証明書にアクセスできる人は誰でも、キーを公に失効させることができます。このアクションは元に戻すことはできません。秘密鍵を保護するのと同じように、失効証明書を保護します。}}
   
 
=== 鍵の編集 ===
 
=== 鍵の編集 ===
165行目: 300行目:
 
$ gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.gpg
 
$ gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.gpg
   
  +
{{Warning|''!'' を追加するのを忘れると、全ての副鍵がエクスポートされます。}}
{{Warning|If you forget to add the !, all of your subkeys will be exported.}}
 
   
 
ここで作業を終えても良いですが、パスフレーズの変更もしておくと安全です。一時フォルダに鍵をインポートします:
 
ここで作業を終えても良いですが、パスフレーズの変更もしておくと安全です。一時フォルダに鍵をインポートします:
179行目: 314行目:
 
これで、他のデバイスで {{ic|/tmp/subkey.altpass.gpg}} を使うことができます。
 
これで、他のデバイスで {{ic|/tmp/subkey.altpass.gpg}} を使うことができます。
   
=== 副鍵使用 ===
+
=== 有効期限延長 ===
   
 
{{Warning|何か特段の事情がないかぎり、有効期限が切れたり無効になった副鍵を削除しないでください。削除してしまうとその副鍵で暗号化したファイルを復号化できなくなってしまいます。満了した、または無効のキーを削除するのは他のユーザーの鍵束を整理するときだけにしてください。}}
 
{{Warning|何か特段の事情がないかぎり、有効期限が切れたり無効になった副鍵を削除しないでください。削除してしまうとその副鍵で暗号化したファイルを復号化できなくなってしまいます。満了した、または無効のキーを削除するのは他のユーザーの鍵束を整理するときだけにしてください。}}
198行目: 333行目:
 
> save
 
> save
   
* キーサーバーにアップデート:
+
* サーバーにアップデート:
   
 
$ gpg --keyserver pgp.mit.edu --send-keys ''<user-id>''
 
$ gpg --keyserver pgp.mit.edu --send-keys ''<user-id>''
   
  +
また、この鍵を複数のコンピュータで使用する場合は、公開鍵(新しい署名付き有効期限付き)をエクスポートして、それらのマシンでインポートすることもできます。
{{Note|満了した副鍵を失効させる必要はありません、また、良い行いとは言えません。しょっちゅう鍵を無効化させているようでしたら、他人はあなたを信用しなくなるかもしれません。}}
 
   
  +
$ gpg --export --output pubkey.gpg ''user-id''
=== 鍵を表示 ===
 
  +
$ gpg --import pubkey.gpg
   
  +
秘密鍵の再エクスポートやバックアップの更新は必要ありません。マスター秘密鍵自体に有効期限がなく、公開鍵やサブ鍵に残された有効期限の署名があればよいのです。
* 公開鍵束の鍵:
 
   
  +
=== Rotating subkeys ===
$ gpg --list-keys
 
   
  +
{{Warning|'''Never''' delete your expired or revoked subkeys unless you have a good reason. Doing so will cause you to lose the ability to decrypt files encrypted with the old subkey. Please '''only''' delete expired or revoked keys from other users to clean your keyring.}}
* 秘密鍵束の鍵:
 
   
  +
Alternatively, if you prefer to stop using subkeys entirely once they have expired, you can create new ones. Do this a few weeks in advance to allow others to update their keyring.
$ gpg --list-secret-keys
 
   
  +
{{Tip|You do not need to create a new key simply because it is expired. You can extend the expiration date, see the section [[#Extending expiration date]].}}
== gpg-agent ==
 
   
  +
Create new subkey (repeat for both signing and encrypting key)
''gpg-agent'' はキーチェインにパスワードをリクエストしたりキャッシュしたりするのに使われるデーモンです。メールクライアントなど外部のプログラムから GnuPG を利用する場合に便利です。{{ic|gpg.conf}} に次の行を追加することで使用できます:
 
   
  +
$ gpg --edit-key ''user-id''
{{hc|~/.gnupg/gpg.conf|use-agent}}
 
  +
> addkey
   
  +
And answer the following questions it asks (see [[#Create a key pair]] for suggested settings).
この設定によって GnuPG はパスワードが必要になった時にエージェントを使うようになります。ただし、あらかじめエージェントを実行しておく必要があります。エージェントを自動的に起動するには、{{ic|.xinitrc}} や {{ic|.bash_profile}} に以下のエントリを追加してください。{{ic|$GNUPGHOME}} を変更していた場合は envfile のパスを忘れずに変更するようにしてください。
 
   
  +
Save changes
{{hc|~/.bash_profile|2=<nowiki>
 
  +
envfile="$HOME/.gnupg/gpg-agent.env"
 
  +
> save
if [[ -e "$envfile" ]] && kill -0 $(grep GPG_AGENT_INFO "$envfile" | cut -d: -f 2) 2>/dev/null; then
 
  +
eval "$(cat "$envfile")"
 
  +
Update it to a keyserver.
else
 
  +
eval "$(gpg-agent --daemon --enable-ssh-support --write-env-file "$envfile")"
 
  +
$ gpg --keyserver pgp.mit.edu --send-keys ''user-id''
fi
 
  +
export GPG_AGENT_INFO # the env file does not contain the export statement
 
  +
You will also need to export a fresh copy of your secret keys for backup purposes. See the section [[#Backup your private key]] for details on how to do this.
export SSH_AUTH_SOCK # enable gpg-agent for ssh
 
  +
</nowiki>}}
 
  +
{{Tip|Revoking expired subkeys is unnecessary and arguably bad form. If you are constantly revoking keys, it may cause others to lack confidence in you.}}
  +
  +
=== 鍵の取り消し ===
  +
  +
鍵が侵害された、置き換えられた、使用されなくなった、またはパスフレーズを忘れた場合は、キーの取り消しを実行する必要があります。これは、鍵を鍵の失効証明書とマージすることによって行われます。
  +
  +
鍵ペアにアクセスできなくなった場合は、まず[[#公開鍵のインポート]]して独自の鍵をインポートします。
  +
次に、キーを失効させるために、[[#失効証明書のバックアップ]] で保存したファイルをインポートします。
  +
  +
$ gpg --import ''revcert.asc''
  +
  +
ここで、取り消しを公開する必要があります。 [[#鍵サーバーを使用する]]で過去に PGP サーバーを使用したことがある場合は、取り消された鍵を公開 PGP サーバーに送信します。それ以外の場合は、取り消された鍵をファイルにエクスポートし、通信パートナーに配布します。
  +
  +
== 署名 ==
  +
  +
署名は文章を証明します。文章が改変された場合、署名の検証に失敗します。公開鍵を使用して文章を暗号化する暗号化とは違って、署名はユーザーの秘密鍵を使って作成されます。署名された文章を受け取った人は送り主の公開鍵を使って署名を検証できます。
  +
  +
=== 署名の作成 ===
  +
  +
==== ファイルに署名する ====
  +
  +
ファイルに署名するには {{ic|--sign}} または {{ic|-s}} フラグを使います:
  +
  +
$ gpg --output ''doc.sig'' --sign ''doc''
  +
  +
上記のコマンドは暗号化も行ってファイルをバイナリ形式で保存します。
  +
  +
==== ファイルやメッセージにクリア署名 ====
  +
  +
バイナリ形式に圧縮しないでファイルに署名するには:
  +
  +
$ gpg --clearsign ''doc''
  +
  +
上記のコマンドは文章を ASCII-armored 署名でラッピングしますが、文章に変更は加えられません。
  +
  +
==== 分離署名を作成する ====
  +
  +
文章やファイルとは別に署名ファイルを作成したい場合、{{ic|--detach-sig}} フラグを使ってください:
  +
  +
$ gpg --output ''doc.sig'' --detach-sig ''doc''
  +
  +
上記の方法はソフトウェアプロジェクトを配布するときによく用いられます。署名書を検証することで第三者によってファイルが改竄されていないことが確認できます。
  +
  +
==== 署名の検証 ====
  +
  +
署名を検証するには {{ic|--verify}} フラグを使います:
  +
  +
$ gpg --verify ''doc.sig''
  +
  +
{{ic|''doc.sig''}} は検証したい署名に置き換えてください。
  +
  +
ファイルの検証と復号化を同時に行いたいお場合、{{ic|--decrypt}} フラグを使ってください。
  +
  +
分離署名を検証する場合、ファイルと署名の両方が必要になります。例えば、Arch Linux の ISO を検証する場合:
  +
  +
$ gpg --verify ''archlinux-''version''.iso.sig''
  +
  +
{{ic|archlinux-''version''.iso}} が同じディレクトリに存在していなければなりません。
  +
  +
=== 署名の確認 ===
  +
  +
署名を確認するには、{{ic|--verify}} フラグを使用します。
  +
  +
$ gpg --verify ''doc''.sig
  +
  +
ここで {{ic|''doc''.sig}} は、検証したい署名を含む署名付きファイルです。
  +
  +
分離された署名を検証する場合、署名されたデータファイルと署名ファイルの両方が検証時に存在する必要があります。例えば、Arch Linux の最新の iso を検証する場合、次のようになります。
  +
  +
$ gpg --verify archlinux-''version''.iso.sig
  +
  +
ここで {{ic|archlinux-''version''.iso}} は同じディレクトリにある必要があります。
  +
  +
また、第2引数で署名付きデータファイルを指定することも可能です。
  +
  +
$ gpg --verify archlinux-''version''.iso.sig ''/path/to/''archlinux-''version''.iso
  +
  +
署名に加えて暗号化されている場合は、[[#暗号化と復号化|復号化]]を行うだけで署名も検証されます。
  +
  +
== gpg-agent ==
  +
  +
''gpg-agent'' はキーチェインにパスワードをリクエストしたりキャッシュしたりするのに使われるデーモンです。メールクライアントなど外部のプログラムから GnuPG を利用する場合に便利です。{{Pkg|gnupg}} には [[systemd/ユーザー|systemd ユーザー]]ソケットが付属しており、デフォルトで有効になります: {{ic|gpg-agent.socket}}, {{ic|gpg-agent-extra.socket}}, {{ic|gpg-agent-browser.socket}}, {{ic|gpg-agent-ssh.socket}}, {{ic|dirmngr.socket}}。
   
  +
* ''gpg'' はメインの {{ic|gpg-agent.socket}} を使って ''gpg-agent'' デーモンに接続します。
その後、セッションを一度ログアウトしてからログインしなおして下さい。''gpg-agent'' が有効になっているか確認:
 
  +
* {{ic|gpg-agent-extra.socket}} はリモート環境から Unix ドメインソケットの転送を設定します。秘密鍵をリモート環境に移さなくてもリモート環境で ''gpg'' が使えるようになります。詳しくは {{man|1|gpg-agent}} を参照。
  +
* The {{ic|gpg-agent-browser.socket}} allows web browsers to access the ''gpg-agent'' daemon.
  +
* [[SSH]] は {{ic|gpg-agent-ssh.socket}} を使って ''ssh-add'' プログラムによって追加された [[SSH 鍵]]をキャッシュします。必要な設定は [[#SSH エージェント]]を見てください。
  +
* {{ic|dirmngr.socket}} は鍵サーバーへの接続を処理する GnuPG デーモンを起動します。
   
  +
{{Note|GnuPG の設定ファイルのディレクトリがデフォルトと異なる場合、{{ic|gpgconf --list-dirs}} の値を使用するようにソケットファイルを編集してください。}}
$ pgrep gpg-agent
 
   
 
=== 設定 ===
 
=== 設定 ===
   
gpg-agent は {{ic|~/.gnupg/gpg-agent.conf}} ファイルで設定することができます。設定オプションは {{ic|man gpg-agent}} に記載されています。例えば、未使用の鍵の cache ttl を変更することができます:
+
gpg-agent は {{ic|~/.gnupg/gpg-agent.conf}} ファイルで設定することができます。設定オプションは {{man|1|gpg-agent}} に記載されています。例えば、未使用の鍵の cache ttl を変更することができます:
   
 
{{hc|~/.gnupg/gpg-agent.conf|
 
{{hc|~/.gnupg/gpg-agent.conf|
253行目: 476行目:
 
=== エージェントのリロード ===
 
=== エージェントのリロード ===
   
設定を変更した後は、{{ic|gpg-connect-agent}} に {{ic|RELOADAGENT}} という文字列をパイプ渡して、エージェントをリロードしてください
+
設定を変更した後は、{{ic|gpg-connect-agent}} でエージェントをリロードしてください:
   
$ echo RELOADAGENT | gpg-connect-agent
+
$ gpg-connect-agent reloadagent /bye
   
 
シェルに {{ic|OK}} と出力されます。
 
シェルに {{ic|OK}} と出力されます。
  +
  +
しかし、エージェント設定に {{ic|keep-screen}} が追加されている場合など、再起動だけでは十分でないこともあります。
  +
この場合、まず進行中の gpg-agent プロセスを kill してから、上記で説明したように再起動する必要があります。
   
 
=== pinentry ===
 
=== pinentry ===
   
  +
{{ic|gpg-agent}} は {{ic|pinentry-program}} stanza を使用して、パスフレーズの入力を促す際に、特定の {{Pkg|pinentry}} ユーザーインターフェイスを使用するように設定できます。例えば、以下の通りです。
最後に、ユーザーにパスワードを尋ねる方法をエージェントに設定する必要があります。gpg-agent の設定ファイルで設定できます。
 
   
デフォルトでは gtk のダイアログが使われます。使用できるオプションは {{ic|info pinentry}} を見て下さい。ダイアログの実装を変更するには {{ic|pinentry-program}} 設定オプションを設定します:
 
 
{{hc|~/.gnupg/gpg-agent.conf|
 
{{hc|~/.gnupg/gpg-agent.conf|
  +
pinentry-program /usr/bin/pinentry-curses
 
# PIN entry program
 
# pinentry-program /usr/bin/pinentry-curses
 
# pinentry-program /usr/bin/pinentry-qt4
 
# pinentry-program /usr/bin/pinentry-kwallet
 
 
pinentry-program /usr/bin/pinentry-gtk-2
 
 
}}
 
}}
   
  +
他のも様々な pinentry プログラムがあります。{{ic|pacman -Ql pinentry {{!}} grep /usr/bin/}} を参照してください。
{{Tip|{{ic|/usr/bin/pinentry-kwallet}} を使うには {{Pkg|kwalletcli}} パッケージをインストールする必要があります。}}
 
   
  +
{{Tip|{{ic|/usr/bin/pinentry-kwallet}} を使うには {{AUR|kwalletcli}} パッケージをインストールする必要があります。}}
変更を行った後は、gpg-agent をリロードしてください。
 
   
  +
変更を行った後は、[[#エージェントのリロード|エージェントのリロード]]を忘れないでください。
=== systemd ユーザーで gpg-agent を起動 ===
 
   
  +
=== パスワードのキャッシュ ===
[[Systemd/ユーザー]]機能を使ってエージェントを起動することが可能です。
 
   
  +
GnuPG のパスワードをセッションの間だけ記憶させたい場合、{{ic|max-cache-ttl}} と {{ic|default-cache-ttl}} を高い値に設定してください:
systemd ユニットファイルを作成:
 
 
{{hc|~/.config/systemd/user/gpg-agent.service|2=
 
[Unit]
 
Description=GnuPG private key agent
 
IgnoreOnIsolate=true
 
 
[Service]
 
Type=forking
 
ExecStart=/usr/bin/gpg-agent --daemon --homedir=%h/.gnupg
 
ExecStop=/usr/bin/pkill gpg-agent
 
Restart=on-abort
 
 
[Install]
 
WantedBy=default.target
 
}}
 
   
{{Note|
+
{{hc|
  +
gpg-agent.conf|
* {{ic|GNUPGHOME}} など、サービスに環境変数を設定する必要があります。詳しくは [[systemd/ユーザー#環境変数]] を見て下さい。
 
  +
max-cache-ttl 60480000
* gnupg ホームディレクトリが {{ic|~/.gnupg}} の場合、パスを指定する必要はありません。
 
  +
default-cache-ttl 60480000
* {{ic|gpg -agent}} は標準ソケットを使いません。代わりに gnupg のホームディレクトリにある {{ic|S.gpg-agent}} という名前のソケットを使います。environment ファイルを読み込んで {{ic|/tmp}} に作成されたランダムなソケットのパスを取得するスクリプトは忘れることができます。
 
* If you use SSH capabilities of gpg-agent (--enable-ssh-support), the systemd unit above will not work.
 
 
}}
 
}}
   
  +
詳しくは [[#gpg-agent]] を参照。
{{Tip|gpg-agent が実行していること、接続を待機していることを確認するには、次のコマンドを実行してください: {{ic|$ gpg-connect-agent}}。設定が問題なければ、プロンプトが表示されます (''bye'' や ''quit'' と入力すれば接続が終了します)。}}
 
   
 
=== 無人のパスフレーズ ===
 
=== 無人のパスフレーズ ===
330行目: 533行目:
 
}}
 
}}
   
{{Note|上流の開発者は ''gpg.conf'' で ''pinentry-mode loopback'' を設定すると他の機能が使えなくなる可能性があると示唆しています。出来るかぎりコマンドラインオプションを使うようにして下さい [https://bugs.g10code.com/gnupg/issue1772]。}}
+
{{Note|上流の開発者は ''gpg.conf'' で ''pinentry-mode loopback'' を設定すると他の機能が使えなくなる可能性があると示唆しています。できるかぎりコマンドラインオプションを使うようにして下さい [https://bugs.g10code.com/gnupg/issue1772]。}}
   
== スマートカード ==
+
=== SSH エジェン===
   
  +
''gpg-agent'' には OpenSSH エージェントのエミュレーション機能が存在します。既に GnuPG スイートを使っているのであれば、SSH 鍵をキャッシュするのに使うことが可能です。さらに、パスフレーズを管理するのに GnuPG エージェントの PIN エントリダイアログを使えます。
{{Note|{{Pkg|pcsclite}} と {{Pkg|libusb-compat}} をインストールして、{{ic|pcscd.service}} サービスを [[systemd#ユニットを使う|systemd]] で実行する必要があります。}}
 
   
  +
==== SSH_AUTH_SOCK の設定 ====
GnuPG はスマートカードリーダーのインターフェイスとして ''scdaemon'' を使います。詳しくは [[man ページ]]を参照してください。
 
  +
  +
SSH が ''ssh-agent'' の代わりに ''gpg-agent'' を使うように {{ic|SSH_AUTH_SOCK}} を設定してください。シェルのタイプに関係なくプロセスが ''gpg-agent'' インスタンスを使うようにするには [[環境変数#pam_env を使う|pam_env]] を使用します:
  +
  +
{{hc|~/.pam_environment|2=
  +
SSH_AGENT_PID DEFAULT=
  +
SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"
  +
}}
  +
  +
{{note|
  +
* {{ic|SSH_AUTH_SOCK}} を手動で設定する場合、{{ic|GNUPGHOME}} をカスタマイズしているときはソケットの場所が異なる可能性があるので注意してください。以下の bash の例を使用するか、{{ic|SSH_AUTH_SOCK}} を {{ic|gpgconf --list-dirs agent-ssh-socket}} の値に変更してください。
  +
* GNOME Keyring がインストールされている場合、 その ssh コンポーネントを[[GNOME/Keyring#無効化する|無効化]]する必要があります。そうしないと、{{ic|SSH_AUTH_SOCK}} を上書きしてしまいます。}}
  +
  +
または、Bash を使う場合:
  +
  +
{{hc|~/.bashrc|<nowiki>
  +
unset SSH_AGENT_PID
  +
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
  +
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
  +
fi
  +
</nowiki>}}
  +
  +
{{Note|1=<nowiki></nowiki>エージェントを {{ic|gpg-agent --daemon /bin/sh}} で起動している場合、シェルは {{ic|SSH_AUTH_SOCK}} 変数を ''gpg-agent'' から承継します [http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/gpg-agent.c;hb=7bca3be65e510eda40572327b87922834ebe07eb#l1307]。}}
  +
  +
==== 適切な TTY を使うように pinentry を設定 ====
  +
  +
{{man|1|gpg-agent}} にあるように、ユーザーを X セッションに切り替えた場合は GPG_TTY も設定して TTY を更新してください。例:
  +
  +
{{hc|~/.bashrc|<nowiki>
  +
# Set GPG TTY
  +
export GPG_TTY=$(tty)
  +
  +
# Refresh gpg-agent tty in case user switches into an X session
  +
gpg-connect-agent updatestartuptty /bye >/dev/null
  +
</nowiki>}}
  +
  +
複数の端末を同時に使用し、''ssh'' コマンドを実行した同じ端末から ''pinentry-curses'' で ''gpg-agent'' がパスフレーズを要求するようにしたい場合、SSH 設定ファイルに以下を追加してください。これにより、''ssh'' コマンドを実行するたびに TTY がリフレッシュされるようになります [https://unix.stackexchange.com/a/499133]。
  +
  +
{{hc|~/.ssh/config|2=
  +
Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"
  +
}}
  +
  +
なお、環境変数 GPG_TTY が設定されていないと動作しません。
  +
  +
==== SSH 鍵の追加 ====
  +
  +
''gpg-agent'' が起動していれば [[SSH 鍵#ssh-agent|ssh-agent]] と同じように ''ssh-add'' で鍵を追加できます。追加された鍵は {{ic|~/.gnupg/sshcontrol}} ファイルに保存されます。パスフレーズが必要になったときは毎回 ''pinentry'' ダイアログが表示されます。パスフレーズのキャッシュは {{ic|~/.gnupg/gpg-agent.conf}} ファイルで制御します。以下の例では ''gpg-agent'' で鍵を3時間キャッシュします:
  +
  +
{{hc|~/.gnupg/gpg-agent.conf|
  +
default-cache-ttl-ssh 10800
  +
max-cache-ttl-ssh 10800}}
  +
  +
==== SSH 認証に PGP 鍵を使用する ====
  +
  +
PGP 鍵を SSH 鍵として使うこともできます。鍵のメンテナンスを楽にして SSH 鍵をキーカードに保存できます。認証機能を有効にして鍵を作成する必要があります ([[#カスタム機能]]を参照)。SSH 認証に PGP 鍵を使用することで得られる様々な利点があります。
  +
  +
* SSH キーを維持する必要がなくなるため、キーのメンテナンスが削減されます。
  +
* 認証キーをスマートカードに保存する能力。GnuPG はカードが利用可能なときにキーを自動的に検出し、エージェントに追加します({{ic|ssh-add -l}} または {{ic|ssh-add -L}} で確認)。キーのコメントは次のようなものであるべきです:{{ic|openpgp:''key-id''}} または {{ic|cardno:''card-id''}}。
  +
  +
GPG/SSH キーの公開キー部分を取得するには、{{ic|gpg --export-ssh-key ''gpg-key''}} を実行します。キーが認証可能であっても、このコマンドが "Unusable public key" で失敗する場合は、{{ic|!}} サフィックスを追加します ([https://dev.gnupg.org/T2957])。
  +
  +
GPG キーをキーカードに持っていない場合、SSH キーとして認識されるように {{ic|$GNUPGHOME/sshcontrol}} にキーを追加する必要があります。キーがキーカードにある場合、その keygrip は {{ic|sshcontrol}} に暗黙的に追加されます。そうでない場合、次の方法でキーの keygrip を取得します:
  +
  +
{{hc|$ gpg --list-keys --with-keygrip|2=
  +
sub rsa4096 2018-07-25 [A]
  +
Keygrip = ''1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7''
  +
}}
  +
  +
その後、{{ic|sshcontrol}} をこのように編集します。keygrip を追加するのは一度だけの操作です。追加のキーを追加する場合を除いて、ファイルを再度編集する必要はありません。
  +
  +
{{hc|$GNUPGHOME/sshcontrol|
  +
''1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7''
  +
}}
  +
  +
== スマートカード ==
  +
  +
GnuPG は、スマートカードリーダとのインターフェイスとして ''scdaemon'' を使用します。詳細は {{man|1|scdaemon}} [[man ページ]]を参照してください。
   
 
=== GnuPG のみ設定 ===
 
=== GnuPG のみ設定 ===
  +
  +
{{Note|scdaemon が USB スマートカードリーダに直接アクセスできるようにするには、任意の依存パッケージである {{Pkg|libusb-compat}} をインストールする必要があります。}}
   
 
GnuPG ベース以外のカードを使う予定がない場合は、{{ic|~/.gnupg/scdaemon.conf}} の {{Ic|reader-port}} パラメータを確認してください。'0' が最初に利用できるシリアルポートリーダーを、'32768' (デフォルト) が最初の USB リーダーを示しています。
 
GnuPG ベース以外のカードを使う予定がない場合は、{{ic|~/.gnupg/scdaemon.conf}} の {{Ic|reader-port}} パラメータを確認してください。'0' が最初に利用できるシリアルポートリーダーを、'32768' (デフォルト) が最初の USB リーダーを示しています。
   
=== GnuPG と OpenSC ===
+
=== GnuPG と pcscd (PCSC Lite) ===
   
  +
{{man|8|pcscd}} は、スマートカードへのアクセスを管理するデーモンです (SCard API)。(GnuPG の内臓の CCID サポートを使うなどして) GnuPG の scdaemon でスマートカードと直接接続できない場合、このデーモンは PCSC Lite ドライバを使用するスマートカードを見つけようとします。
opensc ドライバーであらゆるスマートカードを使う場合は (例: いろいろな国の ID カード)、GnuPG の設定に注意する必要があります。何も設定をしていないと {{Ic|gpg --card-status}} を使った時に以下のようなメッセージが表示されることがあります:
 
  +
  +
pscsd を使うには、{{Pkg|pcsclite}} と {{Pkg|ccid}} を[[インストール]]してください。そして、{{ic|pcscd.service}} を[[開始]]し、(このサービスを永続的に使用する場合は) [[有効化]]してください。あるいは、{{ic|pcscd.socket}} を開始/有効化することで、必要なときにだけデーモンをアクティブ化させることもできます。
  +
  +
==== 常に pcscd を使う ====
  +
  +
opensc ドライバを使用するスマートカード (一部の国々の ID カードがこれに該当します) を使う場合は、GnuPG の設定に注意する必要があります。特に設定しないと、{{Ic|gpg --card-status}} を実行した時に以下のようなメッセージが表示されるかもしれません:
   
 
gpg: selecting openpgp failed: ec=6.108
 
gpg: selecting openpgp failed: ec=6.108
   
デフォルトでは、scdaemon はデバイスに直接接続しようとします。リーダが他のプロセスによって使用中だとこの接続は失敗します。例えば: OpenSC によって使用される pcscd デーモン。この状況に対処するには、opensc と同じ基盤のドライバを使って一緒に動作できるようにする必要があります。scdaemon pcscd を使用させため、{{ic|~/.gnupg/scdaemon.conf}} から {{Ic|reader-port}} を削除し、{{ic|libpcsclite.so}} ライブラリの場所を指定し、ccid を無効化してください:
+
デフォルトでは、scdaemon はデバイスに直接接続しようとします。カードリーダが他のプロセスによって使用されている場合、この接続は失敗します。例えば、pcscd デーモンが OpenSC によって使用されてい場合などです。この問題を解決するには、scdaemon と opensc が互いにうまく機能するようにするために、opensc のものと同じドライバを使する必要があります。scdaemon pcscd を使用ようにするには、{{ic|~/.gnupg/scdaemon.conf}} から {{Ic|reader-port}} を削除し、{{ic|libpcsclite.so}} ライブラリパスを指定し、pcscd を確実に使用させるために ccid を無効化する必要があります:
   
 
{{hc|~/.gnupg/scdaemon.conf|<nowiki>
 
{{hc|~/.gnupg/scdaemon.conf|<nowiki>
356行目: 643行目:
 
</nowiki>}}
 
</nowiki>}}
   
OpenSC を使ない場合は {{Ic|man scdaemon}} をチェックしてください。
+
OpenSC を使用しない場合は{{man|1|scdaemon}} を確認してください。
   
  +
==== pcscd との共有アクセス ====
== Tips and tricks ==
 
   
  +
GnuPG {{ic|scdaemon}} は、{{ic|pcscd}} への接続時に {{ic|PCSC_SHARE_EXCLUSIVE}} フラグを使用する唯一の一般的な {{ic|pcscd}} クライアントです。[[Electronic identification|電子識別]] にリストされているブラウザやプログラムで使用される OpenSC PKCS#11 などの他のクライアントは、単一のスマートカードへの同時アクセスを許可する {{ic|PCSC_SHARE_SHARED}} を使用しています。{{ic|pcscd}} は、他のクライアントが接続されている間はスマートカードへの排他的アクセスを与えません。これは、GnuPG スマートカード機能を使用するには、開いているブラウザウィンドウをすべて閉じるか、その他の不便な操作を行う必要があることを意味します。バージョン 2.2.28 LTS および 2.3.0 以降では、{{ic|scdaemon.conf}} ファイルを変更し、その行末に {{ic|pcsc-shared}} を追加することで共有アクセスを有効にできます。
=== Different algorithm ===
 
   
  +
===== マルチアプレットスマートカード =====
You may want to use stronger algorithms:
 
   
  +
OpenSC PKCS#11 で [[YubiKey]] または他のマルチアプレット USB ドングルを使用すると、OpenSC が Yubikey を OpenPGP から PIV アプレットに切り替えて、{{ic|scdaemon}} が壊れるという問題が発生する可能性があります。
{{hc|~/.gnupg/gpg.conf|
 
  +
  +
OpenSC に OpenPGP アプレットも使用させることで、この問題を回避できます。{{ic|/etc/opensc.conf}} ファイルを開き、Yubikey を検索して、{{ic|1=driver = "PIV-II";}} 行を {{ic|1=driver = "openpgp";}} に変更します。そのようなエントリがない場合は、{{ic|pcsc_scan}} を使用します。リセットするための答えを検索して {{ic|ATR: 12 34 56 78 90 AB CD ...}} 次に、新しいエントリを作成します。
  +
  +
{{hc|/etc/opensc.conf|2=
 
...
 
...
  +
card_atr 12:23:34:45:67:89:ab:cd:... {
  +
name = "YubiKey Neo";
  +
driver = "openpgp"
  +
}
  +
...
  +
}}
   
  +
その後、{{ic|pkcs11-tool -O --login}} を使用して、OpenPGP アプレットがデフォルトで選択されていることをテストします。この変更を適用するには、ブラウザなどの他の PKCS#11 クライアントを再起動する必要があります。
personal-digest-preferences SHA512
 
  +
cert-digest-algo SHA512
 
  +
===== SSH 経由でリモートクライアント上のスマートカードを使用する =====
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
 
  +
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES
 
  +
SSH 経由でマシンにログインし、pcscd 経由で接続されたデバイスを使用しようとすると、次のようなエラーが発生します:
  +
  +
gpg: selecting card failed: No such device
  +
gpg: OpenPGP card not available: No such device
  +
  +
これは、[[Polkit]] がローカル クライアントへのアクセスを制限しているためです。これを修正するには、特定のユーザーを許可するルールを追加します。以下のルールにより、{{ic|wheel}} グループ内のすべてのユーザーが {{ic|pcscd}} 経由でデバイスにアクセスできます:
  +
  +
{{hc|/etc/polkit-1/rules.d/99-pcscd.rules|2=
  +
polkit.addRule(function(action, subject) {
  +
if (action.id == "org.debian.pcsc-lite.access_card" &&
  +
subject.isInGroup("wheel")) {
  +
return polkit.Result.YES;
  +
}
  +
});
  +
polkit.addRule(function(action, subject) {
  +
if (action.id == "org.debian.pcsc-lite.access_pcsc" &&
  +
subject.isInGroup("wheel")) {
  +
return polkit.Result.YES;
  +
}
  +
});
 
}}
 
}}
   
  +
ファイルを作成したら、必ず {{ic|polkit.service}} を [[再起動]] してください。
In the latest version of GnuPG, the default algorithms used are SHA256 and AES, both of which are secure enough for most people. However, if you are using a version of GnuPG older than 2.1, or if you want an even higher level of security, then you should follow the above step.
 
   
  +
== OpenPGP の互換性 ==
=== Encrypt a password ===
 
   
  +
GnuPG は [[OpenPGP]] 形式の実装として始まりました。現在、プロジェクトは [https://www.rfc-editor.org/rfc/rfc4880.html RFC 4880] に基づいており、[https://www.rfc-editor.org/rfc/rfc9580.html RFC 9580] (RFC 4880 に代わる) はサポートしていません。
It can be useful to encrypt some password, so it will not be written in clear on a configuration file. A good example is your email password.
 
   
  +
ただし、バージョン 2.4.0 (2022 年 12 月以降) 以降、GnuPG は IETF プロセスの外でフォーマットへの変更と拡張をロールアウトすることを選択しました ([https://datatracker.ietf.org/doc/draft-koch-librepgp/ draft-koch-librepgp] を参照)
First create a file with your password. You '''need''' to leave '''one''' empty line after the password, otherwise gpg will return an error message when evaluating the file.
 
   
  +
GnuPG 独自の形式 ([[OpenPGP#Standardization|OpenPGP 標準]] から分岐したもの) のほとんどは "バージョン 5" を採用しており (このバージョンは IETF OpenPGP 標準では使用されていません)、非互換性が生じます。
Then run:
 
   
  +
* GnuPG の "バージョン 5" キーは、異なるフィンガープリントを使用します (SHA-256 を使用しているため、より長くなります)
$ gpg -e -a -r ''<user-id>'' ''your_password_file''
 
  +
* 新しい対称的に暗号化されたデータパケット形式 ([https://www.ietf.org/archive/id/draft-koch-librepgp-01.html#name-ocb-encrypted-data-packet-t OCB Encrypted Data Packet]))が追加されました。この形式のサポートは、デフォルトで積極的に有効になっている "機能フラグ" によって通知されます。 [[#サポートされていない AEAD メカニズムを無効にする]] を参照してください。
  +
* 新しい [https://www.ietf.org/archive/id/draft-koch-librepgp-01.html#name-post-quantum-cryptography Post-Quantum Cryptography] 形式 これも IETF プロセスから分岐したものです ([https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/draft-ietf-openpgp-pqc])
   
  +
外部レビューでは、GnuPG による形式拡張の健全性について懸念が生じています ([https://blog.pgpkeys.eu/security-issues-librepgp-2024-08.html "A Summary of Known Security Issues in LibrePGP"] を参照)
{{ic|-e}} is for encrypt, {{ic|-a}} for armor (ASCII output), {{ic|-r}} for recipient user ID.
 
   
  +
GnuPG 固有のフォーマット変更に関する懸念事項のより詳細な議論については、[https://blog.pgpkeys.eu/critique-critique.html "A Critique on “A Critique on the OpenPGP Updates”] を参照してください。
You will be left with a new {{ic|''your_password_file''.asc}} file.
 
   
  +
Arch Linux の立場は、[[OpenPGP]] 標準との互換性を優先しています。
=== Default options for new users ===
 
  +
この目的のために、[https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg/-/blob/1cbbdd291f40d3441b39f5d27c6a3bd4b32ff3c4/gnupg-2.4-revert_default_rfc4880bis.patch デフォルトで RFC4880bis を戻す] などの {{pkg|gnupg}} パッケージにパッチが適用されます。
  +
これにより、他の [[OpenPGP]] 実装との長期的な互換性が保証され、デフォルトでベンダーロックインが回避されます。
   
  +
== ヒントとテクニック ==
If you want to setup some default options for new users, put configuration files in {{ic|/etc/skel/.gnupg/}}. When the new user is added in system, files from here will be copied to its GnuPG home directory. There is also a simple script called ''addgnupghome'' which you can use to create new GnuPG home directories for existing users:
 
   
  +
=== サポートされていない AEAD メカニズムを無効にする ===
# addgnupghome user1 user2
 
   
  +
{{pkg|gnupg}} 2.4 では、[[gpg]] は GnuPG 固有の [[Wikipedia:Authenticated_encryption#Authenticated_encryption_with_associated_data_(AEAD)|AEAD]] 暗号化メカニズム (OCB に基づく) のサポートを通知するキーを生成します。ただし、AEAD のこのフレーバーは、他の [[OpenPGP]] 実装ではサポートされていません。
This will add the respective {{ic|/home/user1/.gnupg}} and {{ic|/home/user2/.gnupg}} and copy the files from the skeleton directory to it. Users with existing GnuPG home directory are simply skipped.
 
   
  +
多くのダウンストリームは [https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg/-/blob/cfc8f931ee3167a3673b249018dbba527d7428f8/gnupg-2.4-revert_default_rfc4880bis.patch GnuPG ソースにパッチを適用] してこの新しいデフォルトを削除しようとしますが、{{ic|--full-gen-key}} OCB ベースのカスタム AEAD 暗号化メカニズムが新しいキーに設定されています。
=== Revoking a key ===
 
   
  +
GnuPG のカスタム AEAD がキーに設定されているかどうかは、{{ic|gpg}} 自体を使用して検査できます:
{{Warning|
 
*Anybody having access to your revocation certificate can revoke your key, rendering it useless.
 
*Key revocation should only be performed if your key is compromised or lost, or you forget your passphrase.}}
 
   
  +
$ gpg --expert --edit-key ''<FINGERPRINT>''
Revocation certificates are automatically generated for newly generated keys, although one can be generated manually by the user later. These are located at {{ic|~/.gnupg/openpgp-revocs.d/}}. The filename of the certificate is the fingerprint of the key it will revoke.
 
  +
gpg> showpref
  +
[ultimate] (1). Foobar McFooface (test) <foobar@mcfooface.com>
  +
Cipher: AES256, AES192, AES, 3DES
  +
AEAD: '''OCB'''
  +
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
  +
Compression: ZLIB, BZIP2, ZIP, Uncompressed
  +
Features: MDC, '''AEAD''', Keyserver no-modify
   
  +
このメカニズムは次のように無効にできます:
To revoke your key, simply import the revocation certificate:
 
   
  +
gpg> setpref AES256 AES192 AES SHA512 SHA384 SHA256 SHA224 ZLIB BZIP2 ZIP
$ gpg --import ''<fingerprint>''.rev
 
  +
Set preference list to:
  +
Cipher: AES256, AES192, AES, 3DES
  +
AEAD:
  +
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
  +
Compression: ZLIB, BZIP2, ZIP, Uncompressed
  +
Features: MDC, Keyserver no-modify
  +
Really update the preferences? (y/N) y
   
  +
=== 他のアルゴリズム ===
Now update the keyserver:
 
   
  +
強力なアルゴリズムを使用したい場合:
$ gpg --keyserver subkeys.pgp.net --send ''<userid>''
 
   
  +
{{hc|~/.gnupg/gpg.conf|
=== Change trust model ===
 
  +
...
   
  +
personal-digest-preferences SHA512
By default GnuPG uses the [[Wikipedia::Web of Trust|Web of Trust]] as the trust model. You can change this to [[Wikipedia::Trust on First|Trust on First]] Use by adding {{ic|1=--trust-model=tofu}} when adding a key or adding this option to your GnuPG configuration file. More details are in [https://lists.gnupg.org/pipermail/gnupg-devel/2015-October/030341.html this email to the GnuPG list].
 
  +
cert-digest-algo SHA512
  +
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
  +
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES
  +
}}
   
  +
GnuPG の最新版では、デフォルトのアルゴリズムとして SHA256 と AES が使われており、どちらも殆どの場合安全です。しかしながら、2.1 以前の古い GnuPG を使っている場合や、さらに高いセキュリティを求めたい場合、上記のように設定するようにしてください。
=== Hide all recipient id's ===
 
   
  +
=== パスワードの暗号化 ===
By default the recipient's key ID is in the encrypted message. This can be removed at encryption time for a recipient by using {{ic|hidden-recipient ''<user-id>''}}. To remove it for all recipients add {{ic|throw-keyids}} to your configuration file. 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 (''e.g.'' with {{ic|--try-secret-key ''<user-id>''}}).
 
   
  +
{{Tip|[[pass]] は以下の作業を自動化します。}}
=== Using caff for keysigning parties ===
 
   
  +
パスワードを暗号化すれば、設定ファイルに平文で書き込まれなくなります。メールのパスワードなどが良い例でしょう。
To allow users to validate keys on the keyservers and in their keyrings (i.e. make sure they are from whom they claim to be), PGP/GPG uses he [[Wikipedia::Web of Trust|Web of Trust]]. Keysigning parties allow users to get together in physical location to validate keys. The [[Wikipedia:Zimmermann–Sassaman key-signing protocol|Zimmermann-Sassaman]] key-signing protocol is a way of making these very effective. [http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html Here] you will find a how-to article.
 
   
  +
まずパスワードを記述したファイルを作成してください。パスワードの後に空行を'''一行'''だけ追加しておく必要があります。そうしないとファイルを評価するときに gpg がエラーメッセージを返します。
キーサインパーティの後、鍵に署名したり所有者に署名を送るのを簡略化するために、''caff'' というツールを使うことができます。AUR のパッケージ {{AUR|caff-svn}} でインストールすることができ、{{AUR|signing-party-svn}} パッケージなど他の便利なツールにも付属しています。どちらにせよ、AUR から大量の依存パッケージをインストールすることになります。また、以下のように CPAN からインストールすることも可能です:
 
cpanm Any::Moose
 
cpanm GnuPG::Interface
 
   
  +
そして次を実行:
To send the signatures to their owners you need a working [[Wikipedia:Message transfer agent|MTA]]. If you do not have already one, install [[msmtp]].
 
   
  +
$ gpg -e -a -r ''<user-id>'' ''your_password_file''
== トラブルシューティング ==
 
   
  +
{{ic|-e}} は encrypt、{{ic|-a}} は armor (ASCII 出力)、{{ic|-r}} は受取人のユーザー ID です。
=== Make it work behind an http proxy ===
 
Since 2.1.9 the http proxy option can be set like this:
 
   
  +
新しく {{ic|''your_password_file''.asc}} ファイルが作られます。
$ gpg --keyserver-option http-proxy=HOST:PORT
 
   
  +
=== 信頼モデルの変更 ===
See https://bugs.gnupg.org/gnupg/issue1786 for more explanation.
 
   
  +
デフォルトでは GnuPG は信頼モデルとして [[Wikipedia:Web of Trust|Web of Trust]] を使います。Web of Trust から [[Wikipedia:Trust on First|Trust on First]] に変更することが可能です。鍵を追加するときに {{ic|1=--trust-model=tofu}} を追加するか GnuPG の設定ファイルにオプションを追加してください。詳細は [https://lists.gnupg.org/pipermail/gnupg-devel/2015-October/030341.html GnuPG メーリングリストのメール] を参照。
=== Not enough random bytes available ===
 
鍵を生成するときに、gpg は以下のエラーを表示することがあります:
 
Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!
 
残っているエントロピーを確認するには、カーネルパラメータをチェックしてください:
 
cat /proc/sys/kernel/random/entropy_avail
 
   
  +
=== 受取人の id を全て隠す ===
エントロピーがたくさんある健康的な Linux 環境ならマックスの 4,096 ビットに近い値が返されます。返ってくる値が 200 以下の場合、システムのエントロピーが足りていません。
 
   
  +
デフォルトでは暗号メッセージには受取人の鍵 ID が含まれます。{{ic|hidden-recipient ''<user-id>''}} を使うことで暗号化するときに ID は削除することが可能です。全ての受取人で ID を削除するには設定ファイルに {{ic|throw-keyids}} を追加してください。この設定によってメッセージの受取人を隠すことができ、トラフィックの解析に対抗することができます (ソーシャルエンジニアリングを使うことでメッセージを復号化できてしまえば誰が受取人なのか確認される可能性があります)。欠点としては、暗号鍵を全て試すことになるので復号化が遅くなります ({{ic|--try-secret-key ''<user-id>''}})。
エントロピー問題を解決するには、メッセージ通りのことをするのがベストです (例: ディスクを動かす、マウスを動かす、wiki を編集する - 何でもエントロピーの生成に繋がります)。それでも問題が解決しない場合、エントロピーを使い果たしているサービスが何なのかチェックして、しばらくそのサービスを停止してみてください。サービスを停止できない場合、[[乱数生成#高速な RNG]] を見て下さい。
 
  +
  +
=== キーサインパーティで caff を使う ===
  +
  +
鍵サーバーやキーリングにある鍵の正当性をユーザーが確認 (つまり鍵の持ち主が本人であることを確認) できるように、PGP/GPG はいわゆる信頼の輪 ("Web of Trust") を利用しています。信頼の輪を維持するために様々なハッカーイベントが開かれており、キーサインパーティはそのひとつです。[[Wikipedia:Zimmermann–Sassaman key-signing protocol|Zimmermann-Sassaman]] 鍵署名プロトコルはキーサインパーティを効果的に行うための方式です。[http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html こちら] にハウツー記事があります。
  +
  +
キーサインパーティの後、鍵に署名したり所有者に署名を送るのを簡略化するために、''caff'' というツールを使うことができます。AUR のパッケージ {{AUR|caff-svn}} でインストールすることができます。
  +
  +
所有者に署名を送信するには [[Wikipedia:ja:メール転送エージェント|MTA]] が必要です。MTA を設定していない場合、[[msmtp]] をインストールして下さい。
  +
  +
=== 長い ID やフィンガープリントを毎回表示する ===
  +
  +
長い鍵 ID を表示させるには設定ファイルに {{ic|keyid-format 0xlong}} を追加してください。鍵の指紋を完全に表示するには、設定ファイルに {{ic|with-fingerprint}} を追加してください。
  +
  +
=== カスタム機能 ===
  +
  +
鍵にカスタム機能を設定することができます。以下の機能を使うことが可能です:
  +
  +
* Certify (マスター鍵のみ) - 副鍵の作成ができるようになります。
  +
* Sign - 公開鍵で検証することができる暗号化署名が作成可能になります。
  +
* Encrypt - 公開鍵でデータを暗号化して、秘密鍵で復号化することができます。
  +
* Authenticate - GnuPG 以外のプログラムで鍵を使って認証できます。SSH 鍵として使用することができるようになります。
  +
  +
マスター鍵の機能は以下のコマンドで指定できます:
  +
  +
$ gpg --full-generate-key --expert
  +
  +
オプションを選択して機能を設定することができます。
  +
  +
副鍵にカスタム機能を指定したい場合、{{ic|gpg --edit-key}} に {{ic|--expert}} フラグを追加してください。詳しくは[[#鍵の編集]]を参照。
  +
  +
== トラブルシューティング ==
   
 
=== su ===
 
=== su ===
458行目: 820行目:
 
そして gpg を使用した後に元に戻して下さい。おそらく {{Ic|/dev/pts/}} と同じのが正しいです。
 
そして gpg を使用した後に元に戻して下さい。おそらく {{Ic|/dev/pts/}} と同じのが正しいです。
   
  +
{{Note|tty の所有者が pinentry を実行しているユーザーと一致している必要があります。{{Ic|tty}} グループに属しているだけでは不十分です。}}
{{Note|The owner of tty ''must'' match with the user for which pinentry is running. Being part of the group {{Ic|tty}} '''is not''' enough.}}
 
  +
  +
{{Tip|{{ic|script}} で gpg を実行した場合、新しい tty が適切な所有権で使われます:
  +
  +
# script -q -c "gpg --gen-key" /dev/null
  +
}}
   
 
=== エージェントがファイルの終末についてエラーを表示する ===
 
=== エージェントがファイルの終末についてエラーを表示する ===
468行目: 835行目:
 
=== KGpg 設定のパーミッション ===
 
=== KGpg 設定のパーミッション ===
   
There have been issues with {{Pkg|kdeutils-kgpg}} being able to access the {{ic|~/.gnupg/}} options. One issue might be a result of a deprecated ''options'' file, see the [https://bugs.kde.org/show_bug.cgi?id=290221 bug] report.
+
{{Pkg|kgpg}} には {{ic|~/.gnupg/}} のオプションが使えないという問題がありました。非推奨となった ''options'' ファイルが原因です。[https://bugs.kde.org/show_bug.cgi?id=290221 バグ] レポートを参照してください。
   
  +
=== GNOME on Wayland で SSH エージェントのソケットが上書きされる ===
Another user reported that ''KGpg'' failed to start until the {{ic|~/.gnupg}} folder is set to {{ic|drwxr-xr-x}} permissions. If you require this work-around, ensure that the directory contents retain {{ic|-rw-------}} permissions! Further, report it as a bug to the [https://bugs.kde.org/buglist.cgi?quicksearch=kgpg developers].
 
   
  +
Wayland のセッションでは、{{Ic|gnome-session}} によって {{Ic|SSH_AUTH_SOCK}} が標準の gnome-keyring ソケット {{Ic|$XDG_RUNTIME_DIR/keyring/ssh}} に設定されます。このため {{Ic|~/.pam_environmment}} や systemd のユニットファイルで設定した値が上書きされてしまいます。
=== gnome-keyring と gpg-agent が衝突する ===
 
   
  +
この挙動を無効化するには {{Ic|GSM_SKIP_AGENT_WORKAROUND}} 変数を設定してください:
Gnome keyring は GPG エージェントコンポーネントを実装していますが、GnuPG バージョン 2.1 から、GnuPG は {{ic|GPG_AGENT_INFO}} 環境変数を無視するようになったため、Gnome keyring を GPG エージェントとして使うことはできません。
 
   
  +
{{hc|~/.pam_environment|2=
However, since version 0.9.6 the package {{Pkg|pinentry}} provides the {{Ic|pinentry-gnome3}} program. You may set the following option in your {{Ic|gpg-agent.conf}} file
 
  +
SSH_AGENT_PID DEFAULT=
pinentry-program /usr/bin/pinentry-gnome3
 
  +
SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"
in order to make use of that pinentry program.
 
  +
GSM_SKIP_SSH_AGENT_WORKAROUND DEFAULT="true"
  +
}}
   
  +
=== mutt ===
Since version 0.9.2 all pinentry programs can be configured to optionally save a passphrase with libsecret. For example, when the user is asked for a passphrase via {{Ic|pinentry-gnome3}}, a checkbox is shown whether to save the passphrase using a password manager. Unfortunately, the package {{Pkg|pinentry}} does not have this feature enabled (see {{Bug|46059}} for the reasons). You may use {{AUR|pinentry-libsecret}} as a replacement for it, which has support for libsecret enabled.
 
   
  +
Mutt は ''gpg-agent'' を正しく使用できないため、mutt を使う場合は {{ic|GPG_AGENT_INFO}} [[環境変数]]を設定する必要があります (中身は何でもかまいません)。[[#パスワードのキャッシュ|パスワードのキャッシュ]]も有効化してください。
=== mutt and gpg ===
 
   
To be asked for your GnuPG password only once per session as of GnuPG 2.1, see [https://bbs.archlinux.org/viewtopic.php?pid=1490821#p1490821 this forum thread].
+
詳しくは [https://bbs.archlinux.org/viewtopic.php?pid=1490821#p1490821 フォーラムスレッド] を参照してください。
   
 
=== gnupg バージョン 2.1 にアップグレードすると鍵が"消失"する ===
 
=== gnupg バージョン 2.1 にアップグレードすると鍵が"消失"する ===
499行目: 868行目:
 
$ gpg --list-keys
 
$ gpg --list-keys
   
=== (鍵を受信しようとすると) どのキーサーバーでも gpg がフリーズする ===
+
=== (鍵を受信しようとすると) どのサーバーでも gpg がフリーズする ===
   
特定のキーサーバーで鍵を受信しようとして gpg がフリーズしている場合、dirmngr を kill して (問題が起こっていない) 他のキーサーバーにアクセスできるようにする必要があります。そうしないと全てのキーサーバーでフリーズしてしまいます。
+
特定のサーバーで鍵を受信しようとして gpg がフリーズしている場合、dirmngr を kill して (問題が起こっていない) 他のサーバーにアクセスできるようにする必要があります。そうしないと全てのサーバーでフリーズしてしまいます。
   
 
=== スマートカードが検出されない ===
 
=== スマートカードが検出されない ===
507行目: 876行目:
 
スマートカードにアクセスするための権限がない場合、カードを正しく設定して接続しても、{{ic|card error}} が表示されることがあります。
 
スマートカードにアクセスするための権限がない場合、カードを正しく設定して接続しても、{{ic|card error}} が表示されることがあります。
   
スマートカードにアクセスする必要があるユーザーに {{ic|scard}} を追加することで解決できます。追加したら、以下のような [[Udev#udev ルールを記述する|udev]] ルールを作って下さい:
+
スマートカードにアクセスする必要があるユーザーに {{ic|scard}} を追加することで解決できます。追加したら、以下のような [[Udev#udev ルールについて|udev]] ルールを作って下さい:
 
{{hc|/etc/udev/rules.d/71-gnupg-ccid.rules|<nowiki>
 
{{hc|/etc/udev/rules.d/71-gnupg-ccid.rules|<nowiki>
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="664", GROUP="scard"
+
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"
 
</nowiki>}}
 
</nowiki>}}
   
 
VENDOR と MODEL は {{ic|lsusb}} の出力にあわせて変更する必要があります。上記は YubikeyNEO の例です。
 
VENDOR と MODEL は {{ic|lsusb}} の出力にあわせて変更する必要があります。上記は YubikeyNEO の例です。
  +
  +
=== gpg: WARNING: server 'gpg-agent' is older than us (x < y) ===
  +
  +
{{ic|gnupg}} をアップグレードしたのに古い gpg-agent が動作し続けていると警告が表示されます。ユーザーの {{ic|gpg-agent.socket}} を再起動してください (再起動するときに {{ic|--user}} フラグを使ってください)。
  +
  +
=== IPC 接続の呼び出しに失敗 ===
  +
  +
{{ic|killall gpg-agent dirmngr}} と {{ic|$GNUPGHOME/crls.d/}} フォルダの権限が {{ic|700}} になっていて、{{ic|gpg-agent}} と {{ic|dirmngr}} が起動していないことを確認してください.
  +
  +
デフォルトでは、{{Pkg|gnupg}} パッケージは、ソケットのために {{ic|/run/user/$UID/gnupg/}} ディレクトリを使用します。[https://github.com/gpg/gnupg/blob/25ae80b8eb6e9011049d76440ad7d250c1d02f7c/README#L121-L122 GnuPG documentation] には、このディレクトリが望ましいと書かれています (すべてのファイルシステムがソケットに対応しているわけではありません)。あなたの {{ic|agent-socket}} の設定が、適切なファイルシステムを持つパスを指定しているかどうか確認してください。ic|agent-socket}} のパス設定は、 {{ic|gpgconf --list-dirs agent-socket}} を実行することで確認することができます。
  +
  +
{{ic|gpg-agent}} が正常に起動するか、{{ic|gpg-agent --daemon}} でテストしてください。
  +
  +
=== 汚染された PGP 証明書の軽減 ===
  +
  +
2019 年 6 月、未知の攻撃者が数万(または数十万)の署名を持つ複数の高プロファイル PGP 証明書をスパム送信し(CVE-2019-13050)、これらの署名を SKS 鍵サーバーにアップロードしていました。
  +
これらの汚染された証明書がキーリングに存在すると、gpg は以下のメッセージを表示してハングします。
  +
  +
gpg: removing stale lockfile (created by 7055)
  +
  +
この場合、[https://tech.michaelaltfield.net/2019/07/14/mitigating-poisoned-pgp-certificates/ ブログポスト]にあるように、汚染された証明書を削除することで軽減できる可能性があります。
  +
  +
=== IPC 応答が無効であり、デバイスの ioctl が不適切 ===
  +
  +
デフォルトの pinentry プログラムは、{{ic|/usr/bin/pinentry-gtk-2}} です。{{Pkg|gtk2}} が使用できない場合、pinentry は{{ic|/usr/bin/pinentry-curses}}にフォールバックし、署名に失敗します。
  +
  +
gpg: signing failed: Inappropriate ioctl for device
  +
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device
  +
  +
pinentry プログラム {{ic|/usr/bin/pinentry-tty}} と {{ic|/usr/bin/pinentry-curses}} を使用するには、環境変数 {{ic|GPG_TTY}} を設定する必要があります。
  +
  +
$ export GPG_TTY=$(tty)
  +
  +
=== キーブロックのリソースが存在しません ===
  +
  +
鍵をインポートしようとしたときに、このようなエラーが発生した場合、
  +
  +
gpg: keyblock resource '''gnupg_home''/pubring.kbx': No such file or directory
  +
  +
これは GnuPG がホームディレクトリを作成しないためです。単に手動で作成してください。
  +
  +
$ mkdir -m 700 ''gnupg_home''
  +
  +
=== サブキーが機能制限されて作成される ===
  +
  +
場合によっては、カスタムの機能セットを使用してサブキーを作成すると、サブキーが "制限付き" としてマークされることがあります。これは、対話型プロンプトで機能が切り替わるときに、オプション 7 または 8 ("set your own capabilities") を指定した {{ic|addkey}} コマンドで発生します。回避策は、機能の選択を求められたときに、個々の機能を切り替えるのではなく、目的の機能セットを文字列として直接入力することです。たとえば、認証機能のみを持つサブキーを作成するには、"=A" と入力します。
   
 
== 参照 ==
 
== 参照 ==
   
 
* [https://gnupg.org/ GNU Privacy Guard ホームページ]
 
* [https://gnupg.org/ GNU Privacy Guard ホームページ]
* [https://fedoraproject.org/wiki/Creating_GPG_Keys Creating GPG Keys (Fedora)]
+
* [https://futureboy.us/pgp.html Alan Eliasen's GPG Tutorial]
  +
* [[RFC:4880|RFC 4880]] — "OpenPGP Message Format"
* [https://wiki.debian.org/Subkeys OpenPGP subkeys in Debian]
 
  +
* [https://help.riseup.net/en/security/message-security/openpgp/gpg-best-practices gpg.conf recommendations and best practices]
* [http://blog.sanctum.geek.nz/series/linux-crypto/ 詳しい gpg のチュートリアル]
 
  +
* [[Fedora:Creating GPG Keys]]
* [https://help.riseup.net/en/security/message-security/openpgp/gpg-best-practices gpg.conf の推奨事項とベストプラクティス]
 
  +
* [[Debian:Subkeys]]
* [https://github.com/ioerror/torbirdy/blob/master/gpg.conf Torbirdy gpg.conf]
 
  +
* [https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md Protecting code integrity with PGP]
  +
* [https://sanctum.geek.nz/arabesque/series/gnu-linux-crypto/ A more comprehensive gpg Tutorial]
 
* [https://www.reddit.com/r/GPGpractice/ /r/GPGpractice - a subreddit to practice using GnuPG.]
 
* [https://www.reddit.com/r/GPGpractice/ /r/GPGpractice - a subreddit to practice using GnuPG.]

2024年8月24日 (土) 12:24時点における最新版

関連記事

公式サイト によれば:

GnuPG は RFC4880 (別名 PGP) で定義される OpenPGP 標準の完全でフリーな実装です。GnuPG を使うことでデータや通信を暗号化したり署名することができます。多目的の鍵管理システムであり、あらゆる種類の公開鍵ディレクトリのアクセスモジュールです。GnuPG (またの名を GPG) は他のアプリケーションとの簡単に連携できる機能を備えたコマンドラインツールです。豊富なアプリケーションとライブラリが利用可能です。GnuPG のバージョン2は S/MIME と ssh のサポートも含んでいます。
警告: GnuPG は OpenPGP 形式の実装として始まりました。しかし、近年、そのメンテナは OpenPGP 標準化の取り組み、GnuPG 固有の方法で形式を個別に拡張しています (draft-koch-librepgp を参照) これらの変更により、バージョン 2.4 以降の他の実装との互換性の問題が発生します。#OpenPGP の互換性 を参照してください。

目次

インストール

gnupg をインストールしてください。

gnupg をインストールすると、GnuPG がパスフレーズエントリに使用するシンプルな PIN やパスフレーズエントリダイアログのコレクションである pinentry もインストールされます。シェルスクリプト /usr/bin/pinentry#pinentry で説明されている順番で、どの pinentry ダイアログを使用するかを決定します。

グラフィカルフロントエンドや GnuPG と連携するプログラムを使いたい場合はアプリケーション一覧/セキュリティ#暗号化, 署名, ステガノグラフィーを参照してください。

設定

設定ファイルのディレクトリ

GnuPG では $GNUPGHOME によって全ての設定ファイルを保存するディレクトリが指定されます。デフォルトでは $GNUPGHOME は設定されておらず、代わりに $HOME が使われます。そのためインストール直後は ~/.gnupg ディレクトリが確認できます。スタートアップファイルに次の行を記述することでデフォルト設定を変更できます:

export GNUPGHOME="/path/to/directory"

設定ファイル

デフォルトの設定ファイルは ~/.gnupg/gpg.conf~/.gnupg/dirmngr.conf です。

デフォルトでは、gnupg ディレクトリのパーミッション700 に設定されており、ディレクトリのファイルのパーミッションは 600 に設定されています。ファイルの読み書きやアクセスの権限を持っているのはディレクトリの所有者だけです (r,w,x)。これはセキュリティ上の理由で設定されていることなので変更してはいけません。ディレクトリやファイルがこのセキュリティ対策に従っていない場合、ファイルやホームディレクトリのパーミッションが安全ではないという警告が表示されます。

どんな長いオプションも設定ファイルに追加します。2つのダッシュを書かないで、オプションや必要な引数の名前を書いて下さい。スケルトンファイルは /usr/share/doc/gnupg/ にあります。gpg がなんらかの操作のため最初に起動されたとき、~/.gnupg が存在しなければこれらのファイルが ~/.gnupg にコピーされます。#参照 に他の例があります。

また、pacman がパッケージの署名の検証に使用する設定ファイルは別に存在します。詳しくは pacman-key を見てください。

新規ユーザーのデフォルトオプション

新規ユーザーのデフォルトオプションを設定したい場合、/etc/skel/.gnupg/ に設定ファイルを配置してください。新しいユーザーが追加されると、/etc/skel/.gnupg/ から GnuPG のホームディレクトリにファイルがコピーされます。既存のユーザーのために新しい GnuPG ホームディレクトリを作成できる addgnupghome というスクリプトも存在します:

# addgnupghome user1 user2

上記のコマンドは /home/user1/.gnupg/home/user2/.gnupg を作成してスケルトンディレクトリからファイルをコピーします。既に GnuPG のホームディレクトリが存在するユーザーはスキップされます。

使い方

ノート: コマンドに <user-id> が必要なときは、鍵 ID、指紋、名前やメールアドレスの一部などを指定できます。これについて GnuPG は寛容です。

鍵ペアの作成

鍵ペアを生成するにはターミナルに次を入力:

$ gpg --full-gen-key
ヒント: --expert を使うことで他の暗号を利用することができます (楕円曲線暗号など)。

上記のコマンドを実行すると複数の質問がきかれます。大抵の場合、以下の設定が必要になります:

  • RSA (署名のみ) と RSA (暗号化のみ) 鍵。
  • 鍵長は2048ビットで十分です。4096ビットを使ったところで "大した効果はありませんし、無駄に時間がかかるようになるだけです"
  • 副鍵の有効期限の設定は技術的には必須ではありませんが、設定することは悪くありません。標準的なユーザーなら、1年間で十分でしょう。たとえ鍵束へのアクセスを失っても、他の人が有効でないことを知ることができるようになります。鍵を作成した後、新しい鍵を再発行しなくても満了日は延長することができます。
  • 名前とメールアドレス。後で同じ鍵に別の識別子を追加できます (複数のメールアドレスが存在する場合など)。
  • コメントは必要ありません。コメントフィールドのセマンティクスは 定義があやふや なため、識別子としては限定的です。
  • 安全なパスフレーズを選ぶようにしてください (セキュリティ#パスワードの管理を参照)。
ノート: 入力した名前とメールアドレスは鍵をインポートすれば誰でも確認できるようになります。

鍵一覧

  • 公開鍵束の鍵の一覧:
$ gpg --list-keys
  • 秘密鍵束の鍵の一覧:
$ gpg --list-secret-keys

公開鍵のエクスポート

公開鍵暗号で交換されたメッセージの機密性を保証するのが gpg の主な利用法です。互いの鍵束の公開鍵を交換して、メッセージを暗号化するときに使用します。秘密鍵は必ず漏洩しないようにしてください。機密性が破れてしまいます。

他の人があなたに暗号化したメッセージを送れるようにするには、彼らがあなたの公開鍵を知っている必要があります。

(メールで送る場合などのために) ASCII 版の公開鍵を public.key ファイルとして生成するには:

$ gpg --output public.key --armor --export user-id

あるいは、鍵サーバーで鍵を共有する方法もあります。

ヒント:
  • --no-emit-version を使うか、これを設定ファイルに書くことでバージョン番号の表示を抑制できます。
  • user-id を省略して、キーリング内のすべての公開鍵をエクスポートできます。これは、一度に複数の ID を共有したい場合や、別のアプリケーションにインポートする場合に便利です。例: Thunderbird

公開鍵のインポート

メッセージを暗号化して他の人に送るには、彼らの公開鍵が必要です。公開鍵 (public.key) を自分の公開鍵リングにインポートするには:

$ gpg --import public.key

あるいは、鍵サーバーで公開鍵を見つけます。

特定の Arch Linux パッケージをインストールするためにキー ID をインポートしたい場合は、キーリングの管理Makepkg#署名チェック を参照してください。

鍵サーバーを使用する

鍵の送信

自分の公開鍵を公共の PGP 鍵サーバーに登録することで、他の人があなたに直接連絡することなしにあなたの鍵を入手できるようになります:

$ gpg --send-keys user-id
警告: 鍵を鍵サーバーに登録してから、サーバーから鍵を削除することはできません [1]。 その理由は、MIT PGP Public Key Server FAQで説明されています。
ノート: 関連するメールアドレスが公開されると、スパムメールの標的となる可能性があり、この場合、スパム対策用のフィルタリングが必要となる場合があります。

鍵の検索と受信

鍵サーバーの鍵の情報を確認したい場合、次のコマンドを実行:

$ gpg --search-keys user-id

鍵サーバーから鍵をインポートするには:

$ gpg --recv-keys key-id
警告:
  • 誰でも鍵サーバーに鍵を送ることができます。そのため、ダウンロードした鍵が本当にその人のものであると信用してはいけません。入手した鍵の指紋を、持ち主が別の場所(ブログ、サイト、メール・電話で連絡するなど)で公開している指紋と比較してその鍵の真正性を確かめるべきです。複数の情報源を使うことでその鍵の信頼性は増します。Wikipedia:Public key fingerprint を参照。
  • ID が短いと衝突する可能性があります。インポートされた鍵には全て短い ID が割り当てられます。鍵を受け取るときに完全な指紋か長い鍵 ID を使うことで衝突を回避できます [2]
ヒント: auto-key-retrievegpg.conf に追加すると、必要に応じて鍵サーバから鍵を自動的に取得しますが、これは プライバシー侵害 と見なされる可能性があります。gpg(1) の "web bug" を参照。

鍵サーバー

最も一般的な鍵サーバーは次の通りです:

  • Ubuntu Keyserver: 分散型、検証なし、キーは削除不可。
  • Mailvelope Keyserver: 中央型、E メール ID の検証、キーは削除可能。
  • keys.openpgp.org: 中央型、E メール ID の検証、キーは削除可能。サードパーティの署名無し (つまり、Web of Trust のサポートは無し)。

Wikipedia:Key server (cryptographic)#Keyserver examples にその他の鍵サーバもあります。

代替の鍵サーバは、#設定ファイルのうちどれかで keyserver オプションを使用することによって指定することができます。例えば:

~/.gnupg/dirmngr.conf
keyserver hkp://keyserver.ubuntu.com

いつも使用しているサーバが思うように動かない時に、一時的に別のサーバを使用すると便利です。例えば、以下のようにして別のサーバを使用できます:

$ gpg --keyserver hkps://keys.openpgp.org/ --search-keys user-id
ヒント:
  • デフォルトの hkps 鍵サーバプールを使用していて、gpg: keyserver receive failed: General error というメッセージで失敗する場合、dirmngr.conf 内で hkp-cacert /usr/share/gnupg/sks-keyservers.netCA.pem を使用して HKPS プールの検証証明書を設定し、古い dirmngr プロセスを kill してください。
  • gpg: keyserver receive failed: Connection refused というメッセージで失敗する場合、別の DNS サーバを使ってみてください。
  • Tor#TorsocksTor 経由で鍵サーバに接続することもできます。また、--use-tor コマンドラインオプションもあります。詳細は [3] を参照してください。
  • http_proxy 環境変数を設定し、dirmngr.conf 内で honor-http-proxy を設定すれば、プロキシを使って鍵サーバに接続することもできます。また、設定ファイル内で http-proxy host[:port] を使えば、先の環境変数をオーバーライドすることができます。変更を適用するには、dirmngr.service ユーザーユニット再起動してください。
  • gpg: keyserver receive failed: Server indicated a failure というメッセージで鍵サーバに接続できない場合、別のポートを使用するように gpg を設定する必要があるのかもしれません。例えば、Ubuntu の鍵サーバで80番ポートを使用するには、keyserver hkp://keyserver.ubuntu.com:80 と設定してください。

Web Key Directory

Web Key Service (WKS) プロトコルは、鍵配布のための新しい 標準で、電子メールドメインが Web Key Directory (WKD) という独自の鍵サーバーを提供するものです。電子メールアドレス (例 : user@example.com) に暗号化するとき、GnuPG (>=2.1.16) は、公開鍵をローカル鍵束にまだ持っていなければ、 HTTPS でそのドメイン (example.com) に照会します。オプション auto-key-locate は、このメールアドレスのローカル鍵束に鍵がない場合、WKD プロトコルを使って鍵を探します。

# gpg --recipient user@example.org --auto-key-locate --encrypt doc

WKD をサポートしているメールプロバイダーの一覧は GnuPG Wiki を参照してください。メールアドレスのドメインを自分で管理している場合は、このガイドに従って、自分のドメインで WKD を有効にすることができます。あなたの鍵が WKD で見つかるかどうかを確認するには、このウェブインターフェイスが使用できます。

暗号化と復号化

非対称

暗号化や復号化をするときは複数の秘密鍵を使用することが可能です。複数の鍵を使うときは使用する鍵を選択する必要があります。-u <user-id> オプションや --local-user <user-id> オプションを使うことで選択できます。このオプションを使うとデフォルトの鍵を使用する代わりに指定された鍵を使用します。先に#鍵の作成が必要です。

(テキストでメッセージをコピー&ペーストするのに適している) ASCII armor を使ってファイルを暗号化するには、次を使用:

$ gpg --encrypt --armor secret.txt

単に暗号化だけしたいときは --armor は不要です。

ヒント:
  • 受取人を変更したい場合は -r <user-id> (または --recipient <user-id>) オプションで変更できます。
  • 暗号メッセージに受取人の鍵 ID を入れたくないときは --recipient のかわりに -R <user-id> または --hidden-recipient <user-id> を追加してください。メッセージの受取人を隠蔽して、トラフィックの解析に対する対抗策になります。
  • バージョン番号を出力したくないときは --no-emit-version を追加してください。または設定ファイルに同じ設定を追加してください。
ノート: gnupg を使えば機密文書を暗号化できますが、一度に複数のファイルを暗号化することはできません。ディレクトリやファイルシステム全体を暗号化したいときは、TrueCryptEncFS などを使用するか、tarball にファイルをまとめて暗号化すると良いでしょう。

ファイルを復号化するには、次のコマンドを使用:

$ gpg --decrypt secret.txt.asc

パスフレーズの入力が求められます。復号化するには送信者の公開鍵をインポートしてある必要があります。

対称

対称暗号化では鍵を生成する必要がなくパスフレーズだけでデータを暗号化できます。対称暗号化を使用するするには --symmetric または -c を使用します:

$ gpg -c doc

例:

  • パスフレーズを使って対称暗号で doc を暗号化。
  • AES-256 暗号アルゴリズムを使ってパスフレーズを暗号化。
  • SHA-512 ダイジェストアルゴリズムを使ってパスフレーズをハッシュ化。
  • 65536回繰り返しパスフレーズをハッシュ化。
$ gpg -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 65536 doc

対称暗号化された doc.gpg をパスフレーズで復号化して doc として同じディレクトリに出力するには:

$ gpg --output doc --decrypt doc.gpg

ディレクトリ

ディレクトリの暗号化・復号化は gpgtar(1) で行うことができます。

暗号化:

$ gpgtar -c -o dir.gpg dir

復号化:

$ gpgtar -d dir.gpg

鍵の管理

秘密鍵のバックアップ

秘密鍵をバックアップするには以下を実行:

$ gpg --export-secret-keys --armor <user-id> > privkey.asc

gpg のリリース 2.1 からデフォルトの挙動が変わっており、たとえ鍵の作成時にパスワードを設定しなかった場合でも上記のコマンドを実行したときにパスフレーズによる保護が必須になっています。エクスポートされたファイルを入手してしまえば、パスフレーズを知らなくてもファイルを暗号化したり署名を加えることができてしまうためです。

警告: パスフレーズは秘密鍵の最大の弱点となります。暗号化されたコンテナやドライブなど、秘密鍵は安全な場所に保管してください。

秘密鍵のバックアップをインポートするには:

$ gpg --import privkey.asc

失効証明書のバックアップ

失効証明書は、新しく生成されたキーに対して自動的に生成されます。これらはデフォルトで ~/.gnupg/openpgp-revocs.d/ にあります。証明書のファイル名は、取り消すキーのフィンガープリントです。 失効証明書は、ユーザーが後で次を使用して手動で生成することもできます。

$ gpg --gen-revoke --armor --output revcert.asc user-id

この証明書は、紛失または侵害された場合に #鍵の取り消し に使用できます。バックアップは、秘密鍵にアクセスできなくなったため、上記のコマンドで新しい失効証明書を生成できない場合に役立ちます。必要に応じて印刷して手で入力できるほど短いです。

警告: 失効証明書にアクセスできる人は誰でも、キーを公に失効させることができます。このアクションは元に戻すことはできません。秘密鍵を保護するのと同じように、失効証明書を保護します。

鍵の編集

  • gpg --edit-key <user-id> コマンドを実行するとメニューが表示され、鍵管理に関連するほとんどの作業を行うことができます。以下は満了日を設定する例です:
$ gpg --edit-key <user-id>
> key number
> expire yyyy-mm-dd
> save
> quit

便利なコマンド:

> passwd       # change the passphrase
> clean        # compact any user ID that is no longer usable (e.g revoked or expired)
> revkey       # revoke a key
> addkey       # add a subkey to this key
> expire       # change the key expiration time
  • 公開鍵の ASCII バージョンを生成 (例: メールなどで配るため):
$ gpg --armor --output public.key --export <user-id>
  • PGP 公開鍵サーバーに鍵を登録して、他の人があなたに直接連絡しなくても鍵を取得できるようにする:
$ gpg  --keyserver pgp.mit.edu --send-keys <key-id>
  • ユーザー Bob あてに署名と暗号化:
$ gpg -se -r Bob file
  • クリアテキスト署名を作成:
$ gpg --clearsign file

副鍵のエクスポート

複数のデバイスで同じ鍵を使い回す場合、マスター鍵を分離させて、セキュリティが低いシステムでは暗号化に必要な副鍵だけを使いたいという状況が考えられます。

まず、エクスポートしたい副鍵を確認してください:

$ gpg -K

エクスポートする副鍵だけを選択:

$ gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.gpg
警告: ! を追加するのを忘れると、全ての副鍵がエクスポートされます。

ここで作業を終えても良いですが、パスフレーズの変更もしておくと安全です。一時フォルダに鍵をインポートします:

$ gpg --homedir /tmp/gpg --import /tmp/subkey.gpg
$ gpg --homedir /tmp/gpg --edit-key <user-id>
> passwd
> save
$ gpg --homedir /tmp/gpg -a --export-secret-subkeys [subkey id]! > /tmp/subkey.altpass.gpg
ノート: マスター鍵が存在しない、また、マスター鍵のパスワードが変更されていないという警告が表示されますが、変更したのは副鍵のパスワードなので無視してかまいません。

これで、他のデバイスで /tmp/subkey.altpass.gpg を使うことができます。

有効期限の延長

警告: 何か特段の事情がないかぎり、有効期限が切れたり無効になった副鍵を削除しないでください。削除してしまうとその副鍵で暗号化したファイルを復号化できなくなってしまいます。満了した、または無効のキーを削除するのは他のユーザーの鍵束を整理するときだけにしてください。

副鍵を設定して一定期間後に満了したら、新しい副鍵を作成できます。他のユーザーが鍵束を更新できるように数週間前に行うようにしましょう。

ノート: 新しい鍵を作成する必要はありません。期限がきて使えなくなっただけだからです。有効期間を延長することができます。
  • 新しい副鍵を作成 (署名と暗号化の鍵の両方)
$ gpg --edit-key <user-id>
> addkey

そして質問に答えて下さい (推奨される設定については前のセクションを参照)。

  • 変更を保存:
> save
  • 鍵サーバーにアップデート:
$ gpg  --keyserver pgp.mit.edu --send-keys <user-id>

また、この鍵を複数のコンピュータで使用する場合は、公開鍵(新しい署名付き有効期限付き)をエクスポートして、それらのマシンでインポートすることもできます。

$ gpg --export --output pubkey.gpg user-id
$ gpg --import pubkey.gpg

秘密鍵の再エクスポートやバックアップの更新は必要ありません。マスター秘密鍵自体に有効期限がなく、公開鍵やサブ鍵に残された有効期限の署名があればよいのです。

Rotating subkeys

警告: Never delete your expired or revoked subkeys unless you have a good reason. Doing so will cause you to lose the ability to decrypt files encrypted with the old subkey. Please only delete expired or revoked keys from other users to clean your keyring.

Alternatively, if you prefer to stop using subkeys entirely once they have expired, you can create new ones. Do this a few weeks in advance to allow others to update their keyring.

ヒント: You do not need to create a new key simply because it is expired. You can extend the expiration date, see the section #Extending expiration date.

Create new subkey (repeat for both signing and encrypting key)

$ gpg --edit-key user-id
> addkey

And answer the following questions it asks (see #Create a key pair for suggested settings).

Save changes

> save

Update it to a keyserver.

$ gpg --keyserver pgp.mit.edu --send-keys user-id

You will also need to export a fresh copy of your secret keys for backup purposes. See the section #Backup your private key for details on how to do this.

ヒント: Revoking expired subkeys is unnecessary and arguably bad form. If you are constantly revoking keys, it may cause others to lack confidence in you.

鍵の取り消し

鍵が侵害された、置き換えられた、使用されなくなった、またはパスフレーズを忘れた場合は、キーの取り消しを実行する必要があります。これは、鍵を鍵の失効証明書とマージすることによって行われます。

鍵ペアにアクセスできなくなった場合は、まず#公開鍵のインポートして独自の鍵をインポートします。 次に、キーを失効させるために、#失効証明書のバックアップ で保存したファイルをインポートします。

 $ gpg --import revcert.asc

ここで、取り消しを公開する必要があります。 #鍵サーバーを使用するで過去に PGP サーバーを使用したことがある場合は、取り消された鍵を公開 PGP サーバーに送信します。それ以外の場合は、取り消された鍵をファイルにエクスポートし、通信パートナーに配布します。

署名

署名は文章を証明します。文章が改変された場合、署名の検証に失敗します。公開鍵を使用して文章を暗号化する暗号化とは違って、署名はユーザーの秘密鍵を使って作成されます。署名された文章を受け取った人は送り主の公開鍵を使って署名を検証できます。

署名の作成

ファイルに署名する

ファイルに署名するには --sign または -s フラグを使います:

 $ gpg --output doc.sig --sign doc

上記のコマンドは暗号化も行ってファイルをバイナリ形式で保存します。

ファイルやメッセージにクリア署名

バイナリ形式に圧縮しないでファイルに署名するには:

 $ gpg --clearsign doc

上記のコマンドは文章を ASCII-armored 署名でラッピングしますが、文章に変更は加えられません。

分離署名を作成する

文章やファイルとは別に署名ファイルを作成したい場合、--detach-sig フラグを使ってください:

 $ gpg --output doc.sig --detach-sig doc

上記の方法はソフトウェアプロジェクトを配布するときによく用いられます。署名書を検証することで第三者によってファイルが改竄されていないことが確認できます。

署名の検証

署名を検証するには --verify フラグを使います:

 $ gpg --verify doc.sig

doc.sig は検証したい署名に置き換えてください。

ファイルの検証と復号化を同時に行いたいお場合、--decrypt フラグを使ってください。

分離署名を検証する場合、ファイルと署名の両方が必要になります。例えば、Arch Linux の ISO を検証する場合:

 $ gpg --verify archlinux-version.iso.sig

archlinux-version.iso が同じディレクトリに存在していなければなりません。

署名の確認

署名を確認するには、--verify フラグを使用します。

$ gpg --verify doc.sig

ここで doc.sig は、検証したい署名を含む署名付きファイルです。

分離された署名を検証する場合、署名されたデータファイルと署名ファイルの両方が検証時に存在する必要があります。例えば、Arch Linux の最新の iso を検証する場合、次のようになります。

$ gpg --verify archlinux-version.iso.sig

ここで archlinux-version.iso は同じディレクトリにある必要があります。

また、第2引数で署名付きデータファイルを指定することも可能です。

$ gpg --verify archlinux-version.iso.sig /path/to/archlinux-version.iso

署名に加えて暗号化されている場合は、復号化を行うだけで署名も検証されます。

gpg-agent

gpg-agent はキーチェインにパスワードをリクエストしたりキャッシュしたりするのに使われるデーモンです。メールクライアントなど外部のプログラムから GnuPG を利用する場合に便利です。gnupg には systemd ユーザーソケットが付属しており、デフォルトで有効になります: gpg-agent.socket, gpg-agent-extra.socket, gpg-agent-browser.socket, gpg-agent-ssh.socket, dirmngr.socket

  • gpg はメインの gpg-agent.socket を使って gpg-agent デーモンに接続します。
  • gpg-agent-extra.socket はリモート環境から Unix ドメインソケットの転送を設定します。秘密鍵をリモート環境に移さなくてもリモート環境で gpg が使えるようになります。詳しくは gpg-agent(1) を参照。
  • The gpg-agent-browser.socket allows web browsers to access the gpg-agent daemon.
  • SSHgpg-agent-ssh.socket を使って ssh-add プログラムによって追加された SSH 鍵をキャッシュします。必要な設定は #SSH エージェントを見てください。
  • dirmngr.socket は鍵サーバーへの接続を処理する GnuPG デーモンを起動します。
ノート: GnuPG の設定ファイルのディレクトリがデフォルトと異なる場合、gpgconf --list-dirs の値を使用するようにソケットファイルを編集してください。

設定

gpg-agent は ~/.gnupg/gpg-agent.conf ファイルで設定することができます。設定オプションは gpg-agent(1) に記載されています。例えば、未使用の鍵の cache ttl を変更することができます:

~/.gnupg/gpg-agent.conf
default-cache-ttl 3600
ヒント: セッションを通してパスフレーズをキャッシュするには、次のコマンドを実行してください:
$ /usr/lib/gnupg/gpg-preset-passphrase --preset XXXXXX

XXXX は鍵輪に置き換えてください。鍵輪の値は gpg --with-keygrip -K を実行することで取得できます。パスフレーズは gpg-agent が再起動されるまで保存されます。default-cache-ttl の値を設定した場合、そちらが優先されます。

エージェントのリロード

設定を変更した後は、gpg-connect-agent でエージェントをリロードしてください:

$ gpg-connect-agent reloadagent /bye

シェルに OK と出力されます。

しかし、エージェント設定に keep-screen が追加されている場合など、再起動だけでは十分でないこともあります。 この場合、まず進行中の gpg-agent プロセスを kill してから、上記で説明したように再起動する必要があります。

pinentry

gpg-agentpinentry-program stanza を使用して、パスフレーズの入力を促す際に、特定の pinentry ユーザーインターフェイスを使用するように設定できます。例えば、以下の通りです。

~/.gnupg/gpg-agent.conf
pinentry-program /usr/bin/pinentry-curses

他のも様々な pinentry プログラムがあります。pacman -Ql pinentry | grep /usr/bin/ を参照してください。

ヒント: /usr/bin/pinentry-kwallet を使うには kwalletcliAUR パッケージをインストールする必要があります。

変更を行った後は、エージェントのリロードを忘れないでください。

パスワードのキャッシュ

GnuPG のパスワードをセッションの間だけ記憶させたい場合、max-cache-ttldefault-cache-ttl を高い値に設定してください:

gpg-agent.conf
max-cache-ttl 60480000
default-cache-ttl 60480000

詳しくは #gpg-agent を参照。

無人のパスフレーズ

GnuPG 2.1.0 から gpg-agent と pinentry の利用が必須になりました。これによって --passphrase-fd 0 コマンドラインオプションによって STDIN からパイプで渡されたパスフレーズの後方互換性が損ねられています。古いリリースと同じような機能を使うには2つのことをする必要があります:

まず、gpg-agent の設定を編集して loopback pinentry モードを許可してください:

~/.gnupg/gpg-agent.conf
allow-loopback-pinentry

gpg-agent プロセスが実行している場合は再起動して変更を適用します。

次に、更新する必要があるアプリケーションに以下のようにコマンドラインパラメータを含めて loopback モードを使用します:

$ gpg --pinentry-mode loopback ...

もしくは、コマンドラインで設定ができない場合、オプションを設定に追加します:

~/.gnupg/gpg.conf
pinentry-mode loopback
ノート: 上流の開発者は gpg.confpinentry-mode loopback を設定すると他の機能が使えなくなる可能性があると示唆しています。できるかぎりコマンドラインオプションを使うようにして下さい [4]

SSH エージェント

gpg-agent には OpenSSH エージェントのエミュレーション機能が存在します。既に GnuPG スイートを使っているのであれば、SSH 鍵をキャッシュするのに使うことが可能です。さらに、パスフレーズを管理するのに GnuPG エージェントの PIN エントリダイアログを使えます。

SSH_AUTH_SOCK の設定

SSH が ssh-agent の代わりに gpg-agent を使うように SSH_AUTH_SOCK を設定してください。シェルのタイプに関係なくプロセスが gpg-agent インスタンスを使うようにするには pam_env を使用します:

~/.pam_environment
SSH_AGENT_PID	DEFAULT=
SSH_AUTH_SOCK	DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"
ノート:
  • SSH_AUTH_SOCK を手動で設定する場合、GNUPGHOME をカスタマイズしているときはソケットの場所が異なる可能性があるので注意してください。以下の bash の例を使用するか、SSH_AUTH_SOCKgpgconf --list-dirs agent-ssh-socket の値に変更してください。
  • GNOME Keyring がインストールされている場合、 その ssh コンポーネントを無効化する必要があります。そうしないと、SSH_AUTH_SOCK を上書きしてしまいます。

または、Bash を使う場合:

~/.bashrc
unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
  export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
fi
ノート: エージェントを gpg-agent --daemon /bin/sh で起動している場合、シェルは SSH_AUTH_SOCK 変数を gpg-agent から承継します [5]

適切な TTY を使うように pinentry を設定

gpg-agent(1) にあるように、ユーザーを X セッションに切り替えた場合は GPG_TTY も設定して TTY を更新してください。例:

~/.bashrc
# Set GPG TTY
export GPG_TTY=$(tty)

# Refresh gpg-agent tty in case user switches into an X session
gpg-connect-agent updatestartuptty /bye >/dev/null

複数の端末を同時に使用し、ssh コマンドを実行した同じ端末から pinentry-cursesgpg-agent がパスフレーズを要求するようにしたい場合、SSH 設定ファイルに以下を追加してください。これにより、ssh コマンドを実行するたびに TTY がリフレッシュされるようになります [6]

~/.ssh/config
Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"

なお、環境変数 GPG_TTY が設定されていないと動作しません。

SSH 鍵の追加

gpg-agent が起動していれば ssh-agent と同じように ssh-add で鍵を追加できます。追加された鍵は ~/.gnupg/sshcontrol ファイルに保存されます。パスフレーズが必要になったときは毎回 pinentry ダイアログが表示されます。パスフレーズのキャッシュは ~/.gnupg/gpg-agent.conf ファイルで制御します。以下の例では gpg-agent で鍵を3時間キャッシュします:

~/.gnupg/gpg-agent.conf
default-cache-ttl-ssh 10800
max-cache-ttl-ssh 10800

SSH 認証に PGP 鍵を使用する

PGP 鍵を SSH 鍵として使うこともできます。鍵のメンテナンスを楽にして SSH 鍵をキーカードに保存できます。認証機能を有効にして鍵を作成する必要があります (#カスタム機能を参照)。SSH 認証に PGP 鍵を使用することで得られる様々な利点があります。

  • SSH キーを維持する必要がなくなるため、キーのメンテナンスが削減されます。
  • 認証キーをスマートカードに保存する能力。GnuPG はカードが利用可能なときにキーを自動的に検出し、エージェントに追加します(ssh-add -l または ssh-add -L で確認)。キーのコメントは次のようなものであるべきです:openpgp:key-id または cardno:card-id

GPG/SSH キーの公開キー部分を取得するには、gpg --export-ssh-key gpg-key を実行します。キーが認証可能であっても、このコマンドが "Unusable public key" で失敗する場合は、! サフィックスを追加します ([7])。

GPG キーをキーカードに持っていない場合、SSH キーとして認識されるように $GNUPGHOME/sshcontrol にキーを追加する必要があります。キーがキーカードにある場合、その keygrip は sshcontrol に暗黙的に追加されます。そうでない場合、次の方法でキーの keygrip を取得します:

$ gpg --list-keys --with-keygrip
sub   rsa4096 2018-07-25 [A]
      Keygrip = 1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7

その後、sshcontrol をこのように編集します。keygrip を追加するのは一度だけの操作です。追加のキーを追加する場合を除いて、ファイルを再度編集する必要はありません。

$GNUPGHOME/sshcontrol
1531C8084D16DC4C36911F1585AF0ACE7AAFD7E7

スマートカード

GnuPG は、スマートカードリーダとのインターフェイスとして scdaemon を使用します。詳細は scdaemon(1) man ページを参照してください。

GnuPG のみ設定

ノート: scdaemon が USB スマートカードリーダに直接アクセスできるようにするには、任意の依存パッケージである libusb-compat をインストールする必要があります。

GnuPG ベース以外のカードを使う予定がない場合は、~/.gnupg/scdaemon.confreader-port パラメータを確認してください。'0' が最初に利用できるシリアルポートリーダーを、'32768' (デフォルト) が最初の USB リーダーを示しています。

GnuPG と pcscd (PCSC Lite)

pcscd(8) は、スマートカードへのアクセスを管理するデーモンです (SCard API)。(GnuPG の内臓の CCID サポートを使うなどして) GnuPG の scdaemon でスマートカードと直接接続できない場合、このデーモンは PCSC Lite ドライバを使用するスマートカードを見つけようとします。

pscsd を使うには、pcscliteccidインストールしてください。そして、pcscd.service開始し、(このサービスを永続的に使用する場合は) 有効化してください。あるいは、pcscd.socket を開始/有効化することで、必要なときにだけデーモンをアクティブ化させることもできます。

常に pcscd を使う

opensc ドライバを使用するスマートカード (一部の国々の ID カードがこれに該当します) を使う場合は、GnuPG の設定に注意する必要があります。特に設定しないと、gpg --card-status を実行した時に以下のようなメッセージが表示されるかもしれません:

gpg: selecting openpgp failed: ec=6.108

デフォルトでは、scdaemon はデバイスに直接接続しようとします。カードリーダが他のプロセスによって使用されている場合、この接続は失敗します。例えば、pcscd デーモンが OpenSC によって使用されている場合などです。この問題を解決するには、scdaemon と opensc が互いにうまく機能するようにするために、opensc のものと同じドライバを使用する必要があります。scdaemon が pcscd を使用するようにするには、~/.gnupg/scdaemon.conf から reader-port を削除し、libpcsclite.so ライブラリへのパスを指定し、pcscd を確実に使用させるために ccid を無効化する必要があります:

~/.gnupg/scdaemon.conf
pcsc-driver /usr/lib/libpcsclite.so
card-timeout 5
disable-ccid

OpenSC を使用しない場合は、scdaemon(1) を確認してください。

pcscd との共有アクセス

GnuPG scdaemon は、pcscd への接続時に PCSC_SHARE_EXCLUSIVE フラグを使用する唯一の一般的な pcscd クライアントです。電子識別 にリストされているブラウザやプログラムで使用される OpenSC PKCS#11 などの他のクライアントは、単一のスマートカードへの同時アクセスを許可する PCSC_SHARE_SHARED を使用しています。pcscd は、他のクライアントが接続されている間はスマートカードへの排他的アクセスを与えません。これは、GnuPG スマートカード機能を使用するには、開いているブラウザウィンドウをすべて閉じるか、その他の不便な操作を行う必要があることを意味します。バージョン 2.2.28 LTS および 2.3.0 以降では、scdaemon.conf ファイルを変更し、その行末に pcsc-shared を追加することで共有アクセスを有効にできます。

マルチアプレットスマートカード

OpenSC PKCS#11 で YubiKey または他のマルチアプレット USB ドングルを使用すると、OpenSC が Yubikey を OpenPGP から PIV アプレットに切り替えて、scdaemon が壊れるという問題が発生する可能性があります。

OpenSC に OpenPGP アプレットも使用させることで、この問題を回避できます。/etc/opensc.conf ファイルを開き、Yubikey を検索して、driver = "PIV-II"; 行を driver = "openpgp"; に変更します。そのようなエントリがない場合は、pcsc_scan を使用します。リセットするための答えを検索して ATR: 12 34 56 78 90 AB CD ... 次に、新しいエントリを作成します。

/etc/opensc.conf
...
card_atr 12:23:34:45:67:89:ab:cd:... {
    name = "YubiKey Neo";
    driver = "openpgp"
}
...

その後、pkcs11-tool -O --login を使用して、OpenPGP アプレットがデフォルトで選択されていることをテストします。この変更を適用するには、ブラウザなどの他の PKCS#11 クライアントを再起動する必要があります。

SSH 経由でリモートクライアント上のスマートカードを使用する

SSH 経由でマシンにログインし、pcscd 経由で接続されたデバイスを使用しようとすると、次のようなエラーが発生します:

gpg: selecting card failed: No such device
gpg: OpenPGP card not available: No such device

これは、Polkit がローカル クライアントへのアクセスを制限しているためです。これを修正するには、特定のユーザーを許可するルールを追加します。以下のルールにより、wheel グループ内のすべてのユーザーが pcscd 経由でデバイスにアクセスできます:

/etc/polkit-1/rules.d/99-pcscd.rules
polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_card" &&
        subject.isInGroup("wheel")) {
        return polkit.Result.YES;
    }
});
polkit.addRule(function(action, subject) {
    if (action.id == "org.debian.pcsc-lite.access_pcsc" &&
        subject.isInGroup("wheel")) {
        return polkit.Result.YES;
    }
});

ファイルを作成したら、必ず polkit.service再起動 してください。

OpenPGP の互換性

GnuPG は OpenPGP 形式の実装として始まりました。現在、プロジェクトは RFC 4880 に基づいており、RFC 9580 (RFC 4880 に代わる) はサポートしていません。

ただし、バージョン 2.4.0 (2022 年 12 月以降) 以降、GnuPG は IETF プロセスの外でフォーマットへの変更と拡張をロールアウトすることを選択しました (draft-koch-librepgp を参照)

GnuPG 独自の形式 (OpenPGP 標準 から分岐したもの) のほとんどは "バージョン 5" を採用しており (このバージョンは IETF OpenPGP 標準では使用されていません)、非互換性が生じます。

  • GnuPG の "バージョン 5" キーは、異なるフィンガープリントを使用します (SHA-256 を使用しているため、より長くなります)
  • 新しい対称的に暗号化されたデータパケット形式 (OCB Encrypted Data Packet))が追加されました。この形式のサポートは、デフォルトで積極的に有効になっている "機能フラグ" によって通知されます。 #サポートされていない AEAD メカニズムを無効にする を参照してください。
  • 新しい Post-Quantum Cryptography 形式 これも IETF プロセスから分岐したものです ([8])

外部レビューでは、GnuPG による形式拡張の健全性について懸念が生じています ("A Summary of Known Security Issues in LibrePGP" を参照)

GnuPG 固有のフォーマット変更に関する懸念事項のより詳細な議論については、"A Critique on “A Critique on the OpenPGP Updates” を参照してください。

Arch Linux の立場は、OpenPGP 標準との互換性を優先しています。 この目的のために、デフォルトで RFC4880bis を戻す などの gnupg パッケージにパッチが適用されます。 これにより、他の OpenPGP 実装との長期的な互換性が保証され、デフォルトでベンダーロックインが回避されます。

ヒントとテクニック

サポートされていない AEAD メカニズムを無効にする

gnupg 2.4 では、gpg は GnuPG 固有の AEAD 暗号化メカニズム (OCB に基づく) のサポートを通知するキーを生成します。ただし、AEAD のこのフレーバーは、他の OpenPGP 実装ではサポートされていません。

多くのダウンストリームは GnuPG ソースにパッチを適用 してこの新しいデフォルトを削除しようとしますが、--full-gen-key OCB ベースのカスタム AEAD 暗号化メカニズムが新しいキーに設定されています。

GnuPG のカスタム AEAD がキーに設定されているかどうかは、gpg 自体を使用して検査できます:

$ gpg --expert --edit-key <FINGERPRINT>
gpg> showpref
[ultimate] (1). Foobar McFooface (test) <foobar@mcfooface.com>
    Cipher: AES256, AES192, AES, 3DES
    AEAD: OCB
    Digest: SHA512, SHA384, SHA256, SHA224, SHA1
    Compression: ZLIB, BZIP2, ZIP, Uncompressed
    Features: MDC, AEAD, Keyserver no-modify

このメカニズムは次のように無効にできます:

gpg> setpref AES256 AES192 AES SHA512 SHA384 SHA256 SHA224 ZLIB BZIP2 ZIP
Set preference list to:
    Cipher: AES256, AES192, AES, 3DES
    AEAD:
    Digest: SHA512, SHA384, SHA256, SHA224, SHA1
    Compression: ZLIB, BZIP2, ZIP, Uncompressed
    Features: MDC, Keyserver no-modify
Really update the preferences? (y/N) y

他のアルゴリズム

強力なアルゴリズムを使用したい場合:

~/.gnupg/gpg.conf
...

personal-digest-preferences SHA512
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
personal-cipher-preferences TWOFISH CAMELLIA256 AES 3DES

GnuPG の最新版では、デフォルトのアルゴリズムとして SHA256 と AES が使われており、どちらも殆どの場合安全です。しかしながら、2.1 以前の古い GnuPG を使っている場合や、さらに高いセキュリティを求めたい場合、上記のように設定するようにしてください。

パスワードの暗号化

ヒント: pass は以下の作業を自動化します。

パスワードを暗号化すれば、設定ファイルに平文で書き込まれなくなります。メールのパスワードなどが良い例でしょう。

まずパスワードを記述したファイルを作成してください。パスワードの後に空行を一行だけ追加しておく必要があります。そうしないとファイルを評価するときに gpg がエラーメッセージを返します。

そして次を実行:

$ gpg -e -a -r <user-id> your_password_file

-e は encrypt、-a は armor (ASCII 出力)、-r は受取人のユーザー ID です。

新しく your_password_file.asc ファイルが作られます。

信頼モデルの変更

デフォルトでは GnuPG は信頼モデルとして Web of Trust を使います。Web of Trust から Trust on First に変更することが可能です。鍵を追加するときに --trust-model=tofu を追加するか GnuPG の設定ファイルにオプションを追加してください。詳細は GnuPG メーリングリストのメール を参照。

受取人の id を全て隠す

デフォルトでは暗号メッセージには受取人の鍵 ID が含まれます。hidden-recipient <user-id> を使うことで暗号化するときに ID は削除することが可能です。全ての受取人で ID を削除するには設定ファイルに throw-keyids を追加してください。この設定によってメッセージの受取人を隠すことができ、トラフィックの解析に対抗することができます (ソーシャルエンジニアリングを使うことでメッセージを復号化できてしまえば誰が受取人なのか確認される可能性があります)。欠点としては、暗号鍵を全て試すことになるので復号化が遅くなります (--try-secret-key <user-id>)。

キーサインパーティで caff を使う

鍵サーバーやキーリングにある鍵の正当性をユーザーが確認 (つまり鍵の持ち主が本人であることを確認) できるように、PGP/GPG はいわゆる信頼の輪 ("Web of Trust") を利用しています。信頼の輪を維持するために様々なハッカーイベントが開かれており、キーサインパーティはそのひとつです。Zimmermann-Sassaman 鍵署名プロトコルはキーサインパーティを効果的に行うための方式です。こちら にハウツー記事があります。

キーサインパーティの後、鍵に署名したり所有者に署名を送るのを簡略化するために、caff というツールを使うことができます。AUR のパッケージ caff-svnAUR でインストールすることができます。

所有者に署名を送信するには MTA が必要です。MTA を設定していない場合、msmtp をインストールして下さい。

長い ID やフィンガープリントを毎回表示する

長い鍵 ID を表示させるには設定ファイルに keyid-format 0xlong を追加してください。鍵の指紋を完全に表示するには、設定ファイルに with-fingerprint を追加してください。

カスタム機能

鍵にカスタム機能を設定することができます。以下の機能を使うことが可能です:

  • Certify (マスター鍵のみ) - 副鍵の作成ができるようになります。
  • Sign - 公開鍵で検証することができる暗号化署名が作成可能になります。
  • Encrypt - 公開鍵でデータを暗号化して、秘密鍵で復号化することができます。
  • Authenticate - GnuPG 以外のプログラムで鍵を使って認証できます。SSH 鍵として使用することができるようになります。

マスター鍵の機能は以下のコマンドで指定できます:

$ gpg --full-generate-key --expert

オプションを選択して機能を設定することができます。

副鍵にカスタム機能を指定したい場合、gpg --edit-key--expert フラグを追加してください。詳しくは#鍵の編集を参照。

トラブルシューティング

su

pinentry を使う場合、使用するターミナルデバイス (例: /dev/tty1) の適切なパーミッションが必要です。しかしながら、su (または sudo) を使用すると、所有権は元のユーザーに残り、新しいユーザーにはなくなります。これでは pinentry はたとえ root であっても起動しません。pinentry を使用する (つまりエージェントで gpg を使用する) 前にデバイスのパーミッションを同じ所に変更する必要があります。root で gpg を実行する場合、gpg を使用する直前に所有者を root に変更してください:

# chown root /dev/ttyN  # where N is the current tty

そして gpg を使用した後に元に戻して下さい。おそらく /dev/pts/ と同じのが正しいです。

ノート: tty の所有者が pinentry を実行しているユーザーと一致している必要があります。tty グループに属しているだけでは不十分です。
ヒント: script で gpg を実行した場合、新しい tty が適切な所有権で使われます:
# script -q -c "gpg --gen-key" /dev/null

エージェントがファイルの終末についてエラーを表示する

デフォルトの pinentry プログラムは pinentry-gtk-2 であり、D-Bus セッションバスを正しく実行する必要があります。詳しくは一般的なトラブルシューティング#セッションのパーミッションを見て下さい。

もしくは、pinentry-qt を使うこともできます。#pinentry を参照。

KGpg 設定のパーミッション

kgpg には ~/.gnupg/ のオプションが使えないという問題がありました。非推奨となった options ファイルが原因です。バグ レポートを参照してください。

GNOME on Wayland で SSH エージェントのソケットが上書きされる

Wayland のセッションでは、gnome-session によって SSH_AUTH_SOCK が標準の gnome-keyring ソケット $XDG_RUNTIME_DIR/keyring/ssh に設定されます。このため ~/.pam_environmment や systemd のユニットファイルで設定した値が上書きされてしまいます。

この挙動を無効化するには GSM_SKIP_AGENT_WORKAROUND 変数を設定してください:

~/.pam_environment
SSH_AGENT_PID	DEFAULT=
SSH_AUTH_SOCK	DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"
GSM_SKIP_SSH_AGENT_WORKAROUND	DEFAULT="true"

mutt

Mutt は gpg-agent を正しく使用できないため、mutt を使う場合は GPG_AGENT_INFO 環境変数を設定する必要があります (中身は何でもかまいません)。パスワードのキャッシュも有効化してください。

詳しくは フォーラムスレッド を参照してください。

gnupg バージョン 2.1 にアップグレードすると鍵が"消失"する

gpg --list-keys を実行しても以前まで使っていた鍵が表示されない場合、また、アプリケーションが鍵を見つけられないまたは鍵が不正だとエラーを吐く場合、鍵が新しいフォーマットに移行できていない可能性があります。

GnuPG invalid packet workaround を読んで下さい。要約すると、旧式の pubring.gpgsecring.gpg ファイルの鍵にはバグが存在しており、新しい pubring.kbx ファイルと private-keys-v1.d/ サブディレクトリ、そしてディレクトリのファイルによって置き換えられたということが書かれています。以下のコマンドを実行することで消失した鍵を復旧させることができるかもしれません:

$ cd
$ cp -r .gnupg gnupgOLD
$ gpg --export-ownertrust > otrust.txt
$ gpg --import .gnupg/pubring.gpg
$ gpg --import-ownertrust otrust.txt
$ gpg --list-keys

(鍵を受信しようとすると) どの鍵サーバーでも gpg がフリーズする

特定の鍵サーバーで鍵を受信しようとして gpg がフリーズしている場合、dirmngr を kill して (問題が起こっていない) 他の鍵サーバーにアクセスできるようにする必要があります。そうしないと全ての鍵サーバーでフリーズしてしまいます。

スマートカードが検出されない

スマートカードにアクセスするための権限がない場合、カードを正しく設定して接続しても、card error が表示されることがあります。

スマートカードにアクセスする必要があるユーザーに scard を追加することで解決できます。追加したら、以下のような udev ルールを作って下さい:

/etc/udev/rules.d/71-gnupg-ccid.rules
ACTION=="add", SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="1050", ENV{ID_MODEL_ID}=="0116|0111", MODE="660", GROUP="scard"

VENDOR と MODEL は lsusb の出力にあわせて変更する必要があります。上記は YubikeyNEO の例です。

gpg: WARNING: server 'gpg-agent' is older than us (x < y)

gnupg をアップグレードしたのに古い gpg-agent が動作し続けていると警告が表示されます。ユーザーの gpg-agent.socket を再起動してください (再起動するときに --user フラグを使ってください)。

IPC 接続の呼び出しに失敗

killall gpg-agent dirmngr$GNUPGHOME/crls.d/ フォルダの権限が 700 になっていて、gpg-agentdirmngr が起動していないことを確認してください.

デフォルトでは、gnupg パッケージは、ソケットのために /run/user/$UID/gnupg/ ディレクトリを使用します。GnuPG documentation には、このディレクトリが望ましいと書かれています (すべてのファイルシステムがソケットに対応しているわけではありません)。あなたの agent-socket の設定が、適切なファイルシステムを持つパスを指定しているかどうか確認してください。ic|agent-socket}} のパス設定は、 gpgconf --list-dirs agent-socket を実行することで確認することができます。

gpg-agent が正常に起動するか、gpg-agent --daemon でテストしてください。

汚染された PGP 証明書の軽減

2019 年 6 月、未知の攻撃者が数万(または数十万)の署名を持つ複数の高プロファイル PGP 証明書をスパム送信し(CVE-2019-13050)、これらの署名を SKS 鍵サーバーにアップロードしていました。 これらの汚染された証明書がキーリングに存在すると、gpg は以下のメッセージを表示してハングします。

gpg: removing stale lockfile (created by 7055)

この場合、ブログポストにあるように、汚染された証明書を削除することで軽減できる可能性があります。

IPC 応答が無効であり、デバイスの ioctl が不適切

デフォルトの pinentry プログラムは、/usr/bin/pinentry-gtk-2 です。gtk2 が使用できない場合、pinentry は/usr/bin/pinentry-cursesにフォールバックし、署名に失敗します。

gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device

pinentry プログラム /usr/bin/pinentry-tty/usr/bin/pinentry-curses を使用するには、環境変数 GPG_TTY を設定する必要があります。

$ export GPG_TTY=$(tty)

キーブロックのリソースが存在しません

鍵をインポートしようとしたときに、このようなエラーが発生した場合、

gpg: keyblock resource 'gnupg_home/pubring.kbx': No such file or directory

これは GnuPG がホームディレクトリを作成しないためです。単に手動で作成してください。

$ mkdir -m 700 gnupg_home

サブキーが機能制限されて作成される

場合によっては、カスタムの機能セットを使用してサブキーを作成すると、サブキーが "制限付き" としてマークされることがあります。これは、対話型プロンプトで機能が切り替わるときに、オプション 7 または 8 ("set your own capabilities") を指定した addkey コマンドで発生します。回避策は、機能の選択を求められたときに、個々の機能を切り替えるのではなく、目的の機能セットを文字列として直接入力することです。たとえば、認証機能のみを持つサブキーを作成するには、"=A" と入力します。

参照