Phil's Pretty Good Softwareが提供するソフトウェア

PGP (tm)

◇Pretty Good(tm) Privacy
一般の人を対象とした公開鍵暗号化方式

◇PGP(tm) ユーザーズガイド
第 2 巻: 特殊事項
作成者: Philip Zimmermann   改定日: 1994 年 10 月 11 日

PGP バージョン 2.6.2 1994 年 10 月 11 日
ソフトウェア作成者
Philip Zimmermann ほか

概要:
PGP(tm) は、公開鍵を暗号化することによって E メールやデータファイルを保護するためのソフトウェアです。このプログラムを使うと、知らない相手との通信を安全に行うことができます。セキュリティ保護された通信路を使って、前もって鍵の交換を行っておく必要もありません。PGP は高い機能性と高速性を備えたプログラムです。高度な鍵管理機能、デジタル署名機能、データ圧縮機能が備わっているだけでなく、使い勝手のよい優れた製品です。

ソフトウェアとマニュアルの著作権(1990-1994)は、Phillip Zimmermann に帰属します。無断転載を禁じます。PGP のライセンス許諾、配布、著作権、特許、商標、免責事項、輸出規制については、「法律に関連する事項」のセクションを参照してください。配布元は、マサチューセッツ工科大学です。



==================
目次
==================
・PGP の概要
・特殊事項
・鍵 ID を使って鍵を選択する
・メッセージから署名を切り離す
・メッセージの復号時に署名をそのまま残す
・異なるマシン環境間で ASCII テキストファイルを送受信する
・PGP を高機能な Uuencode として利用する
・ディスクに平文の痕跡を残さないようにする
・復号化した平文を画面に表示する
・メッセージを画面上だけで確認できるようにする
・平文ファイルの元の名前を残しておく
・ユーザー ID、パスフレーズの変更
・公開鍵の信用パラメータの変更
・公開鍵のキーホルダーに問題がないかどうかを確認する
・電話で公開鍵の確認を行う
・サイズの大きい公開鍵キーホルダーの処理
・PGP を UNIX 方式のフィルターとして利用する
・無駄な質問が表示されないようにする: BATCHMODE
・確認メッセージに対して「Yes」と回答する: FORCE
・PGP がシェルに返す終了ステータス
・パスフレーズの環境変数
・PGP 設定ファイルのパラメータを設定する
・TMP - 一時ファイル用のディレクトリのパス名
・LANGUAGE - 言語の選択
・MYNAME - 署名作成時のデフォルトのユーザー ID
・TEXTMODE - 平文をテキストファイルであるとみなす
・CHARSET - テキストファイルで使うローカル文字セットの指定
・ARMOR - ASCII 保護出力を有効にする
・ARMORLINES - ASCII 保護分割ファイルのサイズ
・KEEPBINARY - 復号化処理後にバイナリ形式の暗号文ファイルを保存する
・COMPRESS - 圧縮処理を有効にする
・COMPLETES_NEEDED - 完全に信用できる仲介者の最小数
・MARGINALS_NEEDED - まずまず信用できる仲介者の最小数
・CERT_DEPTH - 仲介者の入れ子の深さ
・BAKRING - 秘密鍵のキーホルダーのバックアップファイル名
・PUBRING - 公開鍵のキーホルダーのファイル名
・SECRING - 秘密鍵のファイル名
・RANDSEED - 乱数シードのファイル名
・PAGER - 平文出力を表示するためのシェルコマンドの指定
・SHOWPASS - パスフレーズを表示する
・TZFIX - タイムゾーンの調整
・CLEARSIG - 署名付きメッセージをクリアテキストとしてカプセル化する
・VERBOSE - メッセージのモードを指定
・INTERACTIVE - 鍵登録時の確認
・NOMANUAL - マニュアルがなくても鍵の生成を可能にする
・内部機構
・乱数
・PGP で使われている従来の暗号化アルゴリズム
・データの圧縮
・メッセージダイジェストとデジタル署名
・PGP の古いバージョンと新しいバージョンとの間の互換性
・弱点
・パスフレーズと秘密鍵の安全性に問題がある場合
・公開鍵の改ざん
・ファイルは本当は削除されていない
・ウィルスとトロイの木馬
・物理的なセキュリティ侵害
・テンペスト攻撃
・マルチユーザーシステムにおける漏洩
・トラフィック分析
 タイムスタンプの偽造を防止する
 暗号解読
・法律に関連する事項
 商標、著作権、保証
 アルゴリズムに対する特許権
 フリーウェアの状況と制限事項
 PGP を商業目的で利用する場合の制限事項
 ライセンス許諾に関するその他の制限事項
 配布
 輸出規制
 Philip Zimmermann が置かれている法的な状況
・PGP に関するその他の情報源
商用版 PGP の入手場所
PGP のバグを報告する
ファンレター、バージョンアップ、最新情報
コンピュータ関連の政治グループ
推奨文献
原稿作成者の連絡先
付録 A: PGP の入手先


==================
PGP の概要
==================

Philユs Pretty Good Software の PGP (Pretty Good(tm) Privacy) は、MS/DOS、UNIX、VAX/VMS などに対応した高セキュリティの暗号化ソフトウェアアプリケーションです。PGP は、RSA (Rivest-Shamir-Adleman) 方式の公開鍵暗号化システムの利便性と従来の暗号技術の高速性を兼ね備えたソフトウェアであり、メッセージダイジェストによる署名、圧縮データの暗号化、使い勝手のよい設計、優れた鍵管理機能といった特長を備えています。

『PGP ユーザーズガイド』の第 2 巻では、『PGP ユーザーズガイド、第 1 巻: 基本事項』では取り上げられていなかった高度な内容について説明します。まず、基本事項編を読んでおいてください。基本事項編を読んでいないユーザーがこのマニュアルを読んでもあまり意味がありません。特殊事項編を読むかどうかはユーザーの自由ですが、「法律に関する事項」のセクションだけはすべてのユーザーが読んでおいたほうがよいでしょう。


==================
特殊事項
==================


鍵 ID を使って鍵を選択する
-------------------------

ユーザー ID やその一部を入力して鍵を選択するようなコマンドでは、ユーザ ID の代わりに 16 進数の鍵 ID を指定できます。ユーザー ID を指定する代わりに、鍵 ID の先頭に 0x というプリフィクスを付加して入力します。以下に例を示します。

pgp -kv 0x67F7

このコマンドを実行すると、鍵 ID に 67F7 が含まれている鍵がすべて表示されます。

この機能は、ユーザー ID が同一である 2 種類の鍵を同じ人から受け取っている場合に利用すると特に便利です。鍵 ID を指定することによって、目的の鍵を明確に選ぶことができるからです。

メッセージから署名を切り離す
-----------------------------------

署名証明書は通常、署名されたテキストに物理的に添付しておきます。こうしておくと、簡単なケースでは署名を簡単に確認できます。しかし、署名対象となるメッセージとは別に署名証明書を保存したほうが望ましい場合もあります。署名証明書は、署名対象となるテキストから切り離して作成することができます。このような署名を作成するには、b (break) オプションと s (sign) オプションを組み合わせて使います。以下に例を示します。

pgp -sb letter.txt

この例では、letter.sig という名前のファイル内に、独立した署名証明書が作成されます。letter.txt の内容は、署名証明書には付加されません。

作成した署名証明書ファイル(上記の例では、letter.sig)は、元のテキストファイルと一緒に受信者に送信します。受信者は、両方のファイルを持っていないと署名の正当性を確認することができません。受信者が署名ファイルを処理しようとすると、PGP は署名が付けられているファイル内にメッセージが記述されていないことを認識し、メッセージが記述されているファイルの名前を指定するように指示します。ファイル名を指定しないかぎり、署名の正当性を確認することはできません。署名がテキストファイルから切り離されていることを受信者があらかじめ知っている場合は、コマンドラインで両方のファイル名を指定することができます。以下に例を示します。

pgp letter.sig letter.txt
または pgp letter letter.txt

この場合、PGP はテキストファイルの名前を指定するように指示しません。

独立した署名証明書は、署名証明書を別の証明書ログに保存しておきたい場合に使うと便利です。実行可能なプログラムの場合も、分離署名を利用するとウィルスの二次感染を検出できるので便利です。適法の契約など、1 つの文書に複数の組織が署名する必要がある場合にも便利です(署名が入れ子状態になりません)。それぞれの署名は独立しています。


メッセージに署名証明書が添付されている暗号文ファイルを受け取った場合でも、復号化処理の実行時に署名証明書を切り離すことができます。復号化処理時に署名証明書を切り離すには、以下のように -b オプションを使います。

pgp -b letter

letter.pgp の復号化処理時にファイル内に署名が存在すると、署名の確認とメッセージからの切り離しが行われ、letter.sig ファイルに保存されます。


メッセージの復号時に署名をそのまま残す
------------------------------------------------------

通常、暗号文ファイルは完全に復元します。暗号文を解読したあと、入れ子状態になった署名が存在する場合はそれを確認し、さまざまな膜を剥がして元の平文ファイルを得る必要があるからです。

しかし、暗号化されたファイルを復号化する際にファイルに添付された署名をそのまま残し、署名付きメッセージとして復号化したい場合もあります。このような処理は、署名付き文書のコピーを(再暗号化するなどして)第三者に送りたい場合に便利な場合があります。たとえば、チャーリーの署名がつけられたメッセージを受け取ったとします。そのメッセージはあなたを対象に暗号化されています。そして、チャーリーの署名を残したままこのメッセージを復号化し、(アリスの公開鍵を使って再度暗号化するなどして)アリスに送りたいとします。大丈夫です。PGP には、このような処理を行う機能が備わっています。

メッセージを復号化する際にそのメッセージに付けられている署名をそのまま残すには、以下のように入力します。

pgp -d letter

このコマンドを実行すると、署名が格納されている場合は、letter.pgp の復号化処理時に署名がそのまま残され、出力ファイルに平文として出力されます。

このファイルは保存しておいたり、再度暗号化してほかの人に送ったりできます。



異なるマシン環境間で ASCII テキストファイルを送受信する
--------------------------------------------------------------

PGP では、8 ビットのバイナリデータや ASCII テキストなど、どのような平文ファイルでも暗号化できます。PGP の最も一般的な使い方は、平文が ASCII 文字で書かれている E メールを処理することでしょう。

ASCII 文字の表示は、マシンによって異なる場合があります。たとえば、MS/DOS システムでは、ASCII 文字のすべての行は復帰で終わり、最後に改行が挿入されます。UNIX システムでは、すべての行が改行だけで終わります。Mac の場合は、すべての行が復帰だけで終わります。残念なことですが、これが現実です。

一般的に、ACCII 文字で書かれている暗号化されていない普通のメッセージは、別のマシンに転送される際に一般的な「標準」形式に自動的に変換されます。標準テキストでは、各行の最後に復帰文字と改行が挿入されます。たとえば、広く普及している KERMIT 通信プロトコルでは、別のシステムに転送するときにテキストを標準形式に変換することができます。テキストは受信側の KERMIT によって、ローカルマシンのテキスト行の終止記号に戻されるので、さまざまなシステム間で容易にテキストファイルを共有することができます。

しかし、暗号化されているテキストは通信プロトコルによって自動的に変換されることはありません。暗号によって平文が見えなくなっているからです。このような問題に対処するために、PGP では平文をバイナリデータではなく ASCII テキストとして処理し、暗号化を行う前に標準テキスト形式に変換するように指定することができます。復号化された平文は、そのマシンの環境に適した形式に受信側で自動的に戻されます。

平文を標準形式のテキストに変換してから暗号化を行わせるには、メッセージを暗号化したり署名を付けたりするときに、t オプションを指定します。

pgp -et message.txt her_userid

平文ファイルにテキスト形式ではないバイナリデータが格納されていると PGP が判断した場合、このモードは自動的に無効になります。

-t オプションを頻繁に使う必要がある場合は、PGP 設定ファイルの TEXTMODE フラグを有効にするという方法があります。私は、この方法を使っています。

PGP で英語以外の 8 ビットの文字セットを使っている場合は、PGP 設定ファイルの CHARSET パラメータの設定によっては、テキストが標準形式に変換されるときに、データがローカルの文字セットから LATIN1 (ISO 8859-1 Latin Alphabet 1) に変換される場合があります。LATIN1 は ASCII のスーパーセットであり、さまざまなヨーロッパ言語に対応した特殊な文字を ASCII 文字セットに追加したものです。



