OpenPGP

公開鍵のフィンガープリントは、公開鍵の短縮版です。フィンガープリントから、対応する正しい公開鍵を検証できます。C3A6 5E46 7B54 77DF 3C4C 9790 4D22 B3CA 5B32 FF66 のようなフィンガープリントは、名刺に印刷できます。^{[ 4 ] [ 5 ]}

OpenPGPが進化するにつれて、新しい機能やアルゴリズムをサポートするバージョンでは、古いOpenPGPシステムでは有効な秘密鍵を使っても復号できない暗号化メッセージを作成できます。そのため、OpenPGP通信のパートナーは互いの機能を理解するか、少なくともPGP設定について合意することが不可欠です。^{[ 6 ]}

バージョンコードの一覧については、下記の§バージョン履歴を参照してください。

PGP はメッセージを機密に送信するために使用できます。^{[ 7 ]}このため、PGP は対称鍵暗号化と公開鍵暗号化を組み合わせたハイブリッド暗号システムを使用します。メッセージは、送信者によって生成された対称鍵を必要とする対称暗号化アルゴリズムを使用して暗号化されます。対称鍵は一度だけ使用され、セッション鍵とも呼ばれます。メッセージとそのセッション鍵は受信者に送信されます。受信者がメッセージを復号する方法を知るためにセッション鍵を送信する必要がありますが、送信中に保護するために、受信者の公開鍵で暗号化されます。受信者に属する秘密鍵のみがセッション鍵を復号し、それを使用してメッセージを対称的に復号できます。

PGPは、デジタル署名によるメッセージ認証をサポートしており、メッセージが送信者とされる人物または組織によって実際に送信されたかどうかを検証できます。送信者はPGPを使用して、サポートされている複数の公開鍵アルゴリズムのいずれかを用いてメッセージのデジタル署名を作成します。そのためには、PGPは平文からハッシュ値（ダイジェスト）を計算し、送信者の秘密鍵を使用してそのハッシュ値からデジタル署名を作成します。

メッセージの暗号化と署名の検証の両方において、メッセージを送信するために使用される公開鍵が、実際に意図された受信者に「属している」ことが極めて重要です。どこかから公開鍵をダウンロードするだけでは、その関連性を確実に保証することはできません。意図的（または偶発的）ななりすましは起こり得ます。PGPは最初のバージョンから、ユーザーの公開鍵を「ID証明書」として配布する機能を備えており、この証明書も暗号学的に構築されているため、改ざん（または偶発的な文字化け）は容易に検出できます。しかし、検出されずに変更できない証明書を作成するだけでは不十分です。これは証明書が作成された後の改ざんを防ぐことはできますが、作成前には防げません。ユーザーは、証明書内の公開鍵が実際にそれを主張する個人または組織に属していることを何らかの方法で確認する必要があります。特定の公開鍵（より具体的には、ユーザー名と鍵を関連付ける情報）は、第三者のユーザーによってデジタル署名され、個人（実際にはユーザー名）と鍵との関連性を証明することができます。このような署名には、いくつかの信頼度レベルを含めることができます。多くのプログラムはこの情報を読み書きしますが、鍵を信頼するかどうかを計算する際に、このレベルの認証情報を含めるプログラムはほとんどありません（あるいは皆無です）。

信頼のウェブプロトコルは、1992年にフィル・ジマーマンによってPGPバージョン2.0のマニュアルの中で初めて記述された。

時間が経つにつれて、あなたは信頼できる紹介者として指定したい他の人々から鍵を蓄積していくでしょう。他のすべての人はそれぞれ、信頼できる紹介者を選びます。そして、誰もが徐々に他の人々からの認証署名のコレクションを自分の鍵とともに蓄積し、配布していきます。受け取った人は、少なくとも1つか2つの署名を信頼するだろうという期待のもとに。こうして、すべての公開鍵のための分散型で耐障害性の高い信頼のネットワークが出現するでしょう。

信頼のウェブメカニズムは、S/MIMEなどで使用されているような中央集権型の公開鍵基盤（PKI）方式に比べて利点があるものの、広く普及しているとは言えません。ユーザーは証明書を受け入れ、その有効性を手動で確認するか、あるいは単に証明書を受け入れるしかありません。根本的な問題に対する満足のいく解決策はまだ見つかっていません。

