Skip to content

DES / 3DES 暗号化・復号ツール

ブラウザで DES の暗号化・復号:単一 DES、3DES(2鍵・3鍵)、ECB/CBC、PKCS#7(Java の PKCS5Padding)、Zero またはパディングなし。鍵長は厳密に検証され、CryptoJS や openssl enc -K のように黙って切り詰められることはありません。すべての結果に等価な OpenSSL コマンドが付きます。自分の実装を突き合わせるための FIPS 81 テストベクタ付き。データは一切アップロードされません。

トラッキングなし ブラウザで動作 無料
暗号化は完全にブラウザ内で実行されます — 入力された鍵とデータがこの端末の外に出ることはありません。

暗号文
等価な OpenSSL コマンド
—

コマンドには入力した鍵が含まれます。

FIPS 81 の DES テストベクタ

このページが動かしているエンジンでビルド時に計算 — 自分の DES 実装をここに突き合わせてください。
鍵(単一 DES) 0123456789abcdef
平文 4e6f772069732074
暗号文(ECB、パディングなし) 3fa40e8a984d4815
DES/3DES エンジンは FIPS 81 ベクタを検証し、OpenSSL 3(des-ede / des-ede3、単一 DES は K‖K‖K の等価性で確認)と ECB・CBC 全体で 3,000 以上のランダムな組み合わせを突き合わせました。等価な OpenSSL コマンドは実際のシェルで実行して比較しています。ライブラリのデフォルト動作は実際に実行しソースを読んで確認しました。alternatives を参照してください。 — Go Tools Security Team · Sep 28, 2026

暗号ツールを開発している開発者自身が執筆・レビューしています。このページのすべての暗号文とバイト数はツールのエンジンで計算され、テストで検証されています。

DES クイック回答

DES 鍵の長さ

8 / 16 / 24 バイト 単一 DES:8 バイト(実効 56 ビット)。3DES:16 バイト(2鍵)または 24 バイト(3鍵)。名目上の鍵材料は 112/168 ビット、NIST の有効セキュリティ強度は約 80/112 ビット(SP 800-57)。本ツールはバイト数から自動判定し、その他の長さはエラーになります。

FIPS 81 テストベクタ

3fa40e8a984d4815 鍵 0123456789abcdef、平文 "Now is t"(hex 4e6f772069732074):単一 DES ECB・パディングなしでは 3fa40e8a984d4815 が出力されます。

DES の IV の長さ

8 バイト 8 バイト(16 桁 hex)。CBC のみで、ECB では使いません。AES の 16 バイト IV とは別物です。

Java の PKCS5Padding とは

= PKCS#7 DES に対しては PKCS#7 です — 歴史的な名前を持つ同一のパディングアルゴリズム(PKCS#5 が定義していたのは 8 バイトブロックで、それがたまたま DES のブロックでした)。

今日の DES は安全か

レガシー互換のみ いいえ。単一 DES は 2005 年に廃止、3DES は SP 800-131A Rev.2(2023)で非推奨。レガシー互換のみ — 新規には AES-256 を使ってください。

DES と 3DES(Data Encryption Standard)とは?

DES(Data Encryption Standard)は 1977 年に米国の標準化機構が採用した共通鍵ブロック暗号です。IBM の Lucifer 設計を基礎としています。64 ビット(8 バイト)ブロックを、実効 56 ビットの名目 64 ビット鍵で、Feistel 構造の 16 ラウンドで処理します。

3DES(TDEA、Triple DES)は短い鍵を補うため DES を 3 回連ねます:C = E_K3(D_K2(E_K1(P)))。中央のパスが復号になっているため、K1=K2=K3 とすればチェーンは単一 DES に縮退します — 意図的な互換性の選択です。2鍵形(K3=K1)は実効約 112 ビットで、レガシー銀行システムで最も一般的な形です。

NIST は 2005 年に単一 DES を廃止し(FIPS 46-3 の通知)、2023 年に SP 800-131A Rev.2 で 3DES を非推奨としました。今も存在する唯一の理由は レガシー互換 です。銀行の交換システム、決済ゲートウェイ、90 年代・2000 年代の Java/.NET/PHP システムは今も DES 時代の暗号を動かしています。新しい設計には AES-256 を使うべきです。