PGP を高機能な Uuencode として利用する
------------------------------

UNIX ユーザーの間では、バイナリデータファイルを E メールで送信する際に、UNIX の uuencode ユーティリティを使って、ファイルを表示可能な ASCII 文字(E メールで送信可能な形式)に変換するといった方法が広く使われています。暗号化処理が行われないため、送信者も受信者も特別な鍵を持っている必要がありません。uuencode は、「E メールで暗号文を送信する - radix-64 フォーマット」のセクションで説明した PGP の radix-64 ASCII 伝送保護フォーマットとよく似た用途で使うユーティリティですが、機能面においては radix-64 フォーマットよりも劣ります。uuencode では、別の radix-64 文字セットが使われます。Uuencode には、特有の問題があります。具体的には、1) MS/DOS 環境や UNIX 環境で、uuencode のバージョンが異なると、互換性が完全ではない文字セットがいくつか存在すること、そして 2) 一部の E メールゲートウェイ(最後のブランクを削除するなど、uuencode で使われている文字セットに変更を加えるようなゲートウェイ)でデータが破壊されてしまう場合があることです。

PGP は、uuencode で実行できるような一般的な機能を実行するために使うこともできますが、それ以上の機能を実行することもできます。PGP を使ってファイルを PGP の radix-64 ASCII 伝送保護フォーマットに変換するだけであれば、ファイルを暗号化したり署名を付加したりする必要がないので、送信側も受信側も鍵を使う必要はありません。
このような場合は、-a オプションだけを指定します。以下に例を示します。

pgp -a filename

このコマンドを実行すると、radix-64 で保護された filename.asc という名前のファイルが作成されます。

「E メールで暗号文を送信する - radix-64 フォーマット」のセクションを読むと、PGP で使われている方法には、以下に示すようなさまざまな重要なメリットがあり、uuencode で使われている方法よりも優れていることがわかると思います。

* サイズの大きなファイルは、E メールで送信可能な小さなファイルに分割される
* 分割されたファイルに、CRC エラー検出コードが付加される
* データを圧縮してから、radix-64 保護フォーマットに変換される
* PGP の radix-64 文字セットは、uuencode で使われる文字セットに比べて、E メール文字への変換時の柔軟性が高い
* 「異なるマシン環境間で ASCII テキストファイルを送受信する」のセクションで説明したように、送信者がテキストファイルを標準テキストフォーマットに変換できる。

受信者が送信者の元のファイル名を復元するには、PGP の -p オプションを使ってメッセージを開封します。受信者も PGP を使っている場合は、uuencode を使うことができる状況であればどのような場合でも pgp -a を使うことができます。PGP は、uuencode よりも優れた uuencode であると言えます。



ディスクに平文の痕跡を残さないようにする
------------------------------------------

暗号文ファイルが自動作成されたら、平文ファイルの上書きと削除を PGP に自動実行させることによって、平文ファイルの痕跡をディスクに残さないようにすることができます。この処理を行うと、ディスクブロック走査ユーティリティを使ってもファイルを復元することができなくなります。平文ファイルに、残しておきたくないような重要な情報が記載されている場合にこの機能を使うと便利です。

暗号文ファイルの作成後に平文ファイルを消去するには、メッセージを暗号化したりメッセージに署名したりする際に -w (wipe) オプションを指定します。以下に例を示します。

pgp -esw message.txt her_userid

この例では、message.pgp という暗号文ファイルが作成され、message.txt という平文ファイルが復元不可能な状態に破壊されます。

このオプションを使う場合は注意する必要があることは言うまでもありません。また、PGP を実行する前にワードプロセッサを使ってメッセージを編集した場合は、ディスクに残っているその平文は一切消去されませんので注意してください。一般的なワードプロセッサでは、バックアップファイルやスクラッチファイルが作成されます。これらの両方が作成されるものもあります。また、ファイルの上書きは一度しか行われません。従来のディスク復元行為を阻止するにはこれで十分ですが、特殊なディスク復元ハードウェアを使って、わずかな磁気の痕跡を復元するような必死かつ高度な復元行為に対しては十分であるとは言えません。



復号化した平文を画面に表示する
---------------------------------------------

復号化した平文出力をファイルに書き込まずに画面に表示するには、(UNIX の more コマンドと同様)復号化を行うときに -m (more) オプションを指定します。

pgp -m ciphertextfile

このコマンドを実行すると、復号化された平文が一画面ずつ表示されます。



メッセージを画面上だけで確認できるようにする
----------------------------------

受信者が復号化した平文は画面上だけで確認できるようにし、ディスクに保存できないようにするには、-m オプションを指定します。以下に例を示します。

pgp -sem message.txt her_userid

受信者が自分の秘密鍵とパスフレーズを使って暗号文を復号化しても、平文は画面に表示されるだけで、ディスクには保存されません。テキストは、UNIX の more コマンドを使ったときと同じように、一画面ずつ表示されます。メッセージをもう一度読みたい場合は、暗号文を再度復号化する必要があります。

この機能は、重要なメッセージが不用意に受信者のディスクに残されることを防止するには最も安全な方法です。この機能は、あるユーザーの要求によって搭載されたものです。そのユーザーは恋人に親密なメッセージを送りたいと考えていましたが、復号化したメッセージが間違って彼女の夫のコンピュータに残されたままになってしまうことを心配していました。

この機能を使っても、頭がよい人がその気になれば復号化した平文をディスクに保存する方法を見つけ出すことができます。普通のユーザーが平文をディスクに不用意に保存することを防ぐための機能です。ご注意ください。



平文ファイルの元の名前を残しておく
------------------------------------------

通常は、復号化した平文の出力ファイルには、入力元の暗号文ファイルの名前と似た名前が付けられます。異なる点は、拡張子が削除されるということだけです。ファイル名に関するこの規則を無効にするには、コマンドラインで出力平文ファイルの名前を指定するときに、-o オプションを指定します。一般的な E メールの場合、このような方法を使って平文ファイルに名前を付けることは適切であると言えます。メッセージを復号化するときにファイル名を決定する必要がありますが、一般的な E メールの生成元の平文ファイルには、to_phil.txt といった無意味な名前が付けられていることが多いからです。

しかし、PGP で平文ファイルの暗号化を行うときは、必ず元のファイル名が保存されて平文に添付されたあとで、平文の圧縮と暗号化が行われます。PGP では通常、この隠された元のファイルの名前は破棄されますが、元の平文ファイルの名前を保持して、復号化した平文の出力ファイルの名前として使用するように指示することもできます。この機能は、名前を保持しておくことが重要なファイルを処理する場合に使うと便利です。

復号化処理中に、元の平文ファイルの名前を復元するには、-p オプションを指定します。以下に例を示します。

pgp -p ciphertextfile

私はこのオプションを通常は使っていません。このオプションを使うと、復号化した受信メールの半分ほどが、to_phil.txt や prz.txt といったような同じ名前の平文ファイルになってしまうからです。



ユーザー ID、パスフレーズの変更
-----------------------------------

パスフレーズは、入力中に他人に覗かれた場合など、変更する必要性が生じる場合があります。

また、結婚したために名前が変わった場合や、E メールアドレスを変更した場合も、ユーザー ID を変更する必要があるでしょう。複数の名前、E メールアドレス、役職を使っている場合は、鍵に対して 2 つまたは 3 つのユーザー ID を設定する必要があるかもしれません。PGP では、鍵に対して複数のユーザー ID を設定することができます。どのユーザー ID を使ってもキーホルダーに登録されている鍵を検索することができます。

秘密鍵のユーザー ID やパスフレーズを変更するには、以下のように入力します。

pgp -ke userid [keyring]

新しいユーザー名または新しいパスフレーズを入力するように指示されます。

ユーザー ID を編集すると、新しいユーザー ID が実際に登録されます。このとき、既存のユーザーは削除されません。既存のユーザー ID を削除したい場合は、別の操作を実行する必要があります。

オプションの [キーホルダー] パラメータを指定する場合は、秘密鍵のキーホルダーではなく、公開鍵のキーホルダーを指定してください。
userid には、自分のユーザー ID を指定します。公開鍵のキーホルダーと秘密鍵のキーホルダーの両方に表示されるので、PGP がそのユーザーのユーザー ID であることを認識できるものを指定します。
公開鍵のキーホルダーだけを指定した場合でも、両方のキーホルダーが更新されます。

実行対象が公開鍵であるかそれとも秘密鍵であるかによって、-ke コマンドの働きは異なります。-ke コマンドは、公開鍵の信用パラメータを変更するときにも利用できます。


公開鍵の信用パラメータの変更
---------------------------------------------

公開鍵のキーホルダーに保存されている公開鍵の信用パラメータを変更する必要性が生じる場合もあります。信用パラメータを設定することの意味については、『PGP ユーザーズガイド』の基本事項編、「PGP における有効な鍵の管理方法」のセクションを参照してください。

公開鍵の信用パラメータを変更するには、以下のように入力します。

pgp -ke userid [keyring]

オプションの [キーホルダー] パラメータを指定する場合は、秘密鍵のキーホルダーではなく、公開鍵のキーホルダーを指定してください。



公開鍵のキーホルダーに問題がないかどうかを確認する
----------------------------------------------------

公開鍵のキーホルダーに新しい鍵や署名が登録されると、通常は鍵と署名のチェック、信用パラメータと妥当性スコアの更新が自動的に行われます。理論上は、公開鍵のキーホルダーに対して情報の追加や削除が行われるたびに、すべての鍵の正当性ステータス情報が更新されます。しかし、公開鍵のキーホルダーの総合的な分析、すべての認証署名のチェック、信用パラメータのチェック、正当性スコアの更新、書き込みを禁止したフロッピーディスクに保存されているバックアップコピーと最大限に信用できる鍵との照合確認を PGP に明示提的に強制実行させることをお奨めします。このようなクリーンアップ保守を定期的に行って、公開鍵に異常がないことを確認するとよいでしょう。公開鍵のキーホルダーに対する総合分析を強制的に実行するには、以下のように -kc (key ring check) コマンドを実行します。

pgp -kc

特定の 1 つの公開鍵を対象にすべての署名をチェックすることもできます。以下に入力例を示します。

pgp -kc userid [keyring]

自分の鍵のバックアップコピーをチェックする方法の詳細につては、このマニュアルの「設定ファイルの BAKRING パラメータ」のセクションを参照してください。



電話で公開鍵の確認を行う
-------------------------------------

信用できる人によって認証されていない人から公開鍵を受け取った場合は、その鍵が本当にその人のものであるかどうかは判断できません。認証されていない鍵の正当性を確認するには、対象となる鍵を受け取った通信路以外の独立した通信路を使って鍵の正当性を確認するのが最もよい方法です。簡単な方法を 1 つ挙げておきます。それは、対象となる人を知っていて、その人であることが電話で認識できる場合は、その人に電話をして対象となる鍵の正当性を確認するという方法です。電話で、長い(ASCII 保護された)鍵全体を読む必要はありません。鍵の「フィンガープリント」を読むだけでかまいません。フィンガープリントを確認するには、-kvc コマンドを実行します。具体的には以下のように入力します。

pgp -kvc userid [keyring]

このコマンドを実行すると、鍵および公開鍵の構成要素の 16 バイトのダイジェストが表示されます。鍵の所有者に対して、この 16 バイトのフィンガープリントを電話で読み上げます。鍵の所有者は、鍵に対して同じように -kvc コマンドを実行して、フィンガープリントを照合します。

この方法を使ってお互いの鍵の正当性を確認すれば、確信を持ってお互いの鍵に署名できるようになります。これは、サークル仲間の鍵の信用ネットワークを構築するには、安全で簡単な方法です。

E メールで鍵のフィンガープリントを送ることによって鍵の正当性を確認するのは最善の方法ではありません。E メールは傍受されたたり変更が加えられたりする可能性があるからです。鍵を送るのに使った通信路以外の通信路を使うのが最善の方法です。鍵は E メールで送り、鍵のフィンガープリントは電話で確認するのがもっともよい方法です。鍵のフィンガープリントを名刺に印刷している人もいます。これは本当におしゃれな感じがします。