（より新しい）OpenPGP仕様では、信頼署名を使用して認証局の作成をサポートできます。信頼署名は、鍵が主張されている所有者に属していることと、鍵の所有者が自分より1つ下のレベルの他の鍵に署名するのに十分な信頼性があることの両方を示します。レベル0署名は、鍵の有効性のみが証明されるため、信頼のウェブ署名に相当します。レベル1署名は、認証局に対する信頼に似ています。レベル1に署名された鍵は、無制限の数のレベル0署名を発行できます。レベル2署名は、デフォルトの認証局リスト（Webブラウザに含まれているものなど）を使用する際にユーザーが頼らなければならない信頼の前提と非常によく似ています。これにより、鍵の所有者は他の鍵を認証局にすることができます。

(Open)PGPの各バージョンには、公開鍵証明書を無効化（失効）する機能が常に含まれていました。秘密鍵を紛失または侵害した場合、ユーザーが通信の安全性を維持するためには、この機能が必要となります。これは、中央集権型PKIスキームの証明書失効リストとほぼ同等の機能です。最近のOpenPGPバージョンでは、証明書の有効期限もサポートされています。

公開鍵が特定のユーザーに属することを正しく識別するという問題は、PGPに限ったことではありません。公開鍵／秘密鍵暗号システムはすべて、多少形は違えど同じ問題を抱えており、完全に満足のいく解決策は知られていません。OpenPGPの信頼のウェブ方式は、少なくともその承認／検証システムを使用するかどうかの決定をユーザーに委ねていますが、他のほとんどのPKI方式はそうではなく、中央認証局によって証明されたすべての証明書を正しいものとして受け入れることを要求しています。

オープンソースのオフィススイートであるLibreOfficeは、 Linux版5.4.0以降、OpenPGPによる文書署名を実装した。^{[ 15 ]}

PGPキーは、Mozilla Thunderbird（PC版バージョン78以降に内蔵^{[ 16 ]}、Android版バージョン9以降のOpenKeychainアプリ^{[ 17 ]}）、GitHub ^{[ 18 ]}、GitLab ^{[ 19 ]}でサポートされています。

OpenPGP の作成のきっかけは、1996 年に PGP Inc. が Viacrypt に合併された後、RSADSIがViacrypt の RSA ライセンスを新しく合併した会社に継続することに異議を唱えたことから始まった。同社は「ライセンス上の問題のあるアルゴリズムを使用しない」という「制約のない PGP」と呼ばれる非公式の内部標準を採用した。PGP 暗号化は世界的に重要であるため、多くの人が PGP 5 と相互運用できる独自のソフトウェアを作成したいと考えていた。Zimmermann は、 PGP 暗号化のオープン標準が自分たちにとって、そして暗号コミュニティ全体にとって重要であると確信するようになった。1996 年 8 月、Atkins、Stallings、Zimmerman は IETF にRFC 1991を「PGP メッセージ交換フォーマット」という情報文書として公開させた。この文書は PGP バージョン 2.x (パケット バージョン 2 および 3) について説明した。^{[ 20 ]} 

1996年10月のRFC 2015という最新の仕様では、PGPメッセージを電子メールに埋め込む方法であるPGP/MIMEが規定されている。 

1997年7月、PGP Inc.はIETFに対し、OpenPGPという標準規格を提案した。PGP Inc.はIETFに対し、この新しい標準規格、およびその標準規格をサポートするあらゆるプログラムを説明するためにOpenPGPという名称を使用することを許可した。IETFはこの提案を受け入れ、OpenPGPワーキンググループを発足させた。この取り組みは1998年11月のRFC 2440で結実し、さらにプロトタイプ段階にあった「PGP 3」（パケットバージョン4）で使用されるフォーマットについても記述した。^{[ 21 ]} 

次の標準である2007年11月のRFC 4880は、パケットのバージョン番号(4)を変更せずにRFC 2440を改訂しました。これは、「PGP 3」のリリースバージョンであるPGP 5.xを説明することを目的としています。^{[ 22 ]} 

この時期には、RFC 5581（「OpenPGPにおけるカメリア暗号」）およびRFC 6637（「OpenPGPにおける楕円曲線暗号（ECC）」）の形で、新しい暗号方式もOpenPGPに統合されました。

