よくある質問
鍵長はどれくらいが必要ですか？
NIST SP 800-57 Part 1 Rev 5(2020 年)は目標有効期間を示しています。**2048 ビット** は 2030 年までの保護に許容(対称鍵 112 ビット相当)、**3072 ビット** は 2030 年以降も使用可(128 ビット相当)、**4096 ビット** は価値の高い鍵や長寿命の鍵向け(152 ビット相当)です。JWT 署名や短命の TLS には 2048 で十分です。10 年単位で持ち歩く SSH 鍵や CA ルートには 3072 か 4096 を選んでください。代償は検証速度です — 4096 ビットの署名検証は 2048 ビットより約 4 倍遅く、API 呼び出しごとに JWT を検証する場面では積み重なります。
RSA・ECDSA・Ed25519 — どれを選ぶべきですか？
両端を自分で制御する新規コードなら、**Ed25519** が既定です。鍵が小さく(32 バイト)、署名と検証が速く、ECDSA を破ってきた実装上の落とし穴(ナンス再利用など)に対しても堅牢です。**ECDSA P-256** は、NIST / FIPS 準拠が要求されて Ed25519 が承認外の場合の第二選択肢です。**RSA** はレガシー互換性で勝ちます — 古い TLS クライアント、ハードウェアトークン、古い OAuth プロバイダが公開する JWT JWK、ほぼすべての TLS 証明書チェーン — 加えて「誰でも扱い方を知っている」運用上の単純さもあります。相互運用性が決め手のときは RSA、選択の自由があるときは Ed25519 を選んでください。
同じ鍵を署名と暗号化の両方に使えますか？
機構的には可能で、RSA は両方をサポートします。しかし暗号学的・運用的にはやめるべきで、ベストプラクティス(NIST SP 800-57 Part 1 §5.6.3)は目的ごとに別の鍵を用意することです。同じ鍵で署名と暗号化を兼ねると攻撃面が広がります — 署名プロトコルの脆弱性が復号鍵の情報を漏らし得るし、その逆もあり得ます。JWT JWK が `use` フィールド(`sig` か `enc`)を明示的に持つのはこのためです。新規鍵では 2 つ生成し、それぞれにラベルを付けてください。
ブラウザで生成した鍵を実運用で使っても安全ですか？
低リスクな場面で使ってください。テスト用 JWT 署名、使い捨て VM の SSH 鍵、CI テスト用の一時 CA などです。`node-forge`(またはブラウザの WebCrypto)が使う CSPRNG は仕様が要求する `crypto.getRandomValues` で暗号学的に健全です。リスクは数学ではなく周辺環境にあります。侵害されたブラウザ拡張、改ざんされたスクリプトを差し込むネットワーク MITM、画面録画されたセッションなどから秘密鍵が漏れる可能性があり、エアギャップやハードニング済みマシン上の `openssl genrsa` ではこれらは起きません。本当に価値のあるものは対象マシンで生成し、秘密バイトを外に出さないでください。
SSH 鍵が必要です — 出力をそのまま `authorized_keys` に貼れますか？
直接は貼れません。`authorized_keys` は OpenSSH 形式(`ssh-rsa AAAAB3NzaC1yc2E... user@host`)を期待し、PEM ではないためです。変換するには、公開鍵 PEM を `key.pem` に保存し、`ssh-keygen -y -f key.pem > key.pub` で秘密鍵から OpenSSH 形式を導出するか、`ssh-keygen -i -m PKCS8 -f key.pem` で PEM 公開鍵から変換します。本当に SSH 用途なら最初から `ssh-keygen -t rsa -b 4096` で生成するのが簡単です。PEM の秘密鍵と OpenSSH の公開鍵を 1 回で得られます。
秘密鍵にパスフレーズを付けるべきですか？
ノート PC 上に置くローカル鍵にはパスフレーズを付けてください。PEM のバイト列が暗号化されるため、ディスクの盗難やファイルシステムバックアップの漏洩で鍵が直接渡ることがなくなります。一方、起動時に自動プロセスがロードするサーバ上のサービス鍵ではパスフレーズを付けないでください。同じプロセスから読める場所にパスフレーズを置く必要があり、本末転倒です。本ツールは暗号化なしの鍵を生成します。パスフレーズが必要ならコピー後に `openssl rsa -aes256 -in plain.pem -out encrypted.pem` を実行してください。
関連する概念
RSA(Rivest–Shamir–Adleman、1977 年、論文公開は 1978 年)は同じ鍵ペアで署名と暗号化を扱える非対称暗号です。安全性は 2 つの大きな素数の積を因数分解する難しさに依拠します。2048 ビット RSA 鍵は約 1024 ビットの素数 2 つの積で、その因数分解は現時点では実行不可能です。公開鍵は `(n, e)`(`e` はほぼ常に 65537)、秘密鍵は `e·d ≡ 1 (mod φ(n))` を満たす `d` を保持します。RSA の演算の大半は剰余冪乗計算で、非対称性は因数分解を知らずに `(n, e)` から `d` を導出することの難しさから生まれます。
同じ RSA 秘密鍵に対して **転送形式** が 2 種類あります。**PKCS#1**(`BEGIN RSA PRIVATE KEY`)は RSA 固有の元来の ASN.1 構造で、`modulus`・`publicExponent`・`privateExponent` などのフィールドを持ちます。**PKCS#8**(`BEGIN PRIVATE KEY`)は PKCS#1(または他のアルゴリズム)の塊をアルゴリズム非依存のエンベロープで包んだものです。PKCS#8 は現代の既定で、RSA・ECDSA・Ed25519 のいずれにも同じ鍵ファイル形式が使え、2010 年代後半以降の OpenSSL の既定出力でもあります。変換は鍵を再生成しません。ラッピングのバイトだけが変わります。
選択肢を形作る 3 つの隣接プリミティブがあります。**ECDSA**(楕円曲線デジタル署名アルゴリズム)は鍵長のごく一部で同等のセキュリティを得ます — 256 ビット ECDSA ≈ 3072 ビット RSA — が、ナンスの再利用で壊れやすく、過去にいくつかの実運用を破ってきました。**Ed25519**(Bernstein の twisted Edwards 曲線、RFC 8032)は両者の良さを兼ねた現代的選択肢で、鍵が小さく、演算が速く、ナンス再利用の地雷もありませんが、新しいぶん一部のレガシー環境では受け付けられません。**ポスト量子** アルゴリズム(KEM の CRYSTALS-Kyber、署名の CRYSTALS-Dilithium)は 2024〜2026 年に実運用へ入り始めています。十分に大規模な量子計算機が RSA・EC を破るためです。RSA は導入実績が膨大なため当面主流ですが、新規システムは Ed25519 を既定とし、次の 10 年で PQ 移行を計画してください。