# OpenSSL single DES (legacy provider)
openssl enc -des-ecb -provider legacy -provider default -K 0123456789abcdef -nopad

# 3-key 3DES CBC + PKCS#7 (default provider)
openssl enc -des-ede3-cbc -K <48 hex digits> -iv <16 hex digits> -base64 -A

この DES ツールの機能

3 つの鍵長すべてを厳密に検証

8/16/24 バイトは自動判定で単一 DES / 2鍵 / 3鍵 3DES として扱われ、それ以外はエラーになります。CryptoJS の黙った切り詰めや openssl enc -K の「切り詰めて警告」と違い、誤った鍵ははっきり失敗します — 相互運用不一致の最大の原因です。

ビルド時に計算される FIPS 81 ベクタ

ページ下部のテストベクタ表は同じエンジンでビルド時に計算されるため、クローラは JS を実行せずに参照値を読め、表示される数値が対話ツールからずれることはありません。

等価な OpenSSL コマンド

すべてのパラメータの組み合わせが、OpenSSL 3 で同じ結果を再現する openssl enc コマンドに対応します(単一 DES では legacy-provider のフラグを含む)。相手側に送ってパラメータの食い違いを突き止められます。

GBK 平文のサポート

DES 時代の Java の getBytes() は中国語 Windows の JDK では GBK を返します。ここでは双方向とも GBK を受け付けるため、旧システムの中国語平文は事前変換なしで扱えます。

完全にブラウザ内で動作

純 TypeScript、依存ゼロ、ネットワーク要求ゼロ。鍵と平文は端末の外に出ず、読み込み後はオフラインで動作します。鍵を扱うツールとして唯一許容できる形です。

言語ごとの DES ライブラリのデフォルト動作

Java (JCE)

"DES" は既定で ECB + PKCS5Padding

Cipher.getInstance("DES") は DES/ECB/PKCS5Padding と同等です。"DESede" は 3DES ですが 24 バイトの鍵のみ受け付けます — 2鍵は K1‖K2 を K1‖K2‖K1 に展開してください。PKCS5Padding は DES に対しては PKCS#7 です。IV を省略すると、暗号化ではランダム IV が選ばれ(getIV() で取得)、復号では "Parameters missing" が投げられます。

PHP (openssl_encrypt)

des-ede3-cbc / des-ede-cbc

アルゴリズム名は OpenSSL に従います:des-ede3 は 3 重 ECB、des-ede3-cbc は CBC。$options=0(既定)は Base64 文字列 を出力し、生バイトには OPENSSL_RAW_DATA。短い鍵は 黙って 0 埋め され、空の IV は警告の後 ゼロ IV で暗号化します。

OpenSSL 3 (openssl enc)

-des-ede3-cbc は既定で動作

単一 DES には -provider legacy -provider default が必要です(ビルドによっては legacy 自体がない)。-K/-iv は hex を取ります。既定は PKCS#7、-nopad で無効化。-K は長すぎる鍵を警告付きで切り詰めます。

CryptoJS

不正な鍵長を黙って切り詰める

8 バイトの生鍵(WordArray)なら動作します。誤った長さは 黙って 0 埋めまたは切り詰め されます(4 バイトは埋め、10 バイトは切り詰め — エラーなし)。文字列を「鍵」として渡すと鍵導出が走ります(MD5 + ランダムソルト、出力は Salted__ で始まり毎回変わる)。IV なしの CBC はゼロ IV ではなく TypeError クラッシュです。8 バイト鍵の TripleDES は黙って単一 DES になります。

.NET

TripleDES は既定で CBC + PKCS7

TripleDESCryptoServiceProvider:Mode=CBC、Padding=PKCS7、鍵は 16 または 24 バイト(DES は 8 バイト)。.NET は弱い鍵を拒否します(まずパリティを正規化し、それから弱い鍵のテーブルと照合 — ゼロ鍵は例外を投げる)が、他のすべてのライブラリは受け付けます。移行時の注意点です。

