暗号化とハッシュの違い8選｜署名・ECB・乱数の落とし穴

RJC Techチーム

「暗号化してます」——この一言、実はほとんど何も言っていないんですよね。

何を、どの方式で、どの範囲で守っているのか。そこを言い分けられるかどうかで、セキュリティの会話の解像度が変わります。今回は、「暗号化したのに絵柄が透けて見える」話から、専門家でなくても知っておきたいものを8つ集めました。1つでも知らなかったら儲けものです。

① 暗号化・ハッシュ・署名は、ぜんぶ別物です

まず、ここが混ざりがちです。3つは目的が違います。

	やること	元に戻せるか	主な用途
暗号化	内容を隠す	鍵があれば戻せる	通信・保存データの秘匿
ハッシュ	内容の指紋を取る	戻せない	改変検知・パスワード保存
署名	「本人が作り、改変されていない」ことを証明する	—	ソフトウェア配布・電子契約

「パスワードを暗号化して保存」という言い方は、実は危険信号です。戻せる形で持っていることになるので。正しくはハッシュ（それもパスワード専用の、わざと遅いハッシュ）で持つ——言葉の使い分けが、そのまま設計の正しさなんです。

② 暗号化したのに、絵が透けることがあります

暗号の世界で一番有名な画像の話です。

データをブロックごとに区切って、同じ鍵で同じ変換を素朴に繰り返す方式（ECBモード）で画像を暗号化すると——同じ色のブロックは、同じ暗号文になります。

結果、ペンギンの画像を暗号化したのに、ペンギンの輪郭がそのまま見える。中身は読めないのに、絵柄が漏れているわけです。

だから実務では、ブロックごとに変化を混ぜ込むモード（GCMなど）を使います。「暗号化した」と「情報が漏れない」は、別の話という強烈な実例なんです。

③ 「暗号を自作するな」には、理由があります

有名な鉄則ですが、理由まで言えますか。

第一に、暗号の強さは世界中の専門家が何年も攻撃して破れなかった実績で決まります。自作品はその検証を受けていません。

第二に、アルゴリズムが正しくても実装で漏れます。処理時間のわずかな差、電力消費、エラーメッセージの違い——そこから鍵を推定する攻撃（サイドチャネル攻撃）が実在します。

つまり「数学として正しい」と「実装として安全」の間に、深い谷がある。実績あるライブラリを、推奨設定で使うのが、唯一の正解なんです。

④ TLSは、2種類の暗号の合わせ技です

暗号には大きく2系統あります。同じ鍵で暗号化と復号をする共通鍵と、鍵をペアで使う公開鍵。

公開鍵方式は「事前に秘密を共有していない相手」と安全に話せる魔法ですが、計算が桁違いに遅い。共通鍵は速いが、最初の鍵の受け渡しが問題。

そこでTLS（HTTPSの中身）は、最初の一瞬だけ公開鍵方式で「共通鍵」を安全に共有し、以降の通信は高速な共通鍵で行います。

遅いが賢い方式で、速い方式の鍵を運ぶ。実用の暗号は、ほぼすべてこのハイブリッドなんです。

⑤ 暗号は破られるのではなく、「古くなり」ます

「MD5やSHA-1は危険」と聞きますが、ある日突然破られたわけではありません。

計算機の性能向上と攻撃研究の進歩で、「現実的な時間で衝突を作れる」ラインを、じわじわ越えたんです。設計時は安全だったものが、時代の方が追いついた。

つまり暗号の安全性には、賞味期限があります。鍵の長さも同じで、昔の推奨長は今の非推奨です。

だからシステム設計では「どの方式を使うか」だけでなく、「方式を将来入れ替えられる作りか」が問われるんです。

⑥ 暗号の土台は、ぜんぶ乱数です

意外な急所が、ここです。

鍵の生成も、セッションIDも、ワンタイムコードも、すべて「予測できない乱数」が前提です。乱数が予測できたら、どんな強い暗号方式も無意味になります。

そして落とし穴が、プログラミング言語の普通の乱数（Math.randomなど）は、予測可能だということ。シミュレーションには十分でも、セキュリティ用途には使ってはいけません。

各言語には暗号用の乱数生成器が別に用意されています（JavaのSecureRandom、Pythonのsecretsなど）。「乱数」と「暗号用乱数」を使い分けているか——コードレビューの隠れた急所です。

⑦ 「暗号化してます」は、どこを守るかで3種類あります

冒頭の「ほとんど何も言っていない」の答え合わせです。データには3つの状態があり、守り方が別です。

通信中 — TLS。経路上の盗聴から守る
保存時 — ディスクやDBの暗号化。盗まれた記憶媒体から守る
利用中 — メモリ上の処理中。ここまで守る技術はまだ発展途上です

たとえば「通信も保存も暗号化済み」でも、サーバー管理者には平文が見えます。それすら見えなくするのがエンドツーエンド暗号化（E2E）で、メッセージアプリの売り文句の意味はこれなんです。

「暗号化してます」と聞いたら、「どの状態を、誰から守っていますか」と返す。会話が一段深くなります。

⑧ 「署名を検証しない」という実装が、実在しました

最後は、実際にあった事故の型です。

JWTのヘッダには「どの署名方式か」を自己申告する欄があります。ここに「署名なし（none）」と書いたトークンを送ると、検証をスキップして受け入れてしまうライブラリが、かつて複数存在しました。

攻撃者は署名を偽造する必要すらなく、「署名はありません」と宣言するだけで通れたわけです。

教訓は明確で、受け入れる方式を受信側で固定すること。相手の自己申告に検証方法を委ねない。暗号は、使い方の1行で無力化されるという代表例なんです。

番外編：知っておくと会話が深くなる話

秘密にすべきは、鍵だけ
「暗号方式は公開されていても、鍵さえ秘密なら安全であるべき」——19世紀から続くケルクホフスの原理です。方式を隠して安心する設計は、この原理の逆を行っているんです。

「いま盗んで、あとで解読する」
現在の暗号文を保存しておき、将来の計算機（量子コンピュータなど）で解読する——という戦略が現実に懸念されています。これに備えて、2024年に米国のNISTが耐量子暗号を標準化し、ChromeなどのTLS通信では耐量子の鍵交換がすでに使われ始めています。⑤の「入れ替えられる作り」が、まさにいま試されているんですね。

錠前は買うもの、という感覚
③の結論は、「金庫を自作する人はいない」と同じ話です。私たちの仕事は錠前作りではなく、良い錠前を、正しい扉に、正しく取り付けることなんですよね。