2015年から、OpenPGP WGでは、GnuPGの作者であるWerner Kochが最初に始めたプロジェクトである4880bisというリポジトリで更新された文書の作業が進められています。これはパケットバージョン5について説明しています。^{[ 23 ]} LibrePGPウェブサイトのタイムラインによると、このドラフト群で定義されている4880bis「バージョン5」のサポートは、2018年初頭にRNPとGnuPG 2.3の実験ブランチですでに実装されており、2020年7月のGnuPG 2.0で製品品質のコードとしてリリースされました。^{[ 24 ]}

2021 年 1 月に OpenPGP WG は、新しい「crypto-refresh」文書で示される新しい編集戦略に切り替えました。これは、4880 のテキストから始まり、一連のマージ要求で新しい仕様に修正されるというものです。^{[ 25 ]} 2022 年 9 月に Koch は、crypto-refreshとは別のブランチとしてdraft-koch-openpgp-2015-rfc4880bis-00を作成しました。概要セクションで Koch は、 crypto-refresh の後に発生したマージ要求は「主に議長の 1 人によって事前に準備された」ものであり、draft-ietf-openpgp-rfc4880bis-10は「基本的に最終コールの準備ができていた」ため、リファクタリングは不要であると説明しました。^{[ 26 ]}

2022 年 11 月、crypto-refresh は、Koch のブランチの「バージョン 5」との初期の非互換性の 1 つは v3 署名との混同を避けるために、「バージョン 5」署名フォーマットを変更しました。^{[ 27 ]} 2023 年 2 月、crypto-refresh は、「IANA 登録を取得せずにバージョン 5 コードポイントを占有しているソフトウェアとの衝突を避ける」ために、「バージョン 5」を「バージョン 6」に番号変更しました。これは、古い 4880bis で定義されている「バージョン 5」を実装するソフトウェアを指しています。^{[ 28 ]} 2023 年後半、Koch と OpenPGP WG の間で公然とした対立が発生し、Koch は「4880bis」の自身のバージョンを LibrePGP と改名し、GnuPG はcrypto-refreshに基づく将来の仕様をサポートしないと発表した。Koch は、より段階的なアプローチの方が合理的だと考えている。^{[ 24 ]}

crypto-refreshの最終版であるRFC 9580は、 2024年7月に公開されました。 

さらに、OpenPGP（PGP/MIMEを含む）は、NIST特別刊行物800-177 「信頼できる電子メール」を含む、多くの派生規格や関連規格で参照されています。

2017年10月、ROCA脆弱性が発表されました。これは、 OpenPGPでよく使用されるYubiKey 4トークンで使用されているバグのあるInfineonファームウェアによって生成されたRSAキーに影響します。公開されている多くのPGPキーが脆弱であることが判明しました。^{[ 29 ]} Yubicoは、影響を受けるトークンの無償交換を提供しています。^{[ 30 ]}

2018 年 5 月、 EFAILというバグが2003 年以降の PGP/MIME の特定の実装に存在することが発見されました。^{[ 31 ] [ 32 ]}このバグにより、暗号化された電子メールの前後にコンテンツを挿入することが可能になり、一部の HTML コードでは、平文がリモート サーバーに送信される可能性があります。^{[ 33 ]} OpenPGP 仕様も PGP/MIME 仕様も破損していません。^{[ 34 ]}

前述の通り、Werner Koch はOpenPGP 標準を LibrePGP にフォークし、RFC 9580 に対する批判を Web サイトで列挙しています。これには、「アルゴリズムの増殖」（新しい必須アルゴリズムの追加）、4880bis に存在するファイル名署名メカニズムの削除、および 2 つのメタデータ フラグの削除が含まれます。^{[ 43 ]} LibrePGP は、4880bis の初期実装者である GnuPG と RNP によって実装されています。RNP は、LibrePGP の方向性を称賛する別の発表を公開しました。^{[ 44 ]}

アンドリュー・ギャラガーは2024年にウェブページを公開し、LibrePGPに対する2つの理論的な攻撃と1つの実際的な攻撃を列挙した。これには、分裂後にcrypto-refreshフォークで修正された前述のバージョンの混乱も含まれる。 ^{[ 45 ]}もう1つの理論的な攻撃は、従来のOpenPGP/LibrePGPとCMS（ S/MIMEの中核）の両方に影響を与えた。^{[ 46 ]}