Go (crypto/des)

モードは明示的に組み立てる

des.NewCipher は 8 バイト鍵の生のブロックインターフェースを返し、cipher.NewCBCEncrypter などは自分で組み合わせます。3DES は des.NewTripleDESCipher(24 バイト)。IV 長のチェックは他のほとんどの言語より厳密です。

DES 暗号化の例

FIPS 81 テストベクタ(単一 DES、ECB、パディングなし)

鍵 0123456789abcdef、平文 (hex) 4e6f772069732074
3fa40e8a984d4815

平文は ASCII 文字列 "Now is t" です。教科書通りの FIPS 81 ベクタであり、ページ下部の表は同じエンジンでビルド時に計算されています — あなたの DES 実装がこの入力に対してこの値を出さないなら、バグがあります。

2鍵 3DES + CBC + PKCS#7:UTF-8 平文から Base64 へ

鍵 0123456789abcdeffedcba9876543210(16 バイト)、IV fedcba9876543210、平文: DES interop test: order 20260927-0042
QmnMoewSecp7Z7cr/w3/4AjM9lpFo1swc4dfLNH5UkgCwU5n7WIdKA==

16 バイトの鍵は 2鍵 3DES として扱われます(K1 = 先頭 8 バイト、K2 = 末尾 8 バイト、K3 = K1 — EDE2 構成)。8 バイトブロックに対する PKCS#7 は、Java が DES に対して "PKCS5Padding" と呼ぶものそのものです:スキームは同じで、ブロックサイズだけが違います。

3鍵 3DES + CBC + PKCS#7

鍵 0123456789abcdef23456789abcdef010456789abcdef012(24 バイト)、IV fedcba9876543210、平文: hello des
DhDQX9sfxKOirZ8eyqT7Jg==

24 バイトの鍵は完全な 3 鍵の EDE3 です:C = E_K3(D_K2(E_K1(P)))。3 つの鍵長の中で、退化した等価形を持たないのはこの形だけです — 2鍵も K1=K2=K3 もより弱い暗号に縮退します。

この DES 暗号化・復号ツールの使い方

  1. 1

    モードとパディングを選ぶ

    Java の DES/ECB/PKCS5Padding なら ECB + PKCS#7、openssl enc -des-ede3-cbc なら CBC + PKCS#7 を選択します。古い PHP mcrypt コードはたいてい Zero パディングを使っています。

  2. 2

    鍵を入力する(8/16/24 バイト)

    バイト数が暗号方式を決めます:8 = 単一 DES、16 = 2鍵 3DES、24 = 3鍵 3DES。Hex・Text・Base64 を選択でき、バッジに実際のバイト数と判定された形が表示されます。誤った長さはエラーになります — 何も切り詰められません。

  3. 3

    CBC の場合は 8 バイトの IV を入力

    ECB に IV は不要です。IV はちょうど 8 バイト — 16 桁の hex で、AES の 32 桁ではありません。ランダムボタンで新しい IV を生成できます。

  4. 4

    貼り付けてリアルタイム結果を得る

    暗号化:テキスト(UTF-8/GBK)または hex を入力。復号:Base64 または hex の暗号文を貼り付け。入力に合わせて結果が即時更新され、ワンクリックコピーと「この暗号文を復号」ボタンでの往復チェックに対応しています。

  5. 5

    等価な OpenSSL コマンドを相手側に持っていく

    折りたたみパネルは現在の結果を再現する openssl enc コマンドを生成します(鍵付き。単一 DES のコマンドには -provider legacy -provider default が付きます)。相互運用相手に送れば、どちらのパラメータが間違っているかを最速で確定できます。

DES の復号が失敗する理由

鍵長が 8/16/24 ではない

32 桁 hex の「DES 鍵」は 16 バイト — これは 2鍵 3DES であり単一 DES ではありません。逆に、2鍵しか扱えないシステムに 24 バイトの鍵を渡しても失敗します。