PGP の現行バージョンでは、鍵のフィンガープリントは MD5 ハッシュ関数を使って算出されます。将来のバージョンでは、MD5 以外の新しい別のハッシュ関数をオプションで使用できるようにするつもりです。

私のことを知らない人は、私に電話をして鍵の正当性を確認しないでください。そのような電話をかけてくる人があとを絶ちません。私の公開鍵のコピーはすべての PGP ユーザーが持っており、配布されているコピーのすべてを改ざんすることは不可能です。複数のソースを使って鍵をチェックする人がいれば、その人が不一致に気付くので、インターネット上で直ちにその情報が公開されます。

PGP の標準リリースパッケージに付属している私の公開鍵の正当性を確認したい人のために、以下に詳細情報を示しておきます。

ユーザー ID: Philip R. Zimmermann <prz@acm.org>
鍵のサイズ:1024 ビット、 作成日: 1993 年 5 月 21 日、 鍵 ID: C7A966DD
鍵のフィンガープリント: 9E 94 45 13 39 83 5F 70 7B E7 D8 ED C4 BE 5A A6

『PGP ユーザーズガイド』は電子的な方法によって配布されているため、上記の情報が改ざんされている可能性も否定できません。しかし、本マニュアルの書籍版(MIT Press 発行、書店にて入手可)には、私の鍵の正しいフィンガープリントが間違いなく記載されています。


サイズの大きい公開鍵キーホルダーの処理
------------------------------

PGP は本来、サイズの小さい個人用のキーホルダーを処理して、個人用のアドレス帳のような感覚でキーホルダーに友人を登録しておくことを前提に作成されたものです。このようなキーホルダーに適した鍵の数は数百です。しかし、PGP が普及するにつれて、自分のキーホルダーにサイズの大きい別のキーホルダーを保存しようとする傾向が見られるようになりました。キーホルダーに数千の鍵を保存するような場合もあります。PGP は、現在の形態では、このような処理を適切な時間内に実行することはできないので、ユーザーはキーボードを前に待たされることになります。サイズの大きなキーホルダーを処理することには適していません。

サイズの大きなキーホルダーに必要な鍵が数十個登録されているといった理由で、巨大なキーホルダーをインポートして自分のキーホルダーに保存したい場合があるかもしれません。ほかのキーホルダーから利用したい鍵の数が数個であれば、必要な鍵を外部の大きなキーホルダーから取り出して、自分のキーホルダーに登録するほうが効率的です。外部のキーホルダーから鍵を取り出すには、-kx コマンドを利用します。コマンドラインで対象となるキーホルダー名を指定します。鍵を取り出したら、自分のキーホルダーに登録します。

本当の解決策は、PGP の機能を向上することによって、高度なデータベース技術を利用してサイズの大きいキーホルダーを効率的に管理できるようにすることです。現在、このような機能の向上に取り組んでおり、間もなく実現するはずです。この機能が搭載されるまでは、サイズの小さいキーホルダーを使っていただく必要があります。ご理解いただきたいと思います。



PGP をUNIX 方式のフィルターとして利用する
--------------------------------

UNIX の愛好者の間では、UNIX の「パイプ」を使って 2 つのアプリケーションを連動させることが一般的に行われています。1 つのアプリケーションの出力は、パイプを経由して直接送り込み、別のアプリケーションに対する入力として読み込むことができます。これが機能するためには、「標準入力」から生データを読み込んだり、完了した出力を「標準出力」に書き込んだりする能力がアプリケーションに備わっている必要があります。PGP は、このモードで動作させることができます。この説明の意味が理解できないユーザーには、このような機能は必要ないと思われます。

UNIX 風のフィルターモードを使って、標準入力からの読み込みおよび標準出力への書き込みを行うには、-f オプションを指定します。以下に例を示します。

pgp -feast her_userid <inputfile >outputfile

この機能を利用すると、PGP と電子メールアプリケーションを簡単に連携させることができます。

PGP をフィルターモードで使って暗号文ファイルを復号化する場合は、PGPPASS 環境変数を利用してパスフレーズを保持しておくと、パスフレーズの入力を求められなくなるので便利です。PGPPASS の機能については、このあと説明します。


不要な質問が表示されないようにする: BATCHMODE
----------------------------------------------

コマンドラインで BATCHMODE フラグを有効にすると、不要な質問が表示されたり、代替ファイル名の指定を求められたりしなくなります。以下に、フラグの設定例を示します。

pgp +batchmode cipherfile

これは、UNIX のシェルスクリプトや MS/DOS のバッチファイルを使って、PGP を非インタラクティブ形式で実行する場合に便利です。鍵管理に関連するコマンドの中には、BATCHMODE を有効にしてもユーザーの介入が必要なものもあるため、シェルスクリプトによってそれを回避する必要がある場合があります。

BATCHMODE を有効にすると、ファイルに付けられた署名の正当性をチェックすることもできます。ファイルに署名が付けられていない場合の終了コードは 1 になり、ファイルに正当な署名が付けられている場合の終了コードは 0 になります。


確認メッセージに対して「Yes」と回答する: FORCE
----------------------------------------------------

このコマンドラインフラグを指定すると、既存のファイルを上書きするかどうかという確認メッセージに対して、ユーザーが「yes」と応答するとみなされます。また、-kr コマンドを使ってキーホルダーから鍵を削除するときも、ユーザーの応答が「yes」であるとみなされます。以下に、フラグの設定例を示します。

pgp +force cipherfile
または
pgp -kr +force Smith

この機能は、UNIX のシェルスクリプトや MS/DOS のバッチファイルを使って、PGP を非インタラクティブ形式で実行する場合に便利です。



PGP がシェルに返す終了ステータス
------------------------------------

MS/DOS の .bat ファイルや UNIX のシェルスクリプトなどから、PGP を「バッチ」モードで簡単に実行できるようにするために、PGP はエラー終了ステータスをシェルに返します。終了ステータスコードが 0 の場合は正常に終了したことを表し、0 以外の値の場合は何らかのエラーが発生したことを表しています。シェルに返される終了ステータスコードは、エラー終了状態ごとに異なります。



パスフレーズの環境変数
--------------------------------------

通常、PGP が秘密鍵を開ける際にパスフレーズが必要な場合は、必ずパスワードを入力するように要求されます。ただし、OS のコマンドシェルを使って、パスフレーズを環境変数に保存しておくこともできます。PGPPASS 環境変数を利用してパスフレーズを保持しておくと、このパスフレーズが最初に使われるようになります。PGPPASS に保存されているパスフレーズが間違っている場合、PGP は正しいパスフレーズを入力するようにユーザーに要求して、復号化を行います。

たとえば、MS/DOS で

SET PGPPASS=zaphod beeblebrox for president

というシェルコマンドを入力すると、パスフレーズが実際に「zaphod beeblebrox for president」であった場合には、パスフレーズの入力を要求するプロンプトは表示されなくなります。

自分の秘密鍵に宛てられた受信メッセージを大量かつ頻繁に処理する必要がある場合は、この危険な機能を使うと PGP を実行するたびにパスフレーズを何度も入力する必要がなくなるので、非常に便利です。

この機能を搭載した理由は、このような機能に対する要求が多かったからです。ただし、貴重なパスフレーズが頭の中以外の場所に保存されるため、これは危険な機能であると言えます。もっと悪いケースでは、秘密鍵が保存されているコンピュータのディスクにパスフレーズを保存しているような非常に無頓着な人もいます。MS/DOS の AUTOEXEC.BAT ファイルなどのバッチファイルやスクリプトファイルにこのコマンドをインストールすることは、特に危険でおろかな行為です。昼休みに、秘密鍵とパスフレーズが保存されているファイルの両方を誰かに盗まれてしまうかも知れません。

このような危険に関する重大性については、いくら強調しても足らないくらいです。この機能を使おうと思っている場合は、『PGP ユーザーズガイド』の本編と基本事項編の「マルチユーザーシステムにおける漏洩」のセクションと「秘密鍵の漏洩を防止する方法」のセクションを必ず読んでください。

この機能を使う必要がある場合は、マシンの起動時に毎回シェルコマンドに手動で入力することによって PGPPASS を設定してから PGP を使い、作業が終了したら PGPASS を消去するかマシンを停止するのが最も安全な方法です。また、ほかの人が自分のマシンにアクセスできるような環境では、絶対にこのような操作をしないようにしてください。ほかの人が、PGPPASS の設定内容を表示するような操作を行うかもしれません。

E メールパッケージなどのほかのアプリケーションからパスフレーズを PGP に渡したい場合もあります。このような目的で PGPPASS 変数を使うことは、必ずしも望ましくない場合もあります。ほかのアプリケーションから PGP にパスフレーズを渡す方法はほかにもあります。それは、コマンドラインで -z オプションを使う方法です。このオプションは、E メールパッケージ内から PGP を呼び出すためのものです。パスフレーズは、コマンドラインの -z オプションのあとに記述します。この方法には、上述の PGPPASS 変数を使う場合とよく似た危険が伴います。


=================================
PGP 設定ファイルのパラメータを設定する
=================================

PGP には、ユーザーが設定できるパラメータが数多くあります。このようなパラメータは、config.txt という名前の特殊な PGP 設定テキストファイルで設定します。config.txt ファイルは、シェル環境変数 PGPPATH によって示されるディレクトリに格納されています。設定ファイルを作成すると、PGP のさまざまなフラグやパラメータをユーザーが設定できるので、PGP のコマンドラインで毎回パラメータを設定する手間が省けます。

PGP では、config.txt というファイル名がずっと使われていますが、特定の OS における設定ファイルの名前のつけ方と競合するのではないかという指摘が何人かの人からありました。現行の PGP では、この問題に対応するために、config.txt の検索対象となるディレクトリ内に .pgprc ファイルが存在する場合はこのファイルがまず開かれ(UNIX プラットフォームの場合)、pgp.ini が存在する場合はこのファイルが開かれます(UNIX 以外のプラットフォームの場合)。どちらのファイルも存在しない場合にはじめて config.txt が開かれます。

設定パラメータに指定できる値は、整数値、文字列、オン・オフです。どのような値を指定するかは、設定パラメータの性質によって異なります。PGP には、設定ファイルのサンプルが付属しているので、設定例を参考にしてください。

