web-dev-qa-db-ja.com

（Open）PGPのECC

これまでの（Open）PGPでの [〜＃〜] ecc [〜＃〜] （楕円曲線暗号）のサポートはどうですか？ GnuPG （GNU Privacy Guard）には公式の実装がないようですが、 gnupg-eccプロジェクト を見つけました（ECC対応のGnuPG per RFC 6637）Googleコード：

このプロジェクトは、OpenPGPでの楕円曲線暗号化サポートをエンドユーザー機能として実現しました。ユーザーは、ECCキー生成オプションを選択するだけで

gpg2 --gen-key

次に、 here のように、通常は他の公開鍵を使用するのと同じように、生成された公開鍵を使用します。

SymantecがECCをサポートしていることを知っています。 ECCを使用しない理由はありますか？

[〜＃〜]編集[〜＃〜]

さらに調査を行ったところ、ECCはgnupgのメインラインに至るまでの長い道のりを再び繰り返したが、 開発者向けバージョン でのみであることがわかりました。

$ gpg2 --expert --gen-key
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Please select what kind of key you want:
    (1) RSA and RSA (default)
    (2) DSA and Elgamal
    (3) DSA (sign only)
    (4) RSA (sign only)
    (7) DSA (set your own capabilities)
    (8) RSA (set your own capabilities)
    (9) ECDSA and ECDH
   (10) ECDSA (sign only)
   (11) ECDSA (set your own capabilities)
Your selection?`
pgpecc
24
esskar

[〜＃〜] ecc [〜＃〜] を使用したくない理由は2つあります。

実用的な理由：通信には、必然的に送信側と受信側の2つのパーティが含まれます。 ECCは、送信側と受信側の両方がサポートしている場合にのみ使用できます。お気づきのように、既存のデプロイ済み実装は、必ずしもそれで十分ではありません。 ECC公開鍵を使用する場合、OpenPGP実装に関連コードが含まれている場合にのみ、その鍵で暗号化されたメッセージを送信したり、その鍵で署名を検証したりできます。

したがって、ECCを選択するかどうかは、相互運用性を最大化するか、または「早期導入者」を好むかによって異なります（ECCの場合、本当に早期導入者がすでに存在していますが、ECCが主流になりつつあります）。

道徳的な理由：数学的には、採用している暗号アルゴリズムのいずれかが攻撃に対して本当に堅牢であるという証拠はありません。数学的に攻撃に対して堅牢であるかどうかもわかりません。現在、暗号アルゴリズムの強度を評価する必要がある唯一の方法は、それを定義してから、多くの暗号技術者に数年間働きかけてもらうことです。これらの賢い人の誰もがアルゴリズムに問題を見つけなかった場合、アルゴリズムが弱い場合、少なくとも、それは明らかに弱いではありません。

楕円曲線は、1985年に暗号化に適したオブジェクトとして提案されました（KoblitzとMillerがそれぞれ独立）。楕円曲線の数学は、それ以前に約40年間研究されてきました。したがって、ECCは約70年間の暴露に耐えることができ、そのうち30年間は確実に暗号化された環境で使用されます。悪くない。

RSAの基礎となる整数因数分解 は、35年間の暗号化暴露（RSAは1978年に提案された）を誇り、百年以上2500年基礎となる数学のために。したがって、RSAのセキュリティは楕円曲線のセキュリティよりも「理解されている」と主張することができます。

個人的には、ECCは展開するのに十分成熟していると思います。ECCは非常にファッショナブルなので、実装が当たり前になり、GnuPGがすぐに機能することを期待できます。したがって、私の推奨は次のとおりです。数年間、相互運用性の問題に直面する準備ができている限り、ECCは問題ありません。

（ECC展開の1つのダークスポットは、「一般的な」ECC実装がほとんどないことです。ほとんどの実装は、サポートされている曲線の制限されたセットに固有です。多くの場合、2つのNIST P-256およびP-384曲線に制限されています。曲線の選択したがって、キーは相互運用性に大きな影響を与えます。ただし、セキュリティに関してはP-256で十分なので、使用して心配する必要はありません。）

25
Thomas Pornin

現在、ECCはGnuPG 2.1ベータでサポートされています。ソースからコンパイルして、次の曲線がサポートされていることを確認できます。

nistp256 nistp384 nistp521 brainpoolP256r1 brainpoolP384r1 brainpoolP512r1 secp256k1

9
Adrian

gPGでは、セキュリティのために、頭脳のプールやNistカーブから離れます。 edDSA、モンゴメリー、エドワーズの曲線は問題ありません。 ed25519は幸いなことに今のところ亜策なしで配備されています。

署名/認証/認証のためだけですが。暗号化が続きます。

ietf.orgのメーリングリストは、すばらしい開始点であり、cryp.toもチェックしています。

愚かな実装でのECCの使用は、RSAを使用するよりも悪いです。

6
Njomsky