✗ 誤り
鍵 0123456789abcdeffedcba9876543210(16 バイト)を単一 DES で選択 → エラー「鍵はちょうど 8 バイトでなければなりません」
✓ 正しい
同じ鍵を 16 バイト(2鍵 3DES)として → 正常に復号

PKCS5 と PKCS7 の名前の混同

Java は DES に対して "PKCS5Padding" と書きますが、実行しているのは PKCS#7 アルゴリズムです(PKCS#5 が定義していたのは 8 バイトブロックのパディングだけで、それが DES のブロックだったため名前だけ残りました)。JCE の暗号文に対して None や Zero を選ぶと必ず失敗します。

✗ 誤り
JCE の `DES/ECB/PKCS5Padding` 暗号文を「パディングなし」で復号 → 末尾にゴミまたは不正パディングエラー
✓ 正しい
PKCS#7(Java PKCS5Padding)を選択 → クリーンな出力

AES の IV 長(16 バイト)を流用

DES のブロックは 8 バイトなので、IV も 8 バイトです。AES のコードから 32 桁の hex の IV を貼ると長さチェックで失敗し、8 桁の hex の IV は 0 埋めされて誤って解釈されます。

✗ 誤り
IV 00000000000000000000000000000000(32 桁 hex)→ エラー「IV は 8 バイトでなければなりません」
✓ 正しい
IV 0000000000000000(16 桁 hex)→ 受け付けられる

CBC で IV を間違えた:壊れるのは最初の 8 バイトブロックだけ

複数ブロックの暗号文を間違った IV で復号しても エラーにはなりません — 最初の 8 バイトブロックだけが壊れ、残りは正しく復号されます(IV が届くのは第 1 ブロックだけで、パディングの検査は最終ブロックで行われるため)。「先頭の数文字だけ化けて、あとは正常」のときは、鍵より先に IV を疑ってください。逆に単一ブロックの暗号文ではパディングが壊れて bad decrypt エラーになります。

✗ 誤り
複数ブロックの暗号文 + 誤った IV → 先頭 8 バイトだけ化けて残りは正常 — 「鍵が違う」と誤読
✓ 正しい
IV だけ変える(鍵はそのまま)→ 先頭ブロックが復元され、IV が原因と確定

openssl enc -K は長い鍵を黙って切り詰める

-K は必要な分だけのバイトを残し、スクリプトに呑み込まれる 1 行の警告を出すだけです。相手が「鍵はこの 48 桁の hex」と言っていても実際には先頭 16 バイトで暗号化していた場合、鍵全体で復号しても失敗します。

✗ 誤り
シェル:`-K <49 桁 hex>` → 「hex string is too long, ignoring excess」がパイプラインに消える
✓ 正しい
本ツールの等価コマンドで正しい長さの `-K` を生成し、鍵のバイト列を相手側と比較する

単一 DES が OpenSSL 3 で "unsupported" になる

OpenSSL 3 の既定 provider には des-ecb/des-cbc がありません。そのまま実行すると digital envelope routines::unsupported になります。-provider legacy -provider default を付けるか、K‖K‖K の des-ede3(代数的には単一 DES)を使ってください。

✗ 誤り
openssl enc -des-ecb -K … → エラー:unsupported
✓ 正しい
openssl enc -des-ecb -provider legacy -provider default -K …(または des-ede3-ecb -K <K‖K‖K>)

オンライン DES 暗号化が必要な場面

レガシーシステムのメッセージ暗号のデバッグ
銀行の交換システム、POS ゲートウェイの MAC 計算、古い ERP インターフェースの暗号化は今も DES/3DES で動いています。メッセージと鍵をここに貼り付ければ、「鍵は合っているか、どのモードか、どのパディングか」を Java や PHP の環境を立てずに確認できます。
Java / PHP / .NET レガシーコードの移行
切り替える前に、Cipher.getInstance("DES/ECB/PKCS5Padding") の出力や openssl_encrypt(..., 'des-ede3-cbc', ...) の出力を本ツールとバイト単位で突き合わせます。2鍵/3鍵の形は鍵長から判定されるため、推測する箇所はありません。
セキュリティ監査と教育
ECB のパターン漏れの実演(同じ平文ブロック → 同じ暗号文ブロック)、3DES の縮退の検証(K1=K2=K3 は単一 DES に縮退)、FIPS 81 ベクタの確認 — ペネトレーションテスト報告書と暗号学の授業の定番です。
ドキュメント用の暗号文サンプルの生成
社内 Wiki や API ドキュメントに再現可能な例が必要なとき、固定の鍵と IV でここで計算できます — 読者は等価な OpenSSL コマンドで検証でき、本番データを貼り回す必要がありません。

