Skip to content

無料オンライン RSA 鍵ペア生成 — ECDSA・Ed25519

RSA 鍵ペアをオンラインで生成。秘密鍵はブラウザから出ません。2048/4096・ECDSA・Ed25519、PKCS#8 / PKCS#1 PEM 対応。

トラッキングなし ブラウザで動作 無料
鍵ペアは Web Crypto API を使ってブラウザ内で生成され、生成中にネットワークリクエストは発生しません。接続を切ってもこのページは動作します。

PKCS#8(BEGIN PRIVATE KEY)がモダンな既定で、JDK が期待する形式です。PKCS#1(BEGIN RSA PRIVATE KEY)は OpenSSL の従来形式で、一部のゲートウェイでは今も必須です。切り替えても同じ鍵を符号化し直すだけです。

秘密にしてください。これを持つ者は誰でもあなたになりすませます。

公開鍵のフィンガープリント — SPKI DER の SHA-256
JWK(JSON Web Key)
秘密鍵の JWK — こちらは決して公開しないこと
 
公開鍵の JWK
 

OpenSSL で同じ種類の鍵ペアを生成する

RFC 5958/5208(PKCS#8)、RFC 8017(PKCS#1)、RFC 8410(Ed25519)、RFC 7468 の PEM 符号化の正しさ、および RSA・ECDSA・Ed25519 にわたる Web Crypto API の挙動についてレビュー済み。 — Go Tools セキュリティツールチーム · Aug 10, 2026

当チームは PKCS#8 から PKCS#1 への変換を Node の crypto モジュールの参照出力とバイト単位で照合しているため、ここで書き出した鍵は同じ鍵素材から OpenSSL が生成するものと同一です。

RSA 鍵ペア生成ツールとは?

RSA 鍵ペア生成ツールは、数学的に結び付いた 1 組の鍵、つまり手元に保管する秘密鍵と、配布する公開鍵を作ります。秘密鍵で署名したものは公開鍵で検証でき、公開しても安全なのは公開鍵のほうだけです。この非対称性こそが要点で、検証する側に偽造の能力を与えないまま署名を確認させられます。共有シークレットには決してできないことです。

本ツールは Web Crypto API を通じてブラウザ内で動作するため、秘密鍵はタブの中で作られ、生成中にネットワークリクエストは発生しません。RSA に加えて ECDSA と Ed25519 の鍵ペアも生成でき、いずれもはるかに短い鍵で同じ目的を果たします。Ed25519 の秘密鍵は PKCS#8 で 48 バイト、2048 ビットの RSA 鍵は 1.2 KB を超えます。

つまずくのは数学ではなく梱包のほうです。同じ鍵が PKCS#8・PKCS#1・SPKI・JWK のいずれでも書けてしまい、片方を拒否するライブラリがもう片方は受け付ける、しかもメッセージはパースエラー以上に具体的にならない、ということが起こります。下の表は、それぞれのコンテナがどの生態系で期待されるかを対応付けたものです。

// Verify a downloaded key pair matches, using OpenSSL:
openssl pkey -in rsa-2048-private.pem -pubout | diff - rsa-2048-public.pem
// No output means the public key really belongs to that private key.

主な機能

ブラウザ内で生成

鍵はあなた自身のタブ内の Web Crypto API から生成され、生成中にネットワークリクエストは発生しません。接続を切っても動き続けることが、このツールが仕事をするのにサーバーを必要としないことを示しています。

RSA・ECDSA・Ed25519

RSA 2048・3072・4096、ECDSA の P-256・P-384・P-521、そして Ed25519 を、同じページの同じ書き出しオプションで扱えます。

PKCS#8 と PKCS#1 の出力

OpenSSL に触れることなく BEGIN PRIVATE KEY と従来型の BEGIN RSA PRIVATE KEY を切り替えられます。この切り替えは画面にある鍵を符号化し直すだけなので、同じ鍵のままです。

JWK での書き出し

秘密鍵・公開鍵とも JSON Web Key 形式で取得できます。JWKS 文書や JOSE の検証側に入れるのは公開鍵の JWK です。秘密鍵の JWK は署名側だけのもので、決して公開してはいけません。

SHA-256 フィンガープリント

すべての鍵ペアに公開鍵のフィンガープリントが付くので、双方が同じ鍵を持っていることを別経路で検証できます。

対応する OpenSSL コマンド

同じ種類の鍵をローカルで生成するための同等のコマンドが出力の下に表示されるので、好きなタイミングでコマンドラインへ移れます。

分かりやすい名前でのダウンロード

ファイルは rsa-2048-private.pem と rsa-2048-public.pem として保存され、後から名前を付け直す必要のある汎用名にはなりません。

アカウント不要・レート制限なし

サーバーが介在しないので、登録するものも、使い切る割り当てもありません。

実践例

Ed25519 の鍵ペア(全文)

Algorithm: Ed25519
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEIA2HJVU1qChbOJN8XksXVhyD0IjYVt0UU6Mwz814rOFf
-----END PRIVATE KEY-----

-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAV5uB7UaPJrtncx3SXNtNzn1ZXjF1ApwvzBZ8nFzT5eU=
-----END PUBLIC KEY-----

Ed25519 の秘密鍵は PKCS#8 で 48 バイト、公開鍵は 44 バイトなので、どちらの PEM も base64 が 1 行に収まります。これは使い捨てのデモ用ペアです。コピーせずご自分で生成してください。

PKCS#8 と PKCS#1 のヘッダーの違い

Algorithm: RSA 2048, structure toggled
PKCS#8:  -----BEGIN PRIVATE KEY-----
PKCS#1:  -----BEGIN RSA PRIVATE KEY-----

同じ鍵を包む 2 つの容器です。PKCS#8 は RSA の構造の外側にアルゴリズム識別子を付けるため、あらゆるアルゴリズムに使えます。一方 PKCS#1 は RSA のためだけに存在します。トグルの切り替えは画面にある鍵を符号化し直すだけなので、フィンガープリントは変わりません。

RSA 2048 の公開鍵

Algorithm: RSA 2048
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuvUHLjyK9zje2aaNIni
eSccN1uleXFRBb1g2TN6bk/fbpPCGDyh71m73oB9Bk8+fKVkSThXyWTtpgblB7pX
iQBtTvSWVZGHprkLgMGkU2Yw8Z43m1WpoRuYyXNFe92S5viIdVuKTj/VEUuEpzHd
ffWMIUw70LaUdTP04iQdkNVeS3M6VHkpTwsPSQfsFSwObtLVNy2Lf+ODwJRqCk2r
C749hgKqBdJqkcIj49R7UP4SMQ/9V3yy8DFMrIcgsjC4tHwlQSCGeXNxTNlapGSa
ke55LUR83FASryVJRbUs678SCZSFkyGcT0qLZ/olu/e7Jj2lB0Qy/SJawkrs9hPE
4QIDAQAB
-----END PUBLIC KEY-----

先頭の MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A は rsaEncryption のアルゴリズム識別子で、RSA の SPKI 公開鍵はこれを見れば一目で見分けられます。

公開鍵の JWK 表現

Algorithm: Ed25519, JWK panel
{
  "key_ops": [
    "verify"
  ],
  "ext": true,
  "alg": "Ed25519",
  "crv": "Ed25519",
  "x": "V5uB7UaPJrtncx3SXNtNzn1ZXjF1ApwvzBZ8nFzT5eU",
  "kty": "OKP"
}

これは書き出しをそのまま載せたもので、Web Crypto が必ず付与する key_ops と ext のメンバーも含まれています。JWKS のエントリーにこれらは不要です。両方を削り、代わりに kid と use を加えれば、検証側がローテーション中に正しい鍵を選べます。Ed25519 は OKP 鍵タイプに入り、RSA 鍵は kty が RSA で n と e のメンバーを持ちます。

SHA-256 フィンガープリント

Algorithm: Ed25519
SHA256(SPKI) = KAXVxapxpG4zLsTVMpPafovT+X1NLWc8fsOXqtrb59o=

公開鍵構造の SHA-256 ダイジェストで、電話で読み上げられる程度に短いものです。これは ssh-keygen が表示する値ではない点に注意してください。OpenSSH は独自のワイヤ形式をハッシュするため、同じ鍵でも両者が一致することはありません。

RSA 鍵ペア生成ツールの使い方

  1. 1

    アルゴリズムを選ぶ

    RSA は対応するレガシーシステムの幅が最も広く、ECDSA ははるかに短い鍵で同等の強度を得られます。Ed25519 は新規の署名用途におけるモダンな既定です。

  2. 2

    鍵長を選ぶ

    RSA 2048 は現行のガイダンスを満たし、3072 と 4096 は長期間使う鍵に余裕を持たせます。ECDSA は P-256・P-384・P-521 から選べます。Ed25519 の長さは 1 つに固定です。

  3. 3

    PEM 構造を選ぶ

    PKCS#8 は BEGIN PRIVATE KEY を出力し、JDK を含めほぼどこでも通ります。BEGIN RSA PRIVATE KEY を明示的に要求されたときだけ PKCS#1 に切り替えてください。

  4. 4

    両方の鍵をコピーまたはダウンロードする

    秘密鍵はシークレットストアへ、公開鍵は署名を検証する相手へ渡します。秘密鍵のほうはどこへも送らないでください。

  5. 5

    フィンガープリントを照合する

    SHA-256 フィンガープリントを別経路で比較し、相手が導入したのが確かにあなたの生成した公開鍵であることを確認します。

よくある鍵フォーマットの間違い

秘密鍵を置く場所に公開鍵を貼った

署名には秘密鍵のほうが必要です。秘密鍵を期待しているライブラリに BEGIN PUBLIC KEY を渡すと、たいていは本当の問題を名指ししない役に立たないパースエラーが返ってきます。

✗ 誤り
-----BEGIN PUBLIC KEY-----
✓ 正しい
-----BEGIN PRIVATE KEY-----

ライブラリに合わない PEM 構造

従来型の RSA レイアウトしか読まない生態系はごく一部です。OpenSSL 自身の -traditional 出力、一部の決済ゲートウェイ SDK、古い Ruby や Perl のツールなどがそれにあたります。モダンなライブラリの大半、とりわけ JDK は PKCS#8 を期待します。変換コマンドを探すのではなく、PEM 構造のトグルを切り替えてください。

✗ 誤り
-----BEGIN RSA PRIVATE KEY-----
✓ 正しい
-----BEGIN PRIVATE KEY-----

末尾の改行を失った

PEM ファイルは最後の区切り行のあとに改行が入ります。空白を切り詰めるフォームフィールドを経由してコピーすると、一部のパーサーが即座に拒否するファイルになります。しかも欠けた文字は目に見えないので、エディタ上では正しく見えてしまいます。

✗ 誤り
-----END PRIVATE KEY-----[EOF]
✓ 正しい
-----END PRIVATE KEY-----↵[EOF]

転送の途中で 1 文字失われた

PEM を壊すのは行幅ではなく、失われた・挿入された・置き換わった文字です。ほとんどのパーサーは折り返し方を問いません。チャットクライアントやフォームフィールド越しのコピーは改行を静かに空白へ変えてしまうことがあり、base64 はどの文字が壊れたか手掛かりを与えないので、鍵は単に読み込めなくなります。手で選択せずコピーボタンを使ってください。

✗ 誤り
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuvUHLjyK9zje2aaNIni eSccN1uleXFRBb1g2TN6bk
✓ 正しい
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuvUHLjyK9zje2aaNIni
eSccN1uleXFRBb1g2TN6bk

RS256 の設定に HS256 のシークレットを使った

HS256 は共有シークレット 1 つ、RS256 は鍵ペアを使います。ランダムな文字列を RS256 の署名処理に渡すとパースの段階で失敗します。ここで鍵ペアを生成するか、HS256 のつもりだったならJWT シークレット生成ツールをお使いください。

✗ 誤り
alg: RS256, key: 8f3a9c2e1b7d
✓ 正しい
alg: RS256, key: -----BEGIN PRIVATE KEY-----

authorized_keys に PEM を貼った

SSH の公開鍵は OpenSSH の 1 行形式(ssh-ed25519 AAAA…)であって PEM ブロックではないので、このページの公開鍵を authorized_keys に貼っても動きません。RSA 鍵なら ssh-keygen -y でローカルに正しい行を導出できます。SSH アクセス全般については、対象マシン上で生成するほうがなお良い方法です。

✗ 誤り
-----BEGIN PUBLIC KEY-----
✓ 正しい
ssh-keygen -y -f rsa-2048-private.pem > id_rsa.pub

このツールを使う人

RS256 や EdDSA で JWT に署名する
非対称の JWT アルゴリズムは共有シークレットではなく鍵ペアを必要とします。秘密鍵で署名して公開鍵を公開すれば、検証側はトークンを発行できる材料を一切持ちません。JWT エンコーダーはこのページが生成した鍵をそのまま受け付けます。
Webhook やリリース成果物に署名する
公開鍵を一度公開しておけば、あとはすべてのペイロードを秘密鍵で署名でき、消費側は漏洩しうる共有クレデンシャルなしで真正性を検証できます。
ローカル開発とテスト
署名検証を通すテストには使い捨ての鍵ペアが要ります。ここで生成するほうが、OpenSSL の呼び出し方を思い出すより速いはずです。
鍵ペアの姿を学ぶ
アルゴリズムと PEM 構造を並べて切り替えると、仕様書を読むだけでは掴めない違いが具体的に見えてきます。
JWKS エンドポイントを用意する
公開鍵の JWK は、OpenID Connect のディスカバリー文書の keys 配列にそのまま入ります。ローテーション中に検証側が選べるよう kid を加え、秘密鍵の JWK はそのファイルに入れないでください。
RSA から移行する
RSA の元の鍵の隣に Ed25519 の置き換え候補を生成し、サイズを見比べてから切り替えを決められます。
形式の不一致を直す
ライブラリがパースエラーで鍵を拒否したときは、もう一方の PEM 構造で書き出し直すだけで解決することがほとんどです。

PEM 形式と生成ツールの仕組み

どのコンテナをどこで使うか
1 つの鍵に 5 通りの包み方があります。選び間違いは鍵が拒否される最大の原因ですが、エラーメッセージがパース失敗より具体的になることはめったにありません。
コンテナPEM ヘッダー格納するもの登場する場所
PKCS#8BEGIN PRIVATE KEYすべてのアルゴリズムWeb Crypto、JDK、Go、.NET——モダンなライブラリの大半
PKCS#1BEGIN RSA PRIVATE KEYRSA のみOpenSSL の従来出力、一部の決済ゲートウェイ、古い Ruby / Perl のツール
SPKI / X.509BEGIN PUBLIC KEYすべてのアルゴリズム、公開鍵側ほぼすべてのライブラリが期待する公開鍵
PKCS#1 publicBEGIN RSA PUBLIC KEYRSA のみ、公開鍵側レガシーな RSA ツール
JWKなし——JSON であるすべてのアルゴリズムJWKS エンドポイント、OIDC ディスカバリー、JOSE ライブラリ
手元にあるファイルを変換するには、openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem が一方向、openssl rsa -traditional -in pkcs8.pem -out pkcs1.pem が逆方向です。
乱数は OS から供給される
Web Crypto の鍵生成は、プラットフォームのエントロピー源から種を得ます。Linux では getrandom、Windows と macOS ではそれぞれのシステム CSPRNG です。OpenSSL が汲むのと同じ種類の源であり、JavaScript の擬似乱数生成器ではありません。
生成中もページは固まらない
crypto.subtle.generateKey は非同期で、主要なブラウザエンジンでは素数の探索がメインスレッドの外で行われるため、4096 ビットの法を探している間も UI は応答し続けます。それでもページはスピナーを表示します。探索にどれだけかかるかは運次第だからです。
PKCS#8 は PKCS#1 を包んでいる
PKCS#8 の PrivateKeyInfo はバージョン番号・アルゴリズム識別子・OCTET STRING で構成されます。暗号化されていない rsaEncryption 鍵では、その OCTET STRING の中身が完全な PKCS#1 RSAPrivateKey であり、本ページはまさにこの性質を使って、何も導出し直すことなく両者を変換しています。
公開鍵は SubjectPublicKeyInfo を使う
BEGIN PUBLIC KEY は X.509 の SubjectPublicKeyInfo、つまりアルゴリズム識別子と BIT STRING の組です。そのビット列に何が入るかはアルゴリズム次第で、RSA なら PKCS#1 の RSAPublicKey(BEGIN RSA PUBLIC KEY のほうが短いのはこのため)、ECDSA なら非圧縮の曲線点、Ed25519 なら 32 バイトの生の鍵です。
公開指数は 65537
ここで作られる RSA 鍵はすべて e = 65537(0x010001)を使います。小さい指数への攻撃を避けられる程度に大きく、かつ立っているビットが 2 つだけなので、検証は 16 回の二乗と 1 回の乗算で済みます。
フィンガープリントは PEM ではなく DER を要約する
SHA-256 フィンガープリントはバイナリの SubjectPublicKeyInfo に対して計算されます。base64 のテキストを対象にすると、改行の折り返し方が変わるたびに値が変わってしまいます。ローカルでの同等の手順は openssl pkey -in private.pem -pubout -outform DER | openssl dgst -sha256 -binary | openssl base64 です。

鍵管理のベストプラクティス

鍵は使う場所で生成する
ネットワークを渡った秘密鍵は、その経路上のすべてのホップに晒されたことになります。ブラウザで生成すれば鍵そのものはネットワークに乗りません。ただしページのコード自体はネットワーク越しに届いています。対象ホスト上で生成すればコピーの手順すら不要です。本番システムを守る鍵なら、ホスト側での生成を選んでください。
RSA が必須でない限り Ed25519 を選ぶ
Ed25519 は 32 バイトの鍵で強固な安全性を与え、署名が速く、設定を誤りうるパラメータもありません。取引先や古いライブラリに選択の余地を奪われたときに RSA を使ってください。
2048 ビットを下限とみなす
NIST SP 800-131A は 2013 年以降、署名生成における 2048 ビット未満の RSA を許可していません。公的な認証局も、それより短い鍵に証明書を発行しません。長年運用し続ける見込みの鍵には 3072 か 4096 を選んでください。
秘密鍵を絶対にコミットしない
秘密鍵はシークレットマネージャーか、実行時に読み込む環境変数に置いてください。いったんリポジトリに入った鍵は、ローテーションだけが安全な対処です。
インシデント後だけでなく計画的にローテーションする
古い鍵を引退させる前に鍵 ID を付けた新しい公開鍵を公開しておけば、検証側は重複期間中に両方を受け入れられます。日常的に練習したローテーションだけが、いざというときに機能します。

よくある質問

ウェブサイト上で秘密鍵を生成しても安全ですか?
鍵はお使いのブラウザ内の Web Crypto API が生成し、このページは生成中にネットワークリクエストを行いません。ネットワークパネルを見ていても確認できますし、接続を切っても生成が動くことでも確かめられます。ただし、それが何を示して何を示さないかははっきりさせておきましょう。示しているのはこのページがサーバーを必要としないことであって、スクリプトが改ざんされていない証明にはなりません。JavaScript は訪問のたびに当方のサーバーから取得され直すからです。残るリスクはネットワークではなくブラウザ側のものです。悪意のある拡張機能はページとクリップボードを読めますし、マシンに触れられる人はダウンロードしたファイルを読めます。本番システムを守る鍵は、それを使うホスト上で生成してください。下の OpenSSL コマンドがまさにそれを行います。このページは開発・テスト・学習、そしてブラウザ生成の鍵で問題ない場面に適しています。
PKCS#8 と PKCS#1 の違いは何ですか?
同じ RSA 鍵に対する 2 つの容器です。BEGIN RSA PRIVATE KEY と記される PKCS#1 は RSA の数値をそのまま格納し、RSA のためだけに存在します。BEGIN PRIVATE KEY と記される PKCS#8 は、同じ数値をアルゴリズム識別子で包むので、1 つの形式で RSA・ECDSA・Ed25519 のいずれも運べます。モダンなライブラリの大半は PKCS#8 を期待し、とりわけ JDK は追加ライブラリなしでは PKCS#8 しか読みません。一方で多くの決済ゲートウェイや OpenSSL 時代の古いツールは今も PKCS#1 を要求します。このページのトグルを切り替えると画面にある鍵が符号化し直されるだけなので、情報が増えることも失われることもなく、フィンガープリントも変わりません。
PKCS#1 の鍵を PKCS#8 に、またはその逆に変換するには?
このページの PEM 構造のトグルを切り替えれば、同じ鍵がもう一方のコンテナで書き出されます。すでに手元にあるファイルなら OpenSSL がローカルで変換します。openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem は BEGIN RSA PRIVATE KEY のファイルを BEGIN PRIVATE KEY に変え、openssl rsa -traditional -in pkcs8.pem -out pkcs1.pem は逆方向です。どちらの方向でも鍵素材が足されたり削られたりすることはなく、変わるのは外側の包みだけです。だからこそ両方のファイルは同一の鍵を表し、フィンガープリントも同一になります。
RSA の秘密鍵から公開鍵を取り出すには?
公開鍵は秘密鍵から導出できますが、その逆は決してできません。このページは両方を同時に表示するので、導出する必要はありません。すでにディスク上にある秘密鍵からなら、openssl pkey -in private.pem -pubout -out public.pem が対応する BEGIN PUBLIC KEY ファイルを書き出します。これは 1 組の鍵が本当に対になっているかを確かめる方法でもあります。公開鍵側を作り直し、渡されたファイルと突き合わせてください。
RSA と Ed25519 のどちらを選ぶべきですか?
制約がないなら Ed25519 です。32 バイトの鍵で RSA 3072 に匹敵する強度に達し、署名が速く、設定を誤るパラメータもありません。取引先・認証局・古いライブラリが要求する場合は RSA を選びます。企業システムや決済システムでは今も一般的です。ECDSA はその中間で、TLS で広く対応されています。
2048 ビットの RSA はまだ十分強いですか?
今日のほとんどの用途では十分です。NIST は 2048 ビット RSA を 112 ビットのセキュリティ強度と評価し、SP 800-57 では 2030 年まで有効としています。3072 ビットは 128 ビット強度に達し、それ以降について NIST が指し示す水準です。つまり、数年以内にローテーションするものには 2048、2030 年代も現役で使う見込みの鍵や認証局が要求する場合には 3072 か 4096 です。大きな鍵の代償は署名の遅さと署名サイズの増加であり、安全性の低下ではありません。
この鍵で JWT に署名できますか?
できます。RSA 鍵は RS256・RS384・RS512 と PSS 系の各方式で使え、ECDSA の P-256 は ES256 に、Ed25519 は EdDSA に対応します。秘密鍵で署名して公開鍵を公開すれば、検証側は署名を作れないまま検証だけを行えます。PEM ではなく JWK パネルを使う場合に 1 つ注意があります。Web Crypto は RSA の JWK に alg として RS256 を刻むため、厳格なライブラリはそれを PS256 や RS512 用に読み込むことを拒みます。alg メンバーを削除するか、PEM を使ってください。JWT エンコーダーはこれらの鍵を受け付け、JWT デコーダーでは出来上がったトークンの中身を確認できます。
SSH 鍵を生成できますか?
直接はできません。OpenSSH 独自の秘密鍵ファイルは別のコンテナで、このページはそれを書き出しません。ただしここで作った RSA 鍵は利用できます。ssh-keygen -y -f rsa-2048-private.pem > id_rsa.pub でダウンロードしたファイルから authorized_keys の行を導出できます。ここで作った Ed25519 鍵は使えません。OpenSSH が PKCS#8 形式を受け付けないためです。SSH アクセスについては、鍵を必要とするマシン上で ssh-keygen -t ed25519 を実行するのが依然として良い答えで、秘密鍵を動かさずに済みます。JWT 署名・CI のリリース署名・Webhook 検証であれば、このページが生成する PKCS#8 鍵こそがそれらのツールの求めるものです。
秘密鍵をパスフレーズで保護できますか?
ここではできません。暗号化された PKCS#8 には Web Crypto API が公開していない鍵導出の手順が必要で、実装すれば JavaScript で暗号を自作することになります。代わりにローカルでパスフレーズを付けてください。openssl pkcs8 -topk8 -in private.pem -out encrypted.pem がダウンロードしたファイルを読み込み、パスフレーズの入力を求めます。
フィンガープリントは何のためにありますか?
公開鍵構造の SHA-256 ダイジェストで、音声やチャットで比較できる程度に短いものです。誰かに公開鍵を送るとき、別経路でフィンガープリントを突き合わせれば、届いたものが送ったものと同じだと確認できます。識別するのは公開鍵だけで、秘密鍵側については何も明かしません。なお、これは ssh-keygen -l が表示する数値ではありません。OpenSSH は SPKI 構造ではなく独自のワイヤ形式をハッシュするため、同じ鍵でも両者が一致することはありません。

AES復号ツール — OpenSSL・CryptoJS互換

セキュリティツール

AESをオンラインで復号 — GCM/CBC/CTR、パスフレーズまたは生鍵に対応し、OpenSSLとCryptoJSの「U2FsdGVkX1」形式を自動検出します。処理は100%ブラウザ内で完結し、鍵がこのページから出ることはありません。

AES暗号化ツール — GCM・CBC・CTR対応

セキュリティツール

無料のAESオンライン暗号化ツール — AES-128/192/256、GCM/CBC/CTR、パスフレーズ(PBKDF2)または生鍵に対応。処理は100%ブラウザ内で完結し、外部にアップロードされません。

Bcrypt ハッシュ生成・検証ツール

セキュリティツール

bcrypt パスワードハッシュをオンラインで生成・検証。コスト調整、$2b$/$2a$/$2y$ プレフィックス対応。100% ブラウザ内で処理し、パスワードは一切送信されません。

HMAC ジェネレーター&署名検証ツール

セキュリティツール

無料のオンライン HMAC 生成・検証ツール。Text・Hex・Base64 の鍵で HMAC-SHA256/SHA1/SHA384/SHA512 を計算し、Hex/Base64/Base64URL で出力します。100% ブラウザ内で完結 —— 鍵はページから外に出ません。

JWT デコーダー — オンライン解析ツール

セキュリティツール

JWTトークンを無料のJWTデコーダーでオンラインデコード。ヘッダー、ペイロード、署名、有効期限、アルゴリズム、クレームを即座に検査できます。100%ブラウザ動作 — トークンはデバイスから外に出ません。登録不要、追跡なし。

JWT エンコーダー&ジェネレーター

セキュリティツール

無料のオンラインJWTジェネレーター&エンコーダー。ヘッダーとペイロードを組み立て、HS256、RS256、ES256で即座に署名できます。100%ブラウザ動作 — シークレットと鍵はデバイスから外に出ません。