＃PGP セキュリティ
PGP は確かに問題を抱えたものになってしまいました1、私はそれを認めざるを得ません。それは不要な機能（実際には歴史的な遺物）が過度に統合され、危険な暗号プリミティブに対応し、複雑さが過剰で実装を妨げ、一部のプログラミング言語では十分なライブラリを提供できないほどです。
確かに、私は PGP がその目標を十分に受け継いだ実装が登場する前に失敗することを望んでいませんが、これらの問題を緩和することを考慮する必要があります。私がこれらの問題について簡単に議論することを許してください：
アルゴリズムと互換性の問題#
個人的には、キーの移行に関しては Curve 25519 への移行を合意によって実現することで緩和することができます（実際、最新の gpg のデフォルト設定は既にこれを行っています）- ソフトウェアは受け入れるかもしれませんが、人間は受け入れるべきではありません、少なくともそうすべきではありません。キーのアルゴリズム自体はその信頼性の一部です。おそらく gpg はさまざまな暗号プリミティブと曲線を提供し続けるかもしれませんが、それらの古い実装からできるだけ離れるべきです。たとえば、古い実装に対して警告を表示するなどの対策を講じるべきです（これはまだ不十分です）。
パケットの複雑さ#
この問題は歴史的な遺物のため解決策はありませんが、ネットワークの進歩を考慮すれば、適切な仕様があればセキュリティ上致命的な問題ではありません。
過剰な機能#
実際、これ自体が致命的ではありませんが、問題は各機能の切り離しと実装にあります。各機能が一組のキーペアにバインドされているため、共有のアイデンティティベースの暗号署名を提供しますが、互換性と統一された仕様の複雑さにより、各機能は専用のシステムに比べてより多くの攻撃面を持っています。完璧な既存の実装に完全に頼ることは不可能ですので、ある種の中間層を手動で導入することが必要かもしれません。
つまり、pgp の機能を使用して他のツールを導入し、実際の作業は他のツールで行うということです。例えば、pgp 署名を minsign 署名公開鍵の配布チャネルの一つとして使用することができます。
最終的な目標は、既存の機能を新しいレイヤーに置き換えるための仕様の移行ですが、おそらくその日は来ないでしょう...
ユーザーエクスペリエンス#
認めざるを得ないのは、PGP は複雑な使用方法を提供している一方で、十分に簡素化されたデフォルトの設定はありません。これは主に PGP が設計された身元確認ネットワーク（[Web of Trust](#Web of Trust)）のためであり、キーペア間の相互署名と過剰なメタデータがその目的の遺産です。
しかし、PGP は常に追加のセキュリティレイヤーです。それを通信ソフトウェアや暗号化ソフトウェアと比較することは適切ではありません。それらは組み込みのセキュリティに基づいて簡素化されていますが、全体的な問題を処理せず、一般的な機能を提供しません（一般的でセキュリティ自体は多少矛盾していますが）。
コマンドラインツールは常に恐ろしいものであり、GUI の開発は常に苦労しています（少なくとも私は GPG のほとんどの機能を実装した GUI を見たことがありません）。私は最近GpgFrontendという比較的新しい実装を見つけましたが、残念ながら、その人気は PGP が直面している状況を示しています。
私の知る限り、GUI のサポートにはさまざまな機能の不足がまだ存在しています。たとえば、サブキーエディタのサポートがほとんどない、鍵の生成機能が完全ではない、gpg のパス、ホームディレクトリ、サブキーのエクスポートなどのカスタマイズがほとんどありません。
複雑な機能を完全に実装し、同時に簡単なデフォルトの設定を提供するためには、さらなる開発が必要です。
長期的な鍵#
これは重要ではない、または私たちの一般的なセキュリティの考え方の中で最も絶望的なものです：私たちは頻繁にパスワードを変更するように助言されますが、これはユーザー側では不可能です。ユーザーが直接記憶に依存する秘密を頻繁に変更することはできません、これは人間の問題です。
新しい鍵を有効にするコストをできるだけ低く抑えるべきですが、これは信頼の問題であり、最終的にはユーザーの習慣に依存します。したがって、私の提案は鍵の有効期限を使用することであり、実際には本当に期限が切れるわけではありませんが、期限が切れる可能性があると仮定します。そして、更新時にリスクを評価します。それでも、配布の同期を確保するためには、1 つの方法では不可能です。
それに対応して、期限が切れた鍵を削除することを続けるべきです。それらに対するすべての信頼を保持しないでください。
一貫性のないアイデンティティ#
アイデンティティの配布メカニズムは一つではない可能性があります、これは事実です。現在、オフラインの交換や既存のキーサーバー、および信頼のウェブがすべてを提供できることを期待している人はいません。暗号化されたアイデンティティスキームは単なる基礎的な ID です：それ自体を証明することはできません。現在、人々はさまざまなネットワークサービスにわたるアイデンティティ証明を必要としており、その選択肢にはKeyoxideがあります。少なくともその考え方は可能性ですが、重要な点は次のとおりです：
-
私たちは実際に他のネットワークサービスを使用しています。メールのやり取りだけであれば、実際のオンラインアイデンティティは必要ありません。
-
これらのサービスは私たちが制御できないため、それらがどのように表示されるかを決定することはできません。私たちはさまざまな方法を具体的にサポートするだけです。
-
オンラインアイデンティティ自体は、連絡方法の一つにすぎず、真実の背後にあるアイデンティティは存在しません。
もちろん、彼らは元の pgp の方法を放棄する準備をしています。公開鍵のコメントにアイデンティティ情報を入れるのはばかげています。ただし、アイデンティティ配布システムは確かに実装されていませんが、仕様は既に存在していますが、エコシステムはまだ受け入れていません。
メタデータの漏洩#
PGP 自体の UID メタデータは明らかですが、これはその目的の一部です。ただし、キーサーバーがメタデータを取得すると、公開メタデータ情報が唯一のレベルになります。したがって、より良い選択肢は、PGP キーができるだけ少ない公開情報を持ち、それらを他のチャネル（Keyoxideのアイデンティティ）に分散させることです。
フォワードセキュリティの欠如#
これは注意が必要です。PGP を使用してメッセージを直接交換するのではなく、一度性会話鍵を交換する必要があります（もちろん、ユーザーに安全な交換を要求することは現実的ではありませんので、これを実現するためのツールが必要です）。ただし、より持続的な固定暗号化にはフォワードセキュリティの暗号化も必要です：時間を超えて送信する（笑
不器用な鍵#
形式の歴史的な遺物であり、ツールチェーンの改善に期待するしかありません。
ネゴシエーション#
過去 20 年間の暗号設計に関する 3 つの重要な教訓のうち、少なくとも 2 つはネゴシエーションと互換性は悪魔であるということです。暗号システムの欠陥はしばしば細部に現れ、主要な部分ではなく、広範な暗号の互換性は細部の数を増やします。
古いバージョンを断固として廃止する必要があります。ソフトウェアは受け入れるかもしれませんが、人間は受け入れるべきではありません、少なくともそうすべきではありません。
粗雑なコード#
GnuPG は PGP の有効なリファレンス実装であり、PGP 暗号を統合した多くの他のツールの基盤です。それはどこにも行かず、PGP に依存しています。
私たちが期待しているのはSequoia-PGPであり、これは上記のさまざまな問題の解決（少なくとも緩和）の期待があります。
信任のウェブ#
信任システムには常に 2 つのアイデアがあります。私たちは権威に基づく CA システムを持っていますが、PGP に基づく信任のウェブもあります。しかし、統一されたが信頼できる信任のウェブを現在の技術で構築する方法はまだ解決されていません。ソフトウェアパッケージの信頼に関しては、私が見たcargo-crevがありますが、これはまだ開発者の範囲内でのみ検討されており、一般ユーザーにとっては普及していません（ただし、私たちはすべて CA 証明書の欠点を知っています：Last Chance to fix eIDAS: Secret EU law threatens Internet security）。
PGP にはさまざまな問題があるかもしれませんが、そのアイデアは捨てることはできません。分散型の信頼を失った場合、Last Chance はヨーロッパだけでなく、ブラウザ証明書だけではありません...。