DES / 3DES とブロック暗号モードの解説

ブロックと鍵
DES は 64 ビットブロックを 16 ラウンドの Feistel で処理し、各ラウンドでは 56 ビットのマスター鍵から PC-1/PC-2 の圧縮置換とスケジュール回転で導かれた 48 ビットのサブ鍵を使います。8 つの S-box が非線形性の唯一の源で、その設計基準は完全には公開されていません。
3DES の EDE 構成
C = E_K3(D_K2(E_K1(P)))。中央の復号により K1=K2=K3 は単一 DES に縮退します — 後方互換のための設計です。2鍵形は名目上 2×56=112 ビットの鍵材料を持ちますが、NIST の有効セキュリティ強度は約 80 ビット(SP 800-57 Part 1);3鍵は名目 168 ビットに対し実効強度 112 ビット(非推奨)です。
ECB と CBC
ECB はブロックを独立に暗号化します — 同じ平文ブロックは同じ暗号文ブロックになり、8 バイトブロックでは AES-ECB よりもはっきりとパターンが漏れます。CBC は前の暗号文ブロック(最初は IV)を平文に混ぜてから暗号化するもので、DES 時代の銀行システムの主流でした。どちらのモードも暗号文は 8 バイトの倍数になります。
パディング:PKCS#7 / Zero / None
PKCS#7 は不足分に値 n のバイトを n 個追加し(3 バイト不足 → 03 03 03)、満杯のブロックには丸ごと 1 ブロック追加します — これが DES に対する Java の "PKCS5Padding" です。Zero パディングは 0x00 で埋め、平文が実際に 0x00 で終わっている場合は可逆ではありません。None は 8 の整数倍を要求します。
OpenSSL 3 の legacy provider
OpenSSL 3 は単一 DES を既定で無効な legacy provider に移しました:CLI には -provider legacy -provider default が必要で、一部のビルド(Node 同梱の OpenSSL を含む)では legacy 自体が入っていません。3DES(des-ede/des-ede3)は既定の provider に残っています。本ツールの純 TS エンジンは影響を受けません。

DES を正しく使う(レガシー互換)

新規システムで DES を使わない — どの形でも
単一 DES の 56 ビットは総当たり可能で、64 ビットブロックは Sweet32 の誕生日限界(CVE-2016-2183)を抱え、NIST は 1 つの鍵バンドルにつき平文約 8 MB(2²⁰ ブロック)を上限としています。2鍵は Disallowed、3鍵の暗号化は 2023 年以降 Disallowed。新規には AES-256 を。本ツールは レガシーシステムを読み、安全に移行するため に存在します。
レガシー互換では、まずバイト単位の一致
古いシステムに手を入れるときは、まず旧パラメータの暗号文をここでバイト単位で再現してからコードを変えます。鍵長、モード、パディング、IV の出所(固定かランダムか、ヘッダか帯域外か)を、アルゴリズムを切り替える前に確認してください。
IV を再利用しない — レガシーシステムでも
同じ鍵で CBC の IV を再利用すると、2 つの平文の先頭ブロック同士の関係が露出します。レガシープロトコルが固定 IV を義務付けているなら、移行リストに欠陥として記録してください — 慣習として引き継がないこと。
鍵をソースコードに置かない
DES 時代のシステムは鍵を平文のソースや設定にハードコードしがちです。監査するときは「どのアルゴリズムか」と並べて「鍵がどう保存されているか」を報告書に書いてください — ほとんどの侵害では、後者が本当の穴でした。

DES 暗号化・復号 FAQ