設定ファイルでは、コメント文字(#)のあとの記述と同様、空白行は無視されます。予約語では、大文字と小文字は区別されません。

以下に、設定ファイルにおける一般的な設定例の一部を示します。

# TMP is the directory for PGP scratch files, such as a RAM disk.
TMP = "e:\" # Can be overridden by environment variable TMP.
Armor = on # Use -a flag for ASCII armor whenever applicable.
# CERT_DEPTH is how deeply introducers may introduce introducers.
cert_depth = 3

設定ファイルで一部の設定パラメータが設定されていない場合、設定ファイルがない場合、または設定ファイルが見つからない場合は、設定パラメータはデフォルトの適当な値に設定されます。

なお、これらの設定パラメータは、PGP コマンドラインから直接設定することもできます。コマンドラインから設定するときは、パラメータ設定値の前に + 記号を記述します。たとえば、以下の 2 つのコマンドの実行結果は同じになります。

pgp -e +armor=on message.txt smith
  pgp -ea message.txt smith


以下に、設定ファイルで設定できる各種パラメータの概要を示します。


TMP - 一時ファイル用のディレクトリのパス名
--------------------------------------------

デフォルトの設定: TMP = ""

TMP は、PGP の一時スクラッチファイルを保存するディレクトリを設定するための設定パラメータです。RAM ディスクがある場合は、RAM ディスクにスクラッチファイルを保存するのがいちばんよいでしょう。高速に処理できるだけでなく、セキュリティも多少高くなります。TMP が設定されていない場合、一時ファイルはカレントディレクトリに保存されます。シェル環境変数 TMP が設定されている場合は、この変数を使って一時ファイルの保存ディレクトリが指定されます。


LANGUAGE - 言語の選択
------------------------------------

デフォルトの設定: LANGUAGE = "en"

PGP では、さまざまなプロンプト、警告メッセージ、アドバイスが画面に表示されます。たとえば、「ファイルが見つかりません」や「パスフレーズを入力してください」といったメッセージです。通常、このようなメッセージは英語で表示されますが、ほかの言語で表示することもできます。表示言語の変更は、PGP 実行プログラムに変更を加えなくても行うことができます。

各国のさまざまな人たちによって、PGP で表示されるメッセージ、警告、プロンプトがその国の言語に翻訳されています。このようなメッセージの翻訳は、PGP の配布パッケージに付属する language.txt という特殊なファイルに記載されています。このファイルには、英語、スペイン語、オランダ語、ドイツ語、フランス語、イタリア語、ラトビア語、リトアニア語のメッセージが保存されています。将来、これ以外の言語が追加される可能性もあります。

LANGUAGE は、これらのメッセージの表示言語を指定するための設定パラメータです。LANGUAGE に設定可能な値は、モenモ (英語)、モesモ (スペイン語)、モdeモ (ドイツ語)、モnlモ (オランダ語)、モfrモ (フランス語)、モitモ (イタリア語)、モruモ (ロシア語)、モit3モ (リトアニア語)、モlvモ (ラトビア語)、モespモ (エスペラント語) です。たとえば、設定ファイルに以下の行を記述すると、

LANGUAGE = "fr"

メッセージを表示する言語としてフランス語が選択されます。デフォルトの設定は英語です。

メッセージを表示する必要があるときには、指定された言語で記述された該当するメッセージが language.txt ファイル内で探され、メッセージの翻訳版が表示されます。言語文字列ファイルが見つからない場合、選択した言語がファイルに存在しない場合、対象となるメッセージの翻訳版がファイルに記述されていない場合、対象となるメッセージがファイル内に存在しない場合は、英語で表示されます。

ディスクスペースを節約するために、ほとんどの言語のメッセージは PGP の標準パッケージには付属していませんが、別途入手することができます。


MYNAME - 署名作成時のデフォルトのユーザー ID
----------------------------------------------

デフォルトの設定: MYNAME = ""

MYNAME は、署名を作成するための秘密鍵を選択するときに使うデフォルトのユーザー ID を指定するための設定パラメータです。MYNAME が設定されていない場合は、秘密鍵のキーホルダーに最後に登録された秘密鍵が使われます。この設定を無効にするには、PGP のコマンドラインで -u オプションを使ってユーザー ID を指定します。


TEXTMODE - 平文をテキストファイルであるとみなす
--------------------------------------------

デフォルトの設定: TEXTMODE = off

TEXTMODE は、コマンドラインオプションの -t に相当する設定パラメータです。この設定パラメータを on に設定すると、平文がバイナリファイルではなくテキストファイルであるとみなされ、「標準テキスト」に変換したあとに暗号化が行われます。標準テキストでは、各行の最後に復帰文字と改行が挿入されます。

平文ファイルにテキスト形式ではないバイナリデータが格納されていると PGP が判断した場合、このモードは自動的に無効になります。PGP の使用目的が主に E メールの処理である場合は、TEXTMODE=ON と設定してください。

VAX/VMS システムの場合、PGP の現在のバージョンではデフォルトで TEXTMODE=ON に設定されます。

詳細については、「異なるマシン環境間で ASCII テキストファイルを送受信する」のセクションを参照してください。


CHARSET - テキストファイルで使うローカル文字セットの指定
------------------------------------------------------

デフォルトの設定: CHARSET = NOCONV

PGP では、ASCII 文字以外の文字セットを使うような、英語以外の言語で記述されたメッセージを処理する必要があるため、自分のマシンで使われている文字セットを PGP に教える必要があります。これによって、平文ファイルと標準テキストフォーマット間の変換を行うときに、どのような文字変換を行うのかが決まります。これは、英語以外の非 ASCII 環境のユーザーだけに関係する設定です。

CHARSET は、ローカルの文字セットを選択するための設定パラメータです。指定できる値は、NOCONV(変換なし)、LATIN1(ISO 8859-1 ラテンアルファベット 1)、KOI8(ロシアのほとんどの UNIX システムで使用)、ALT_CODES(ロシアの MS/DOS システムで使用)、ASCII、CP850(標準的な MS/DOS コンピュータの西ヨーロッパ言語で使用)です。

LATIN1 は、PGP 内部で標準テキストに使われている表示方法です。したがって、LATIN1 を指定した場合、変換は行われません。また、KOI8 は LATIN1 とはまったく異なる言語セットですが、PGP では、KOI8 は LATIN1 として扱われます。いずれにしても、KOI8 を LATIN1 や CP850 に変換することは無意味だからです。つまり、CHARSET を NOCONV、LATIN1、KOI8 のどれに設定しても、処理結果になるということです。

MS/DOS を使って西ヨーロッパ言語でメッセージをやり取りする場合は、CHARSET = "CP850" と設定してください。このように設定すると、受信した標準テキストのメッセージは、復号化されたあと LATIN1 から CP850 に変換されます。標準テキストへの変換時に -t オプションを使うと、CP850 で記述されたテキストが LATIN1 に変換されてから暗号化処理が行われます。

詳細については、「異なるマシン環境間で ASCII テキストファイルを送受信する」のセクションを参照してください。


ARMOR - ASCII 保護出力を有効にする
---------------------------------

デフォルトの設定: ARMOR = off

ARMOR は、コマンドラインオプションの -a に相当する設定パラメータです。ARMOR を on に設定すると、ASCII radix-64 フォーマットで記述された暗号文や鍵がエミットされ、E メールで送信するのに適した形式に変換されます。出力ファイルの名前には、.asc という拡張子が付けられます。

PGP の使用目的が主に E メールの処理である場合は、ARMOR=ON と設定してください。

詳細については、基本事項編の「E メールで暗号文を送信する - radix-64 フォーマット」のセクションを参照してください。


ARMORLINES - ASCII 保護分割ファイルのサイズ
------------------------------------------------

デフォルトの設定: ARMORLINES = 720

PGP で非常にサイズの大きい radix-64 フォーマットの .arc ファイルを作成して、暗号文や鍵をE メールで送る際には、インターネットのメールユーティリティで送信可能ないくつかの小さいファイルに分割されます。通常、インターネットメーラーでは、約 50,000 バイト以上のファイルの送信は禁止されています。つまり、行数を 720 程度に制限すれば、50,000 バイトという制限値に十分収まることになります。分割されたメッセージは、.as1、.as2、.as3、… という拡張子が付いたファイルに変換されます。

ARMORLINES は、各 .asc ファイルに分割するときの最大行数を指定するための設定パラメータです。0 に設定すると、ファイルは分割されません。

Fidonet の E メールには通常、約 32K バイトという上限が設定されているので、Fidonet 環境で使う場合は、450 行に設定するとよいでしょう。

詳細については、基本事項編の「E メールで暗号文を送信する - radix-64 フォーマット」のセクションを参照してください。


KEEPBINARY - 復号化処理後にバイナリ形式の暗号文ファイルを保存する
----------------------------------------------------------

デフォルトの設定: KEEPBINARY = off

PGP が .asc ファイルを読み込む際には、ファイルが radix-64 フォーマットで記述されていることを認識し、バイナリ形式に戻したあと通常どおりに処理します。その結果、副生成物として、バイナリ形式の .pgp 暗号文ファイルが作成されます。そのあとの .pgp ファイルを復号化する処理において、最終的な出力ファイルは通常の平文形式に変換されます。

処理の途中で作成されるバイナリ形式の .pgp ファイルは削除することをお奨めします。PGP に自動的に削除させることもできます。.pgp ファイルを削除しても、PGP を実行して元の .asc ファイルを処理することができます。

KEEPBINARY は、復号化の処理過程で作成される .pgp ファイルを保存するかどうかを指定するための設定ファイルです。

詳細については、基本事項編の「E メールで暗号文を送信する - radix-64 フォーマット」のセクションを参照してください。


COMPRESS - 圧縮処理を有効にする
-----------------------------

デフォルトの設定: COMPRESS = on

COMPRESS は、暗号化処理を行う前に圧縮処理を実行するかどうかを指定するための設定パラメータです。この設定パラメータは主に PGP をデバッグするときに使います。通常は、平文を圧縮してから暗号化が行われます。一般的には、設定を変更せずに、平文が圧縮されるようにしてください。


COMPLETES_NEEDED - 完全に信用できる仲介者の最小数
------------------------------------------------------------------

デフォルトの設定: COMPLETES_NEEDED = 1

COMPLETES_NEEDED は、公開鍵のキーホルダーに登録されている公開鍵を完全に認証するために必要な完全に信用できる仲介者の最小数を指定するための設定パラメータです。このパラメータを設定することによって、PGP の基準レベルを調整することができます。

詳細については、基本事項編の「PGP における有効な鍵の管理方法」のセクションを参照してください。


MARGINALS_NEEDED - まずまず信用できる仲介者の最小数
------------------------------------------------------------------

デフォルトの設定: MARGINALS_NEEDED = 2

MARGINALS_NEEDED は、公開鍵のキーホルダーに登録されている公開鍵を完全に認証するために必要なまずまず信用できる仲介者の最小数を指定するための設定パラメータです。このパラメータを設定することによって、PGP の基準レベルを調整することができます。

詳細については、基本事項編の「PGP における有効な鍵の管理方法」のセクションを参照してください。


CERT_DEPTH - 仲介者の入れ子の深さ
-----------------------------------------------

デフォルトの設定: CERT_DEPTH = 4

CERT_DEPTH は、公開鍵のキーホルダーに登録されている公開鍵を認証するためのそのほかの仲介者をどの程度入れ子することができるかを指定するための設定パラメータです。たとえば、CERT_DEPTH を 1 に設定すると、最大限に信用できる鍵の下には仲介者の階層は 1 つしか設定できません。このような場合は、キーホルダーに登録されている信用できるすべての仲介者の公開鍵をユーザーが直接認証する必要があります。CERT_DEPTH を 0 に設定した場合は、仲介者を設定できないため、公開鍵のキーホルダーのすべての鍵を直接を認証しないと、使用することができなくなります。CERT_DEPTH に設定できる最小値は 0 で、最大値は 8 です。

詳細については、基本事項編の「PGP における有効な鍵の管理方法」のセクションを参照してください。


BAKRING - 秘密鍵のキーホルダーのバックアップファイル名
--------------------------------------------

デフォルトの設定: BAKRING = ""

公開鍵のキーホルダーに対して PGP が行うすべての鍵認証は最終的には、最大限に信用できる公開鍵の正当性に左右されます。公開鍵のキーホルダーが改ざんされているかどうかをチェックするためには、自分の鍵が改ざんされていないことを確認する必要があります。そのためには、書き込みを禁止した、改ざん不可能なメディアに保存されている秘密鍵のコピーと公開鍵との照合チェックを行う必要があります。秘密鍵には、公開鍵のすべての情報および一部の秘密要素が格納されています。つまり、秘密鍵のバックアップコピーを使って、公開鍵を確認できるということです。

設定パラメータ BAKING を使うと、秘密鍵のキーホルダーのバックアップコピーに使用するパス名を指定することができます。MS/DOS では a:\secring.pgp と設定することによって、秘密鍵のキーホルダーのバックアップコピーをフロッピーディスクに保存して書き込みできないようにできます。この確認は、PGP の -kc オプションを実行して公開鍵のキーホルダーをチェックするとき以外は行われません。

BAKRING を設定しなかった場合は、鍵とバックアップコピーの照合チェックは行われません。

詳細については、基本事項編の「公開鍵の改ざんを防止する方法」のセクションと「PGP における有効な鍵の管理方法」のセクションを参照してください。


PUBRING - 公開鍵のキーホルダーのファイル名
------------------------------------------

デフォルトの設定: PUBRING = "$PGPPATH/pubring.pgp"

公開鍵のキーホルダーは、$PGPPATH 環境変数で指定されているディレクトリに保存されている PGP 設定ファイルとは別のディレクトリに保存することをお奨めします。PUBRING パラメータを設定することによって、公開鍵のキーホルダーのフルパスとファイル名を指定することができます。たとえば MS/DOS システムでは、以下のように入力して、フロッピーディスクに公開鍵のキーホルダーを保存するとよいでしょう。

PUBRING = "a:pubring.pgp"

この機能は、コマンドラインで別のキーホルダーを指定するときに特に便利です。


SECRING - 秘密鍵のファイル名
------------------------------------------

デフォルトの設定: SECRING = "$PGPPATH/secring.pgp"

秘密鍵のキーホルダーは、$PGPPATH 環境変数で指定されているディレクトリに保存されている PGP 設定ファイルとは別のディレクトリに保存することをお奨めします。公開鍵のキーホルダーよりも保護性が高いディレクトリやデバイスに秘密鍵のキーホルダーを配置するときにこのパラメータを使うと便利です。SECRING パラメータを設定することによって、秘密鍵のキーホルダーのフルパスとファイル名を指定することができます。たとえば MS/DOS システムでは、以下のように入力して、フロッピーディスクに秘密鍵のキーホルダーを保存するとよいでしょう。

SECRING = "a:secring.pgp"


RANDSEED - 乱数シードのファイル名
------------------------------------------

デフォルトの設定: RANDSEED = "$PGPPATH/randseed.bin"

セッション鍵を生成するための乱数シードファイルは、$PGPPATH 環境変数で指定されているディレクトリに保存されている PGP 設定ファイルとは別のディレクトリに保存することをお奨めします。公開鍵のキーホルダーよりも保護性が高いディレクトリやデバイスに乱数シードファイルを配置するときにこのパラメータを使うと便利です。RANDSEED パラメータを設定することによって、乱数シードファイルのフルパスとファイル名を指定することができます。たとえば MS/DOS システムでは、以下のように入力して、フロッピーディスクに保存するとよいでしょう。

RANDSEED = "a:randseed.bin"


PAGER - 平文出力を表示するためのシェルコマンドの指定
---------------------------------------------------------

デフォルトの設定: PAGER = ""

復号化を行うときに -m (more) オプションを指定すると、復号化した平文出力をファイルに書き込むことなく画面に表示することができます(UNIX の more コマンドと同じ機能です)。このコマンドを実行すると、復号化された平文が一画面ずつ表示されます。

PGP に組み込まれている表示ユーティリティよりも高度なユーティリティを使いたい場合は、シェルコマンド名を指定して、平文出力ファイルを表示するときにそのシェルコマンドが使われるように設定することができます。PAGER は、ファイルを表示するときに呼び出すシェルコマンドを指定するための設定パラメータです。たとえば、MS/DOS システムの場合は、広く使われている list.com というシェアウェアプログラムを使って平文メッセージを表示するとよいでしょう。list.com がインストールされている場合は、PAGER を以下のように設定します。

PAGER = "list"

しかし、送信者がこのファイルを画面表示のみに指定しているためにディスクに書き込めない場合は、PGP に組み込まれている表示機能が使われます。

詳細については、「復号化した平文を画面に表示する」のセクションを参照してください。


SHOWPASS - パスフレーズを表示する
-----------------------------------

デフォルトの設定: SHOWPASS = off

通常、PGP ではパスフレーズの入力時にその内容は表示されません。したがって、パスフレーズの入力中に、ほかの人が入力内容を覗き込んで、それを覚えてしまうことが難しくなります。しかし、身体的な理由でタイピングに不自由を感じるような人の場合、入力内容が表示されないと不便です。また、自分の家で、誰にも見られずにパスフレーズを入力できる場合もあります。このような人たちから、パスフレーズの入力中にその内容が表示されるように PGP を設定できないかという問い合わせがありました。

設定パラメータ SHOWPASS を使うと、パスフレーズの入力中にその内容が表示されるように設定することができます。


TZFIX - タイムゾーンの調整
---------------------------

デフォルトの設定: TZFIX = 0

PGP では、鍵や署名証明書のタイムスタンプにグリニッジ標準時または協定世界時(PGP の利用目的においては、この 2 つは同じものです)が使われます。PGP がシステムに時刻を問い合わせた場合、システムはグリニッジ標準時の時刻を返すことになっています。

しかし、MS/DOS システムが正しく設定されていない場合には、米国太平洋標準時に 8 時間を足した時刻が返されることがあります。奇妙な感じがするでしょう。米国西海岸に存在するある種の愛国主義によって、MS/DOS において、現地の時間が米国太平洋標準時であるとみなされ、太平洋標準時があらかじめグリニッジ標準時に修正されます。その結果、PGP が呼び出す内部の MS/DOS グリニッジ標準時機能の動作に悪影響が与えられます。ただし、MS/DOS の TZ 環境変数がすでに自分のタイムゾーンに正しく設定されていれば、すべての人が米国西海岸に住んでいるという MS/DOS の間違った認識が修正されます。

TZFIX は、グリニッジ標準時に変換する際に、システムタイム機能に何時間付加するかを指定するための設定変数であり、これによって変換されたグリニッジ標準時のタイムスタンプが鍵や署名に付加されます。MS/DOS の TZ 環境変数が適切に設定されている場合は、TZFIX=0 のままでかまいません。UNIX システムの場合は、通常 TZFIX の設定についてはまったく心配する必要はありません。ただし、グリニッジ標準時が認識できないような、あまり普及していない OS を利用している場合は、TZFIX を利用してシステムタイムをグリニッジ標準時に変更したほうがよいかもしれません。

TZ が設定されていない MS/DOS システムでは、カリフォルニアの場合は TZFIX=0、コロラドの場合は TZFIX=-1、シカゴの場合は TZFIX=-2、ニューヨークの場合は TZFIX=-3、ロンドンの場合は TZFIX=-8、アムステルダムの場合は TZFIX=-8 に設定してください。サマータイム採用時には、これらの値から 1 を引いた値を TZFIX に設定する必要があります。非常に面倒です。

これよりも格段にクリーンな方法もあります。それは、TXFIX 修正を使わずに、AUTOEXEC.BAT ファイルで MS/DOS の TZ 環境変数を設定するという方法です。この方法を使うと、MS/DOS は正しいグリニッジ標準時タイムスタンプを使うようになり、サマータイムの調整も自動的に行ってくれます。以下に、AUTOEXEC.BAT ファイルに挿入する記述の例を示します。記述内容はユーザーのタイムゾーンによって異なります。

ロスアンゼルス: TZ=PST8PDT
デンバー: TZ=MST7MDT
アリゾナ: TZ=MST7
(アリゾナでは、サマータイムは採用されていません。)
シカゴ: TZ=CST6CDT
ニューヨーク: TZ=EST5EDT
ロンドン: TZ=GMT0BST
アムステルダム: TZ=MET-1DST
モスクワ: TZ=MSK-3MSD
オークランド: TZ=NZT-13


CLEARSIG - 署名付きメッセージをクリアテキストとしてカプセル化する
------------------------------------------------------------------

デフォルトの設定: CLEARSIG = on

PGP の署名付きメッセージは通常、先頭にバイナリ形式の署名証明書が付加されます。また、署名付きメッセージは圧縮されて、実際に暗号化していなくても人間が読むことができない形式に変換されます。このバイナリデータを 7 ビットの E メール通信路で送信する場合は、radix-64 の ASCII 保護が適用されます(ARMOR パラメータを参照してください)。PGP でメッセージの圧縮処理が行われなかった場合でも、メッセージは ASCII 保護によって人間が判読できない形式に変換されます。受信者は、PGP を使わないと保護の除去と解凍を行ってメッセージを読むことができません。

元の平文メッセージがバイナリ形式ではなくテキスト形式の場合は、署名付きメッセージを E メールで送信することができます。つまり、署名付きメッセージが圧縮されずに、ASCII 保護がバイナリ形式の署名証明書だけに適用されて平文メッセージには適用されないような方法を使います。CLEASIG フラグを使うとこのような便利な機能が実現し、PGP を使わなくても人間が判読できる署名付きメッセージを作成することができるようになります。もちろん、実際に署名を確認するときには PGP が必要になります。

PGP のバージョン 2.5 以降では、CLREASIG フラグはあらかじめ on に設定されています。CLEASIG の動作を完全に有効にするには、ARMOR フラグと TEXTMODE フラグも on にする必要があります。ARMOR=ON(または -a オプションを使用)および TEXTMODE=ON(または -t オプションを使用) に設定してください。設定ファイルで CLEARSIG が off に設定されている場合は、コマンドラインから直接 on に戻すことができます。具体的には、以下のように入力します。

pgp -sta +clearsig=on message.txt

このメッセージ表示は、インターネット PEM (Privacy Enhanced Mail) で採用されている MIC-CLEAR メッセージタイプと似ています。この方法では、ASCII 保護はメッセージテキスト自体ではなくバイナリ形式の署名証明書だけには適用されるため、保護されていないメッセージは途中で偶発的な妨害にあうこともあります。このような事態は、文字セットの変換を行うような E メールゲートウェイを通過すると発生します。場合によっては、行末に余分なスペースが加えられたり、行末からスペースが削除されたりすることもあります。このような変更が加えられると、署名の正当性が確認できず、故意に改ざんされているという間違った表示が行われる可能性があります。しかし、PEM にも同じ弱点があるため、リスクはあるもののこの機能を搭載する価値はあると思われます。

PGP バージョン 2.2 からは、CLEARSIG モードにおいてテキストの署名を計算する際に、各行の末尾のブランクが無視されるようになりました。


VERBOSE - メッセージのモードを指定
--------------------------------------------

デフォルトの設定: VERBOSE = 1

VERBOSE に設定可能な値は、0、1、および 2 です。設定する値によって、PGP 診断メッセージの表示レベルが決まります。以下に各設定の詳細を示します。

0 - 問題が発生したときのみメッセージが表示されます。UNIX の愛好者は、この「静かなモード」設定を好みます。

1 - 通常のデフォルト設定です。診断メッセージやアドバイスメッセージが適度な詳細さで表示されます。

2 - 最大限の情報が表示されます。通常は、PGP の問題を診断するのに役に立ちます。通常の使用においては、この設定はお奨めしません。また、PGP では、問題は発生しないはずです。


INTERACTIVE - 鍵登録時の確認
-----------------------------------------------

デフォルトの設定: INTERACTIVE = off

このモードを有効にすると、複数の鍵が格納された鍵ファイルをキーホルダーに登録する際に、1 つ 1 つの鍵に対して、キーホルダーに登録するかどうかの確認が求められるようになります。


NOMANUAL-マニュアルがなくても鍵の生成を可能にする
---------------------------------------------------

デフォルトの設定: NOMANUAL = off

フリーウェアバージョンの PGP にはユーザーマニュアルが付属していませんが、標準リリースパッケージには通常マニュアルが付属しています。このマニュアルには、PGP を使う上での重要な情報や法律に関する注意事項が記載されています。PGP の古いバージョンの中には、配布元によってはマニュアルが付属していない場合があり、そのようなパッケージを手に入れた人たちは多くの問題に遭遇しています。必要なマニュアルが付属していない PGP が配布されることを防ぐために、コンピュータに『PGP ユーザーガイド』がインストールされていないと PGP で秘密鍵と公開鍵を生成できないようにしました。しかし、記憶容量の小さい小型ノートパソコンで PGP を使いたいユーザーもいます。このようなユーザーは、マニュアルをインストールせずに現在のシステムで PGP を実行したいと考えています。このようなユーザーの要求に応えるため、鍵生成時にコマンドラインで NOMANUAL フラグを有効にすると、マニュアルがインストールされている必要があるという PGP の規定を緩めることができます。具体的には、以下のように入力します。

pgp -kg +nomanual

NOMANUAL フラグは、設定ファイルに設定することはできず、コマンドラインだけで設定できます。このマニュアルを読まないと、この簡単な無効化機能の使い方を知ることもできないわけですから、マニュアルが付属しない PGP の配布を防ぐことに効果があることを願っています。

PGP が鍵を生成するためには、マニュアルが近くに存在する必要があるという PGP の主張に反対する人もいます。そのような人たちは、権威主義的とも取れるこのような態度に反感を持っています。PGP を改造することよってこの機能を無効にし、不正なバージョンを第三者に配布するユーザーもいました。このような行為は、私にとっては問題になります。この機能を付加する前には、マニュアルが付属していない、不備のある PGP 配布パッケージが各種出回っていました。そのようなパッケージの 1 つが Compuserve にアップロードされ、数多くのユーザーに配布されていました。私に電話をかけてきて、これほど複雑なプログラムにマニュアルが付属していない理由を問い正すユーザーも数多くいました。このパッケージは、国のあちこちの BBS システムに広がりました。その後、あるフリーウェア配布組織がこのパッケージを Compuserve から入手して CD-ROM に格納し、マニュアルが付属しない状態で数千というパッケージを配布してしまいました。何と言うことでしょう。


==================
内部機構
==================

PGP の内部的な機能のいくつかを見てみましょう。


乱数
--------------

PGP では、暗号強度の高い疑似乱数ジェネレータを使って、従来の一時セッション鍵を作成しています。一時セッション鍵のシードファイルは、randseed.bin というファイルです。このファイルは任意のディレクトリに保存できます。保存ディレクトリを指定するには、PGPPATH 環境変数を使います。ランダムシードファイルが存在しない場合は、自動的に作成され、ユーザーの打鍵間隔を基盤に生成された真の乱数のシードになります。

このジェネレータは、ディスクファイルが使われるたびに、時刻などの真の無作為ソースから生成された新しい鍵データを混合することによって、ディスクファイルに対して再度シードを供給します。乱数ジェネレータのエンジンとしては、従来の暗号化アルゴリズムが使われています。シードファイルには、無作為なシードデータと無作為な鍵データが格納されており、乱数ジェネレータの従来の暗号化エンジンを使って鍵を作成します。

この無作為シードファイルは、漏洩に対して多少の保護を行い、ユーザーの次のセッション鍵や前のセッション鍵がアタッカーに推測されないようにしてください。攻撃を行う場合、この無作為シードファイルから意味のあるデータを取り出すことは非常に困難です。無作為シードファイルは、使用する前と使用したあとに暗号的にクリーンにされるからです。それでも、このファイルが少なくとも悪意のある第三者に渡らないように用心するのが賢明でしょう。

アルゴリズムを基盤に生成された乱数ソースがいくら強力であっても、それを信用することに不安を感じる方は、すでに従来の暗号の強度を信用してメッセージを保護しているということを思い出してください。従来の暗号の強度が十分であるとすれば、一時セッション鍵の乱数ソースとしても十分な強度があるはずです。なお、PGP では、現在でも物理的なソース(主にキーボードによる入力のタイミング)から生成した真の乱数を使って、長期的な公開鍵と秘密鍵のペアを生成しています。



PGP で使われている従来の暗号化アルゴリズム
---------------------------------------

すでに説明したように、PGP は公開鍵アルゴリズムを使って従来のセッション鍵を暗号化したあとで従来の高速暗号技術に切り替えることによって、起動時に「自力で」従来の単一鍵による暗号化アルゴリズムを使用するようになります。従来の暗号化アルゴリズムについて説明しましょう。DES のことではありません。

一般的な市販のアプリケーションでは、優れた暗号化アルゴリズムであるとして、DES (Federal Data Encryption Standard: 連邦データ暗号化規格) が使われていました。しかし、政府はその機密データを保護する際に DES を決して信用していませんでした。DES の鍵長である 56 ビットは、総当り攻撃に対して十分に防御できなかったからです。また、16 ラウンドの完全な DES が、Biham と Shamir によって特殊な解読法を使って攻撃されたり、Matsui によって直線的な解読法を使って攻撃されたりしたことがあります。どちらの攻撃もある程度成功しました。

Crypto 93 のコンフェレスンスにおいて、DES に対するもっとも破壊的かつ現実的な攻撃に関する説明がありました。このコンフェレンスで、Bell Northern Research の Michel Wiener は、特殊なマシンを使って DES を解読する方法に関する研究を発表しました。Wiener は、1 秒間に 5,000 万の DES 鍵を推測することによって正しい鍵を発見できるチップを完全に設計していただけでなく、テストも完了していました。現在時点では、実際にこのようなチップは作成されていませんが、単価 10.50 ドルで製作させることができ、100 万ドルする特殊なマシンにこのチップを 57,000 個組み込むことによって、すべての鍵を 7 時間で調べることができます。鍵を発見するの必要な平均時間は 3.5 時間です。100 万ドルであれば、一般的な会社の予算に密かに組み込むことができます。1,000 万ドル出せば、21 分で解読でき、1 億ドル出せばわずか 2 分で解読できます。DES トラフィックを調査する政府の主な予算を使えば、数秒で解読できるようになります。つまり、直線的な 56 ビットの DES は、重要なセキュリティを必要とするデータに対しは、事実上無効であるということです。

DES に取って変わるものとしては、「トリプル DES」と呼ばれる規格が考えられます。トリプル DES では、2 つの鍵を使って暗号化処理を 3 回行うことによって、112 ビットの有効鍵スペースを実現します。しかし、この方法の場合、通常の DES に比べて 3 倍の時間がかかります。PGP の将来のバージョンでは、オプションとしてトリプル DES をサポートする可能性もあります。

PGP では、メッセージを暗号化するための従来の単一鍵アルゴリズムとして DES は使われていません。IDE(tm) と呼ばれる別の従来からの単一鍵ブロック暗号化アルゴリズムが使われます。

暗号的に奇妙な点としては、IDEA 暗号には、平文と暗号文に対して 64 ビットのブロックサイズがあるということです。IDEA 暗号では、128 ビットの鍵サイズが使われます。また、その設計コンセプトは、さまざまな代数グループの演算を混合することです。ソフトウェアにおいては、DES よりも高速に実行されます。DES と同様、CFB (Cipher Feedback: 暗号フィードバック) モードや CBC (ブロックチェーン化) モードで使用できます。PGP では、64 ビットの CFB モードで使用します。

スイス連邦工科大学チューリッヒ校で James L. Massery と Xuejia Lai によって IPES/IDEA ブロック暗号が開発され、1990 年に発表されました。これは、「国産」のアルゴリズムではありません。この暗号の設計者は、暗号の世界では高く評価されている人です。以前に発表されたアルゴリズムに関する論文では、IPES (Improved Proposed Encryption Standard: 改良型推奨暗号化規格) と呼ばれていましたが、のちに IDEA(International Data Encryption Algorithm: 国際データ暗号化アルゴリズム)に改名されました。これまでのところ、FEAL、REDOC-II、LOKI、Snefru、Khafre といったほかの暗号に比べて、IDEA の耐攻撃性は各段に優れていました。また、特殊な解読法を使った成功率が非常に高い Biham と Shamir の攻撃に対しても、IDEA は DES よりも強靭であるという証拠が最近見出されました。Biham と Shamir は、IDEA の弱点を研究しましたが、見つけることができませんでした。ベルギー、イギリス、ドイツの学術的な暗号解読グループやヨーロッパ各国の軍事機関も IDEA に対する攻撃を試みました。この新しい暗号は、暗号解読界の最も恐るべき部門から、攻撃対象として高い関心を示されているため、IDEA の信頼性は時の経過とともに大きくなっています。

PGP では、大量のデータを暗号化する際に純粋な RSA を使っていません。このような恐ろしい事実をはじめて知った人から手紙が届くことが時々あります。このような人たちが心配していることは、高速化を実現するためだけに混成の公開鍵と従来の方式を使っているとしたら、パッケージ全体が弱体化するのではないかということです。つまり、「弱い環があれば全体の環が弱い」のではないかという心配です。彼らは、PGP の強度にこのような明らかな「妥協」がある理由についての説明を求めます。これは、RSA 技術を崇敬する世間の風潮に感化され、RSA 技術に対して畏敬の念を抱いており、RSA は従来のどの暗号よりも本質的に強力であると誤解しているからかもしれません。しかし、事実はそうではありません。

因数分解の研究に携わっている人たちによると、IDEA で使われていると考えられる 128 ビットの鍵をすべてチェックするための仕事量は、3,100 ビットの RSA 鍵を解読するのに必要な因数分解を行う仕事量とほぼ同じだということです。3,100 ビットの RSA 鍵は、ほとんどの人が高セキュリティアプリケーションで使っている 1,024 ビットの RSA 鍵に比べてかなり大きいサイズです。鍵のこのようなサイズ差を考えると、そして従来の暗号には弱点が潜んでいないと仮定すれば、この混合方式の弱点は、従来の暗号ではなく、公開鍵のアルゴリズムであると言えます。

大きな鍵を使う純粋な RSA を利用して長いメッセージの暗号化と復号化を行うことは、使い勝手の点において現実的ではありません。1,024 ビットの RSA 鍵を使ってメッセージを復号化した場合、IDEA 暗号と比べて 4,000 倍ほどの時間がかかります。実際にこのような方法を使って復号化を行う人は絶対にいません。公開鍵による暗号技術の人気が高い理由は、それが従来の暗号よりも本質的に強力であるからではなく、鍵の管理が簡単だからです。暗号化技術における経験が少ない人は、一般的にこのような事実をわかっていません。

RSA は、大量のデータを処理するにはあまりにも速度が遅いだけでなく、ほかにも弱点があります。たとえ鍵のサイズが大きい場合でも、特定の種類のメッセージがRSA 暗号に送り込まれるような特殊なケースにおいて、このような弱点を突かれる場合があります。このような特殊なケースは、RSA を使って従来の暗号用のランダムセッション鍵を暗号化するという混合方式を使うことによって回避できます。PGP でもこの方法が使われています。結論は、サイズの大きいデータに対して純粋な RSA を使うのは、間違った方法であるということになります。速度が遅すぎるだけでなく、強度にも問題があります。脆弱であると言ってもよいかもしれません。サイズの大きいデータに対して純粋な RSA を使うアプリケーションが存在するとしたら、作成者はこのような問題を知らなかったということであり、暗号化技術に関するそのほかの重要な概念も理解していないということになります。



データの圧縮
----------------

PGP では通常、平文を暗号化する前に圧縮処理が行われます。この処理の順番を入れ替えることはできません。暗号化されたデータは圧縮できないからです。データを圧縮することによって、モデムの通信時間を短縮したりディスクスペースを節約したりすることができますが、もっと重要なことは、暗号のセキュリティが向上するということです。ほとんどの暗号解読法では、平文に存在する冗長性を利用して暗号を解読します。データを圧縮すると、平文に存在するこのような冗長性が低減するため、暗号解読が各段に困難になります。平文を圧縮するには余分な時間がかかりますが、少なくとも用心深い私の意見では、セキュリティを考えれば、圧縮を行う価値はあると言えます。

短すぎて圧縮できないファイルやうまく圧縮できないようなファイルは圧縮されません。

好みに応じて、PKZIP を使って平文を圧縮したあとに暗号化を行うこともできます。PKZIP は、PKWare, Inc が作成した MS/DOS 用のシェアウェアとして幅広く使われている効率的な圧縮ユーティリティです。ZIP を使ってもかまいません。ZIP は、PKZIP と互換性があります。UNIX などのシステムで利用できるフリーウェアの圧縮ユーティリティであり、配布元は Jean-Loup Gailly です。 特別なケースでは、PKZIP や ZIP を使うことにはメリットがあります。PKZIP や ZIP には、PGP に組み込まれている圧縮アルゴリズムには備わっていない機能、つまり複数のファイルを圧縮して 1 つのファイルに格納できるというすばらしい機能が備わっているからです。圧縮ファイルは、解凍すると元の複数のファイルに復元されます。PGP では、すでに圧縮されている平文ファイルに対して圧縮処理は行われません。受信者は PKUNZIP を使って、復号化した平文を解凍します。復号化した平文が、PKZIP を使って圧縮されたファイルの場合は、そのことが自動認識され、復号化した平文が PKZIP ファイルであるというメッセージが表示されます。

技術的な内容に興味がある方のために説明すると、PGP の現在のバージョンでは、Jean-loup Gailly、Mark Adler、Richard B. Wales によって記述されたフリーウェアの ZIP 圧縮ルーチンが使われています。この ZIP ソフトウェアでは、機能性においては PKWare の新しい PKZIP 2.0 で使われているのと同じ圧縮アルゴリズムが使われています。ZIP ソフトウェアが PGP で採用された主な理由は、移植性の高い C ソースコードが利用できること、圧縮率が非常に優れていること、そして高速であることです。

また、Peter Gutmann によっても、HPACK という優れた圧縮ユーティリティが作成されています。このユーティリティは、インターネットのさまざまな FTP サイトから無料で入手できます。HPACK では、圧縮されたアーカイブファイルの暗号化を行う際に、PGP のデータフォーマットとキーホルダーが使われます。このマニュアルでそのことについて説明しておいてほしいと Peter Gutmann に依頼されました。



メッセージダイジェストとデジタル署名
--------------------------------------

デジタル署名を作成する場合、PGP ではユーザーの秘密鍵を使って暗号化を行います。ただし、秘密鍵を使って、実際にメッセージ全体を暗号化するわけではありません。時間がかかりすぎるからです。メッセージ全体が暗号化されるのではなく、「メッセージダイジェスト」が暗号化されます。

メッセージダイジェストは、メッセージをコンパクト(128 ビット)にした「抽出物」であり、そのコンセプトはチェックサムと似ています。メッセージの「フィンガープリント(指紋)」であると考えることもできます。メッセージダイジェストはメッセージの代わりとなるものであり、メッセージに何らかの変更が加えられた場合は、変更後のメッセージから別のメッセージダイジェストが生成されます。したがって、偽造者によってメッセージに何らかの変更が加えられた場合は、そのことを検知することができます。メッセージダイジェストは、暗号強度の高い一方向的な、メッセージのハッシュ関数を使って算出されます。まったく同じメッセージダイジェストを生成するような別のメッセージを考え出すことによって攻撃を行うことは計算上不可能です。このような点で、メッセージダイジェストはチェックサムよりもはるかに優れています。同じチェックサムを生成するような別のメッセージを考え出すことは簡単だからです。ただし、チェックサムと同様、メッセージダイジェストから元のメッセージを推測することはできません。

メッセージを認証するには、メッセージダイジェストだけでは不十分です。メッセージダイジェストアルゴリズムは公に知られているものであり、秘密鍵の算出に関する知識は必要とされません。メッセージにメッセージダイジェストを添付するだけであれば、メッセージを改ざんしたあと、そのメッセージから算出した新しいメッセージダイジェストを添付することよって偽造することができます。そこで、本当の認証を実現するために、送信者は秘密鍵を使ってメッセージダイジェストを暗号化する(署名を付ける)必要があります。

メッセージダイジェストは、送信者によってメッセージから算出します。送信者の秘密鍵を使ってメッセージダイジェストとタイムスタンプが暗号化され、デジタル署名、つまり署名証明書が作成されます。送信者は、メッセージにデジタル署名を添付して送付します。メッセージとデジタル署名を受け取った受信者は、送信者の公開鍵を使ってメッセージを復号化することによって、デジタル署名から元のメッセージダイジェストを復元します。そして、メッセージから新しいメッセージダイジェストを算出し、デジタル署名から復元したメッセージダイジェストと一致するかどうかを確認します。一致した場合は、メッセージが改ざんされていないこと、そして署名を確認するのに使った公開鍵を所有する送信者からメッセージが送られてきたことがわかります。

偽造するのであれば、まったく同じメッセージダイジェストが生成されるようにメッセージを改ざんするか、別のメッセージダイジェストから新しいデジタル署名を作成する必要がありますが、送信者の本当の秘密鍵を知らないかぎり、このようなことを行うのは不可能です。

デジタル署名を使うと、メッセージの送信者が誰であるかを証明できるだけでなく、エラーであるか故意であるかに関わらず、メッセージに変更が加えられていないことも証明できます。また、否認防止も実現します。つまり、送信者は、メッセージに付けられた署名が自分のものであることを簡単には否定できないということです。

メッセージダイジェストを利用してデジタル署名を作成することには、秘密鍵を使って実際のメッセージ全体に直接署名することよりも優れている点はほかにもあります。メッセージダイジェストを利用すると、実際のメッセージのサイズに関係なく、署名を標準の固定サイズにすることができます。また、チェックサムを使うときとよく似た方法を使って、ソフトウェアにメッセージの正当性を自動的に確認させることも可能になります。署名とメッセージを別々に保存することも可能になります。実際のメッセージに関する重要な情報が明らかにされることなく、公的なアーカイブなどにも保存できます。メッセージダイジェストからメッセージの内容は一切推測できないからです。

ここで使われるメッセージダイジェストアルゴリズムは、MD5 のメッセージダイジェストアルゴリズムであり、RSA Data Security, Inc によってパブリックドメインに配置されています。MD5 の設計者である Ronald Rivest は、MD5 について以下のように記述しています。

同じメッセージダイジェストが生成されるような 2 つのメッセージを考え出すことの困難さは、2^64 回の演算を行うことに匹敵し、所定のメッセージダイジェストを生成するようなメッセージを考え出す困難さは、2^128 回の演算を行うことに匹敵します。MD5 のアルゴリズムは、弱点が存在しないかどうかが注意深く調べられています。しかし、比較的新しいアルゴリズムであり、この種の新しい提案が行われた場合の常として、当然ながら、セキュリティに関してさらに分析を行う必要もあります。MD5 や RSA の公開鍵による暗号化システムを基盤とする、非常にセキュリティレベルの高い混合方式のデジタル署名方式においては、MD5 のセキュリティレベルは十分なはずです。



=============================================
PGP の古いバージョンと新しいバージョンとの間の互換性
=============================================

PGP のバージョン 2.6 では、バージョン 2.3 ~ 2.7 で生成したものをすべて読み込むことができます。ただし、マサチューセッツ工科大学と RSA Data Security, Inc との間で取り交わされた合意によって、1994 年 9 月 1 日に PGP 2.6 の動作が若干変わります。この変更は、プログラムに組み込まれたソフトウェアタイマーによって行われます。9 月 1 日になると、バージョン 2.6 ではメッセージ、署名、鍵において、これまでとは少し異なる新しいデータフォーマットが使われるようになります。古いフォーマットで作成されたメッセージ、署名、鍵も読み込むことはできますが、新しく作成するメッセージ、署名、鍵には新しいフォーマットが使われます。このような変更を行う目的は、古いバージョン(2.3 以前)のPGP を継続的に使うユーザーの数を減らすことです。これは、古いバージョンの PGP は、RSA の特許を侵害していると Public Key Partner が主張しているからです(「法律に関連する事項」のセクションを参照してください)。ViaCrypt の PGP(「商用版 PGP の入手場所」のセクションを参照してください)のバージョン 2.4 ~ 2.7 では、Viacrypt と Public Key Partners との間のライセンスに関する取り決めによって、特許の侵害に関する問題が発生しないようになっています。PGP 2.5 と 2.6 では、RSA Data Security, Inc からライセンス許諾された RSAREF(TM) 暗号ツールキットを使うことによって、特許の侵害に関する問題が発生しないようになっています。

米国以外では RSA の特許は有効ではありません。したがって、米国以外の PGP ユーザーは RSAREF とその制限事項に準拠していない PGP 製品を自由に使えます。このマニュアルのこのあとの「法律に関する事項」に記載した海外のバージョンに関する注意事項を参照してください。米国以外で作成された PGP の各バージョンでも新しいフォーマットが利用できると思います。詳しい説明は、マサチューセッツ工科大学から入手できます。1994 年の 8 月以前にバージョンアップを行うと、互換性に関する問題が若干発生します。

バージョン 2.6 以降で適用されるフォーマット変更は、新しい機能の搭載に伴って当然発生するプロセスと同じようなものであり、古いバージョンの PGP では、新しい PGP で作成したファイルを読み込むことができませんが、新しいバージョンでは古いフォーマットのファイルも読み込むことができます。通常の変更と唯一異なる点は、技術的なバージョンアップではなく、「法的な理由にあるバージョンアップ」であるということです。波風が立たなくなるのであれば、有意義な変更です。

PGP の製品版を販売する ViaCrypt によると、ViaCrypt PGP では新しいフリーウェアバージョンの PGP との互換性が維持されるようです。

PGP の旧バージョンとの互換性を有効にする変更はほかにもあります。残念ながら、RSAREFF および PGP 2.5 と 2.6 によってデータフォーマットが制限されるため、PGP 2.2 以前のバージョンで作成されたメッセージや署名は解釈できません。RSAREF に切り替えるためには新しいデータフォーマットを使わざるをえないので、この問題については一切対処することができません。

バージョン 2.4(ViaCrypt の初めてのバージョン)から少なくともバージョン 2.6 までの PGP では、1,024 ビットを超えるサイズの RSA 鍵を生成することはできません。上限は、常に 1,024 ビットになるように設計されています。性能および互換性といった理由で、何らかの上限を設定する必要があったからです。しかし、古いバージョンの PGP にはバグが存在したため、1,024 ビットを超える鍵を作成することができました。サイズの大きな鍵を作成すると、PGP の旧バージョン間で互換性に関する問題が発生します。バージョンによって、使われる演算アルゴリズムと固有のワードサイズが異なるからです。プラットフォームによっては、サイズの大きな鍵の処理時に PGP が停止しました。古い鍵のサイズに関する問題以外にも、現在 RSAREF は 1,024 ビットの制限を実行しています。1,024 ビットの鍵は、主要な政府機関による攻撃を受けにくい十分なサイズであることが多いと言えます。PGP の将来のバージョンでは、サイズの大きい鍵がサポートされる予定です。

一般的に、2.0 ~ 2.4 のバージョンでは互換性があります。新しい機能が付け加えられると、新しいバージョンで作成された一部のファイルを古いバージョンでは必ずしも処理できない場合があります。すべてのアルゴリズムとデータ構造に大幅な変更を加えたため、PGP のバージョン 2.0(以降)とバージョン 1.0 との間に互換性はほとんどありません(いずれにしても、現在バージョン 1.0 を使っているユーザーはいません)。

PGP の将来のバージョンでは、重要な新機能を搭載するために、メッセージ、署名、鍵、キーホルダーのデータフォーマットを変更する必要が生じるかもしれません。将来のバージョンでも、現在のバージョンで作成した鍵、署名、メッセージを処理できるようにするつもりですが、保証はできません。今後のバージョンには、古い鍵を変換するための変換ユーティリティが付属される可能性もありますが、旧バージョンの PGP で作成した古いメッセージは処分する必要があるかもしれません。また、現在のバージョンにおいても、すべての将来のバージョンで作成されたファイルなどを読み込めなくなる可能性があります。


==================
弱点
==================

侵入できないデータセキュリティシステムはありません。PGP でもさまざまな方法で抜け道を見つけることができます。どのようなセキュリティシステムにおいても、保護しようとしている情報が、それを攻撃するためのコストに見合うだけの価値があるかどうかを考える必要があります。このようなことを考えると、コストがかかる攻撃のことを心配する必要はなく、安っぽい攻撃から身を守ることを考えるべきであるという結論に達します。

これから説明する内容の中には、無用の心配であると思えるものもあるかもしれませんが、脆弱性について適切な説明を行う場合は、このような姿勢が適しています。


パスフレーズと秘密鍵の安全性に問題がある場合
--------------------------------------

最も単純な攻撃とは、秘密鍵のパスフレーズをメモしたものを放置した場合に発生するものです。他人にパスフレーズと秘密鍵ファイルを盗まれると、メッセージが盗み見されたり、あなたの名前で署名が作成されたりする可能性が発生します。

子どもや配偶者の名前など、簡単に推測できるようなパスワードは使わないようにしてください。1 語だけのパスフレーズを使っている場合は、コンピュータを利用して辞書に載っている単語をすべてチェックされ、パスワードが突き止められてしまいます。これが、パスワードよりもパスフレーズのほうが優れている理由です。もっと高度な攻撃では、コンピュータを使って有名なせりふを載せた本をスキャンしておき、パスフレーズを発見するといった方法も考えられます。忘れにくくなおかつ推測しにくいパスフレーズは、思いつきもしないような無意味な文章や誰も知らないような文学作品の一節を利用すると簡単に作成できます。

詳細については、『PGP ユーザーズガイド』の基本事項編、「秘密鍵の漏洩を防止する方法」のセクションを参照してください。


公開鍵の改ざん
--------------------

公開鍵が改ざんされていると、大きな弱点が発生します。これが、公開鍵を利用した暗号化システムの最大の弱点であると言えるかもしれません。その 1 つの理由として、ほとんどの初心者は公開鍵が改ざんされていることに気付かないからです。この弱点の重要性とそれに対するクリーンな対応策の詳細については、基本事項編の「公開鍵の改ざんを防止する方法」を参照してください。

要点を簡単に説明します。ほかの人の公開鍵を使う場合は、改ざんされていないことを確認します。ほかの人からはじめて公開鍵を受け取ったときは、その公開鍵の所有者から直接受け取ったり、信用できる第三者の署名が付いている場合以外は、信用しないでください。自分の公開鍵のキーホルダーは絶対に改ざんされないようにしてください。自分の公開鍵と秘密鍵のキーホルダーは、物理的な方法で管理してください。リモートのタイムシェアリングシステムではなく自分のコンピュータに保存するのがよいでしょう。どちらのキーホルダーもバックアップコピーを作成して保存します。


ファイルは本当は削除されていない
-------------------------

セキュリティに関する問題の発生原因はほかにも考えられます。それは、一般的な OS におけるファイルの削除方法です。ファイルを暗号化したあとに元の平文ファイルを削除しても、データは実際に物理的に消去されるわけではありません。ディスクの該当するブロックが削除済みとしてマークされ、そのスペースがあとで再利用できるようになるだけです。例えて言うならば、重要な書類をシュレッダーで処分するのではなく、紙用のリサイクル箱に捨てるようなものです。ディスクの該当するブロックには、消去したいと思った元の重要なデータが残っており、最終的には将来の任意の時点で新しいデータに上書きされることになリます。割り当て解除後すぐに、この削除済みのディスクブロックを読み込むと、平文を復元することができます。

実際に、何らかの理由で、だれかがディスクの間違った場所にアクセスし、一部のファイルが間違って削除されたり破壊されたりすると、このような事態が偶発的に発生することもあります。ディスク復元プログラムを実行すると損傷したファイルを復元できますが、これはすでに削除したファイルとそのすべての内容が復元されるということでもあります。完全に消去したと思っている極秘ファイルが復元され、損傷したディスクを復元しようとしている人に見られることになります。元のメッセージをワードプロセッサやテキストエディタで作成している最中でも、内部的な仕組みとして、文章を保存するための一時ファイルがディスク上に複数作成される場合もあります。文章を一時的に保存するファイルは、ワードプロセッサの終了時に削除されますが、重要な内容の断片はディスク上のどこかに保存されています。

実際に起こった恐ろしい話を紹介します。私の友人で、結婚して小さい子どもがいる人がいました。彼女はほんの少しの間、軽い不倫をしていた時期がありました。彼女はワードプロセッサを使って恋人あてに手紙を書き、その手紙を送ったあとファイルを削除しました。その後、彼女の不倫がすでに終わっていたときに、何らかの理由で問題のフロッピーディスクが破損しました。そのフロッピーには、ほかにも重要な文書が保存されていたため、復元する必要がありました。彼女は夫にディスクの修復を頼みました。証拠となる手紙は削除されていることをわかっていたので、ディスクを修復してもまったく問題はないと思われました。彼女の夫は、市販のディスク復元ソフトウェアを実行して、ファイルを復元しました。ファイルは無事復元されました。しかし、削除したはずの手紙までも復元されてしまったのです。彼女の夫はその手紙を読み、それがきっかけで数々の悲劇が起こりました。

平文が復元されることを防ぐ唯一の方法は、削除した平文ファイルを何らかの方法で上書きすることです。削除したディスクブロックがすぐに使われることが確実でないかぎり、確実な手段によって平文ファイルを上書きする必要があります。ワードプロセッサによって作成されたファイルの断片がディスクに残っている場合も上書きします。暗号化を行ったあとに元の平文ファイルを上書きするには、PGP の -w (wipe) オプションを使います。ディスクに残っている平文の断片については、ディスクの未使用のブロックをすべて上書きする機能が備わったディスクユーティリティを使って処理します。たとえば、Norton の MS/DOS 用のユーティリティに、このような機能が備わっています。

ディスク上の平文データを上書きしたとしても、豊富なリソースと強い意思を有する敵であれば、データを復元できる場合もあります。上書きしたあとでも、ディスク上には元のデータの磁気がかすかに残ります。高機能の特殊なディスク復元ハードウェアを使うと、データを復元できる場合もあります。


ウィルスとトロイの木馬
-------------------------

特別に作成した悪意のあるコンピュータウィルスやワームを使って、PGP や OS に感染させるといった攻撃も考えられます。この想定上のウィルスを使って、パスフレーズ、秘密鍵、復号化済みのメッセージを盗み出し、手に入れたデータを密かに別のファイルに書き出したり、ネットワークを利用してウィルスの所有者に送信したりすることも可能です。PGP の動作を変えることによって、署名の確認が正常に行われないようにすることも可能です。このような攻撃は、暗号解読による攻撃よりも低コストで行うことができます。

このような攻撃に対する防御は、一般的にウィルス感染に対する防御に分類されます。適度な機能を備えたアンチウィルス製品が販売されており、ウィルス感染の可能性を大幅に低減できるクリーンな手順もあります。ウィルスやワームを防止するための対応策を詳細に説明することは、このマニュアルの主旨ではありません。PGP には、ウィルスに対する防御策が講じられておらず、ユーザーのコンピュータが信頼性の高い環境で実行されていることを前提にしています。このようなウィルスやワームが実際に出現した場合は、すべてのユーザーに対して警告が直ちに発せられることを望みます。

これと似た攻撃方法はほかにもあります。それは、PGP とほとんど同じように動作し、本来の意図とは異なる処理を行うような模造ソフトウェアを巧妙に作成するという手口です。たとえば、故意に署名の確認を適切に行わないようにおくことによって、にせの鍵証明書が承認されるようにすることも可能です。このような PGP 版「トロイの木馬」を作成して攻撃を行うことは難しいことではありません。PGP のソースコードは広く公開されているため、ソースコードに手を加えることによって、
本物とそっくりでありながら、極悪非道な主人の指示どおりに動作するような、脳に異常をきたしたゾンビのような模造ソフトウェアを作成することは誰にもできるからです。このようにして作成された PGP 版トロイの木馬は、私の製作物であるとして広く配布される可能性があります。まったく油断できません。

PGP は、あらゆる意味で信頼できる場所から入手するようにしてください。関連性のない複数のソースから入手して、ファイル比較ユーティリティを使って比較してみるのもよいでしょう。

PGP が改ざんされていないかどうかを調べる方法はほかにもあります。デジタル署名を使う方法です。PGP の実行可能なバージョンに信用できる人の署名が付加されていることによって、ウィルスに感染していたり改ざんされたりしていないことが証明されれば、正常なバージョンを入手したことを確信しても大丈夫でしょう。信用できる PGP の古いバージョンを使って、それ以降の疑わしいバージョンの署名を確認してもよいでしょう。ただし、OS がウィルスに感染している場合は、この方法はまったく役に立ちません。また、PGP.EXE の元のコピーが、署名確認機能が働かないように改ざんされているかどうかを検知することもできません。このテストは、PGP の実行ファイルに付加された署名を確認するときに使った公開鍵のコピーが正当かつ信用できるものであることも前提としています。

マサチューセッツ工科大学や ViaCrypt から直接配布されたものや電子署名が付けられた私の裏書が付いているものでないかぎり、信用しないことをお奨めします。新しいバージョンの配布パッケージには、必ずそのパッケージの配布元のデジタル署名が 1 つまたは複数付けられています。通常は、マサチューセッツ工科大学や ViaCrypt、またはそのバージョンのリリース元の代表者の署名が付けられています。入手したバージョンに付けられている署名を確認してください。実際に、にせものの PGP 配布パッケージを何回か目にしたことがあります。このようなにせもののパッケージの中には、CD-ROM 配布業者や Compuserve など、信頼できそうなフリーウェア配布ルートからリリースされているものもありました。新しいバージョンを入手したときは、必ず署名を確認してください。


物理的なセキュリティ侵害
------------------------

物理的なセキュリティの侵害があると、平文ファイルや表示メッセージを第三者に物理的に盗まれてしまうことがあります。敵が必死であれば、押込み強盗、ごみ箱あさり、不当な調査や押収、贈賄、脅迫状、偽装スタッフといった手段を使ってこれを実現させる可能性もあります。このような攻撃の中には、スタッフの多くがボランティアであるような政治的な草の根団体においては、きわめて実現性が高いものもあります。FBI の プログラムでは、反戦団体や市民権運動団体に対して、強盗、潜入、違法なバグ修正が行われたと、マスメディアは大々的に報じてきました。ウォーターゲートホテルで起こった事件にも注目する必要があります。

暗号化ツールを所有しているからといって、間違ったセキュリティ感に陥らないようにしてください。暗号化技術によって保護できるのは暗号化されたデータだけです。平文データ、記述・口述データは、物理的なセキュリティの侵害を直接的に行うことによって危険にさらされる可能性があります。

このような攻撃は、暗号解読による攻撃よりも低コストで行うことができます。


テンペスト攻撃
---------------

完全装備した敵に対する攻撃方法として、ユーザーのコンピュータから発せられる電磁信号を遠隔検知する方法があります。このような高コストでいくぶん人員を要する攻撃を行う場合でも、直接暗号を解読されてしまう攻撃に比べればそのコストは安いでしょう。彼等はその機器を装備したバンを会社の近くに駐車し、ユーザーのキーボード操作やコンピュータのディスプレイに表示されるメッセージのすべてを遠隔操作で検知します。このような行為によって、パスワードやメッセージなど、すべてものが危険な状態にさらされます。このような攻撃は、すべてのコンピュータ機器とネットワーク配線を適切に保護して信号が発生しないようにすることによって防止できます。この保護技術が「テンペスト」と呼ばれるものであり、一部の政府機関や防衛関係の請負業者が利用しています。テンペスト保護を販売しているハードウェアベンダーが存在しますが、これを利用するには政府のライセンス許諾のようなものに従う必要がある場合があります。政府がテンペスト保護の利用を制限する理由は何でしょうか。


マルチユーザーシステムにおける漏洩
------------------------------

PGP はもともと、シングルユーザーの MS/DOS マシンにおいて、ユーザーが直接物理的に管理することを前提に設計されたものです。私は、PGP を自宅のコンピュータで実行していますが、他人が私の家に押し入り電磁信号を監視しない限り、平文ファイルや秘密鍵を見ることはできないでしょう。

しかし、現在 PGP はUNIX や VAX/VMS のようなマルチユーザーシステムでも実行されています。マルチユーザーシステムでは、平文、鍵、パスワードが漏洩する危険は格段に増大します。UNIX システムの管理者や頭のよい侵入者であれば、平文ファイルを読むことができます。特殊なソフトウェアを使えば、キーボード操作をこっそり監視したり、画面に表示された内容を読んだりすることも可能です。UNIX システムでは、UNIX の ps コマンドを利用するだけで、ほかの人の環境情報をリモートに読むことができます。MS/DOS マシンでも、LAN に接続されている場合は、同様の問題が発生します。セキュリティに関する実際のリスクは、特定の状況によって左右されます。マルチユーザーシステムでは、安全性が確保される場合もあります。すべてのユーザーが信用できる場合、侵入者が実行できる攻撃を防御できるだけの十分な安全性を備えたシステムセキュリティ対策が講じられている場合、そして攻撃を行うことを考えているような侵入者が存在しない場合です。UNIX システムでも、ユーザーがひとりしかいない場合は安全です。UNIX が動作するようなノート型パソコンもあります。すべての UNIX システムで PGP を実行しないようにすることは、適切な処置であるとは言えません。

セキュリティに問題があるシステムに平文形式のデータが存在する場合、PGP はこのようなデータを保護することはできません。また、侵入者が高度な手段を使って、使用中の秘密鍵を読み取ることを防ぐこともできません。ユーザーは、マルチユーザーシステムにこのようなリスクが存在することを認識し、それに応じた意識や行動を心がける必要があります。独立したシングルユーザーシステムで物理的に直接管理できる環境以外では、PGP を実行しないことをお奨めします。私は、このようにしており、これをお奨めします。


トラフィック分析
----------------

暗号化されたメッセージの内容を読むことができない場合でも、メッセージの発信元や送信先、メッセージのサイズ、メッセージの送信日時を調べることによって、少なくとも何らかの役に立つ情報を推測することができるかもしれません。これは、会話の実際の内容がわからなくても、長距離電話の請求書を調べれば発信人、通話日時、通話時間がわかるのと同じです。これが、トラフィック分析と呼ばれる行為です。PGP だけで、トラフィック分析を防止することはできません。この問題を解決するには、暗号化技術を利用するなどして、ユーザーの通信環境におけるトラフィック分析への漏洩を軽減するような特殊な通信プロトコルが必要になります。