DES の復号が "bad decrypt" やパディングエラーで失敗する — 何を確認すべき?
復号ではすべてのパラメータが暗号化側と一致している必要があります:鍵のバイト列、鍵長(8/16/24)、モード(ECB/CBC)、IV、パディング、そして暗号文が hex か Base64 か。最も多い落とし穴は 2 つ:鍵長の不一致(32 桁の hex の「DES 鍵」は 16 バイト — これは 2鍵 3DES であり単一 DES ではない)と、パディング名の混同(Java の PKCS5Padding は DES に対しては PKCS#7 そのもの — None を選ばないこと)。右側の折りたたみパネルは現在の設定に対する等価な OpenSSL コマンドを表示します。これを相手側に送るのが食い違いを見つける最短ルートです。
DES 鍵の長さは?3DES は?
単一 DES:名目 64 ビット(8 バイト、実効 56 ビット — 各バイトの 1 ビットはパリティ)。3DES には 2 つの形があります:2鍵(16 バイト、K1‖K2 で K3=K1)と 3鍵(24 バイト、K1‖K2‖K3)。名目上の鍵材料はそれぞれ 112/168 ビットですが、NIST の有効セキュリティ強度(SP 800-57 Part 1 Rev.5 表 2)は約 80 ビットと 112 ビットにすぎず、しかも 3鍵形も非推奨です。本ツールはバイト数から形を判定し、8/16/24 以外はエラーになります — CryptoJS や openssl enc -K は黙って切り詰めるか 0 埋めするため、これが相互運用失敗の最大の原因です。
IV とは何ですか?DES での長さは?
IV は CBC が最初のブロックに混ぜ込む 8 バイトの値で、ECB では使いません。ちょうど 8 バイト(16 桁の hex または 8 文字の ASCII)でなければなりません。DES の IV は 8 バイト、AES は 16 バイト — AES の IV 長をそのまま持ってくると即座に失敗します。同じ鍵で IV を再利用しないでください。
Java の DES/ECB/PKCS5Padding は本ツールでは何に対応しますか?
ECB モード + PKCS#7 パディングです。JCE では DES の "PKCS5Padding" は汎用の PKCS#7 アルゴリズムを実行します — PKCS#5 が定義していたのは 8 バイトブロックのパディングだけで、それがたまたま DES のブロックサイズでした。Java の Cipher.getInstance("DES/ECB/PKCS5Padding") の出力は、ECB + PKCS#7 と 8 バイトの単一 DES 鍵でここで復号できます。⚠️ Java の 3DES(DESede)は 24 バイトの鍵のみ受け付けます — 2鍵形は K1‖K2 を自分で K1‖K2‖K1 に展開する必要があります。
PHP の des-ede3 系アルゴリズム名との対応は?
PHP は OpenSSL の名前を借りています:des-ede3-cbc は 3鍵 3DES + CBC、des-ede3-ecb は 3鍵 + ECB;des-ede-cbc は 2鍵形です。24 バイトの鍵なら 3鍵、16 バイトなら 2鍵が選ばれます。
DES 鍵のパリティビットとは?チェックされるのですか?
鍵の各バイトの最下位ビットはパリティビットと定義されており、真の 56 ビット鍵は 64 ビットの中に収まっています。FIPS 46-3 はチェックを要求しません — OpenSSL も Java も本ツールも無視します。任意の 8 バイトで動作し、パリティビットを変えても暗号文は変わりません。例外は .NET です:パリティを正規化してから弱い鍵のテーブルと照合するため、ゼロ鍵などの弱い鍵は .NET では拒否されますが、他のライブラリはすべてそのまま暗号化します — Java/OpenSSL から .NET へテスト鍵を移すときだけ発火する落とし穴です。
3DES で K1 = K2 のとき何が起きますか?
2鍵 3DES では K3 は常に K1 と等しく、さらに K1 = K2 なら EDE チェーン全体が単一 DES に縮退します:E_K(D_K(E_K(P))) = E_K(P)。24 バイト鍵の 3 つの 8 バイト構成要素がすべて同一の場合も同じです。本ツールはそれでも暗号化します(相互運用優先)が、実際の強度は 3DES ではなく単一 DES の 56 ビットです。
DES は今も安全ですか?
いいえ — レガシー互換のためだけのものです。 NIST は 2005-05-19 に単一 DES を廃止しました(56 ビット鍵は総当たり可能。EFF の Deep Crack は 1998 年に 56 時間、翌年は distributed.net と共に 22 時間で破りました)。SP 800-131A Rev.2 は 2鍵 TDEA の暗号化を Disallowed、3鍵の暗号化を 2023-12-31 以降 Disallowed としています(復号は「Legacy use」のまま、歴史的データの読み取りだけに許容)。SP 800-67 自体も 2024-01-01 に withdrawn になりました。64 ビットという小さなブロックは Sweet32 クラスの誕生日限界(CVE-2016-2183)も抱えます — NIST は 1 つの鍵バンドルにつき平文 2²⁰ ブロック(約 8 MB)を上限としています。新規には AES-256 を使ってください。本ツールが存在するのは、銀行の交換システム、決済ゲートウェイ、古い Java/.NET システムが今も DES 時代のメッセージを動かしているからです — 直すには、まず読めることが始まりです。
3DES の結果が Java/PHP と一致しないのはなぜ?
発生頻度の高い順に確認してください:① 鍵長 — 相手の「32 桁 hex の DES 鍵」は 16 バイト(2鍵 3DES)で、あなたは単一 DES として復号した;② モード — Java の素の "DES" は既定で ECB、OpenSSL のモード接尾辞なしの名前 des-ede3/des-ede は ECB(CBC の別名は -des3);PHP の openssl_encrypt はアルゴリズム名を明示する必要があり、紛らわしいのは既定で生バイトではなく Base64 文字列を出力する点;③ パディング — 古い PHP mcrypt は Zero をよく使い、JCE は PKCS#5/#7;④ エンコーディング — hex か Base64 か、大文字小文字;⑤ CryptoJS のパスワード落とし穴 — 文字列を「鍵」として渡すと鍵導出が走ります(MD5 + ランダムソルト、出力は Salted__ で始まり毎回変わる)。これは生の鍵ではまったくありません — 「同じコードなのに実行ごとに結果が違う」の最大の原因です。本ツールでは各項目を切り替えられ、右側の等価 OpenSSL コマンドを相手側に送って再現できます。
ECB と CBC — どちらを使うべき?
相手のシステムが要求するものを使うしかありません — レガシー互換に選択の余地はありません。それでも選べるなら、必ずランダム IV 付きの CBC:ECB は同じ平文ブロックを同じ暗号文ブロックにし、DES の 8 バイトという小さなブロックは AES-ECB よりもさらに目立ってパターンが漏れます。DES 時代の銀行プロトコルは両方を使っています。まずプロトコル仕様書を確認してください。
オフラインで動きますか?データはアップロードされますか?
すべての計算はブラウザ内で行われます(純 TypeScript、依存ゼロ、ネットワーク要求ゼロ)。鍵と平文が端末の外に出ることはありません。ページを読み込んだ後はオフラインでも作業を続けられます。鍵を扱うツールとして唯一許容できる形です。
2鍵と 3鍵の 3DES — レガシーシステムではどちらが多い?
2鍵(16 バイト)の方が一般的です:銀行と決済業界は互換性のため 16 バイト鍵のハードウェアを展開しており、SP 800-67 は 2鍵に別の(より早い)廃止日を残しています。したがって 32 桁 hex の「3DES 鍵」はおそらく 2鍵形です。本ツールはバイト数から形を自動判定します。

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% ブラウザ内で処理し、パスワードは一切送信されません。

CRC チェックサム計算機(巡回冗長検査)

セキュリティツール

16進数またはテキストを貼り付けるだけで、CRC-8・CRC-16・CRC-32 の全63変種を一度に算出します。手元のチェックサムと一致しない場合は期待値を入力すれば、MODBUS・CCITT-FALSE・XMODEM・KERMIT のどれかを自動で特定。処理はすべてブラウザ内で完結します。

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

セキュリティツール

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

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

セキュリティツール

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