はじめに

はじめまして。某工業大学に所属する大学院生です。

学んだ知識を自分なりに整理しながら、私なりに情報セキュリティの知識や面白さを初学者向けに分かりやすく発信していきます。
この記事をきっかけに少しでも情報セキュリティについて興味を持ってくれたらうれしいです！

概要

スマホ決済、ネットショッピング、SNSへのログイン、メッセージアプリ、クラウド保存。
どれも普段は何気なく使っているサービスですが、裏側では「安全に通信する」「途中で書き換えられていないか確認する」「本物の相手につながっているか確かめる」といった処理が行われています。

このような、デジタル社会の見えない安全確認を支えている代表的な技術が、暗号技術です。

本記事では、暗号技術をいきなり数式やアルゴリズムから説明するのではなく、まずは身近なサービスの例から整理します。
そのうえで、暗号技術を次の3つの視点から「地図」のように眺めます。

何を守るのか
どの道具を使うのか
実サービスではどう組み合わせるのか

本記事では、AESやRSAの内部構造、具体的な実装コード、数学的な安全性証明までは扱いません。
詳細は今後の個別記事で深掘りし、本記事はその入口として使える内容を目指します。

この記事の立ち位置

暗号技術について調べると、AES、RSA、SHA-256、TLS、JWT、耐量子暗号など、たくさんの用語が出てきます。
それぞれを個別に調べることは大切ですが、最初から細かいアルゴリズムを追いかけると、「結局どこで使われているのか」が見えにくくなることがあります。

そこで本記事では、暗号技術を「用語の一覧」ではなく、学習を進めるための地図として整理します。

よくある暗号入門記事	本記事の方針
アルゴリズム名から説明する	身近なサービスから説明する
共通鍵暗号・公開鍵暗号を個別に説明する	実サービスでどう組み合わされるかを見る
基礎用語の説明で終わる	耐量子暗号や軽量暗号など最近動向にも触れる
1記事で完結する	詳細記事へつなげる入口にする

この記事で分かること

暗号技術が日常のどこで使われているか
暗号技術が「何を守るためのもの」なのか
暗号化・ハッシュ・MAC・デジタル署名・鍵共有などの役割の違い
TLS、JWT、ブロックチェーン、パスワード保存などの身近な利用例
耐量子暗号、軽量暗号、プライバシー強化暗号などの最近の動向
今後、個別記事で深掘りするテーマ

対象読者

この記事は、次のような人を想定しています。

情報セキュリティを学び始めた人
「暗号化」「ハッシュ化」「署名」の違いがまだ曖昧な人
TLS、JWT、ブロックチェーン、パスワード保存などで出てくる暗号用語を整理したい人
詳細なアルゴリズムに入る前に、まず全体像をつかみたい人

本記事で扱わないこと

本記事は、暗号技術の入口として全体像をつかむことを目的にしています。
そのため、以下は別記事で扱います。

AES、RSA、楕円曲線暗号などの詳細なアルゴリズム
数式を使った安全性の厳密な説明
各暗号方式の実装コード
暗号ライブラリの具体的な使い方
実システムにおける詳細な鍵管理設計

今後の記事は、次のように本記事から枝分かれさせる想定です。

1. 日常のサービスは、どんな安全確認で守られているのか

コンビニでスマホをかざして支払う。
ネットショッピングで住所や支払い情報を入力する。
SNSにログインする。
クラウドにファイルを保存する。

これらはまったく別のサービスに見えますが、裏側では共通して「データを安全に扱うための確認」が行われています。

たとえば、通信内容を第三者に盗み見られないようにすること。
送信した内容が途中で書き換えられていないこと。
接続先のサーバーが本物であること。
本人の操作として正しく記録されること。

このような安全確認を支えている代表的な技術が、暗号技術です。

ここで大切なのは、暗号技術は「データを読めなくする技術」だけではない、という点です。
もちろん、秘密の情報を読めなくする暗号化も重要です。

しかし実際には、改ざんを見つける、相手が本物か確認する、電子的な署名を残す、通信のための鍵を安全に共有する、といった多くの場面で暗号技術が使われています。

たとえばスマホ決済を例にすると、支払い情報を隠すだけでは十分ではありません。
金額が途中で変わっていないか、接続先が本物か、本人の操作として扱ってよいか、といった確認も必要になります。

Webログイン、API通信、ブロックチェーン送金、クラウド保存でも、形は違っても同じように「安全に扱うための確認」が行われています。

この記事では、暗号技術を深い数式や実装からではなく、まずは日常のサービスを安全に動かすための道具箱として整理します。

次の章では、その道具箱が具体的にどのような性質を守っているのかを見ていきます。

2. 暗号技術が守っているもの

この章では、暗号技術の地図のうち 「何を守るのか」 を見ます。
暗号化、ハッシュ、署名などの名前を覚える前に、まず守りたい性質を整理します。

前の章では、スマホ決済やWebログインのような身近な場面を例に、暗号技術が私たちの生活の裏側で使われていることを見ました。
では、暗号技術は具体的に「何」を守っているのでしょうか。

ここで大切なのは、暗号技術を「情報を読めなくするためだけのもの」と考えないことです。
もちろん、通信内容や保存データを第三者に読まれないようにすることは、とても重要です。

しかし実際には、それだけでは足りません。
たとえばスマホ決済では、支払い情報が読まれないだけでなく、金額が途中で書き換えられていないこと、本物のサービスにつながっていること、自分の操作として正しく記録されることも必要です。

この章では、暗号技術が守っている代表的な性質を、身近な例と一緒に整理します。

2.1 まず全体像を見る

暗号技術が支える代表的な性質は、次のように整理できます。

守りたいもの	やさしく言うと	身近な例	関係する主な暗号技術
機密性	他人に中身を読まれないこと	カフェのWi-Fiでログイン情報を盗み見られないようにする	共通鍵暗号、公開鍵暗号、TLS
完全性	中身が勝手に書き換えられていないこと	送金金額が途中で変更されていないか確認する	ハッシュ関数、MAC、デジタル署名、AEAD
認証	相手や送信者が本物だと確認すること	本物の銀行サイトにつながっているか確認する	証明書、MAC、デジタル署名
否認防止	後から「やっていない」と否定しにくくすること	電子契約やブロックチェーンの送金署名	デジタル署名
鍵共有	通信に使う秘密の鍵を安全に準備すること	HTTPS通信を始めるときに一時的な鍵を作る	Diffie-Hellman、ECDH、KEM
プライバシー保護	必要なことだけを示し、余計な情報は隠すこと	年齢条件だけを示し、生年月日そのものは隠す	ゼロ知識証明、MPC、FHE

図にすると、暗号技術は次のような「安全確認の道具箱」として見ることができます。

この図のポイントは、暗号技術が「暗号化」だけで完結していないことです。
実際のシステムでは、目的に応じて複数の技術を組み合わせています。

たとえば、TLS 1.3はインターネット上のクライアントとサーバーの通信を保護するプロトコルで、盗聴、改ざん、メッセージ偽造を防ぐように設計されています。
参考: RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3

2.2 機密性：見られたら困るものを隠す

機密性は、第三者に情報の中身を読まれないようにする性質です。
一番イメージしやすい「暗号化」は、この機密性を守るために使われます。

たとえば、ネットショッピングで住所や支払い情報を入力するとき、その内容が通信経路の途中で丸見えになってしまうと困ります。
そこで、通信内容を暗号化し、第三者が途中で見ても意味の分からない形にします。

身近な例でいうと、手紙をそのままハガキに書くのではなく、封筒に入れて送るようなイメージです。
封筒の中身は、受け取る相手だけが読める状態にしたいわけです。

ただし、ここで注意したいのは「暗号化しているから何もかも安全」とは限らないことです。
暗号方式が適切でも、鍵の管理を間違えたり、古い方式を使い続けたり、偽物のサイトに情報を入力したりすると、安全性は崩れてしまいます。

NIST SP 800-57 Part 1 Rev.5は、暗号を使う際のセキュリティサービスや鍵管理の考え方を整理した文書であり、暗号ではアルゴリズムだけでなく鍵管理も重要であることが分かります。
参考: NIST SP 800-57 Part 1 Rev.5 - Recommendation for Key Management

2.3 完全性：途中で書き換えられていないことを確認する

完全性は、データが途中で勝手に変更されていないことを確認する性質です。
これは「読めないようにする」とは少し違います。

たとえば、あなたが「1,000円を支払う」という操作をしたとします。
通信内容が暗号化されていて第三者に読めなかったとしても、もし途中で金額が「10,000円」に書き換えられてしまったら大問題です。

このような改ざんを見つけるために、ハッシュ関数、MAC、デジタル署名、AEADなどが使われます。

ハッシュ関数は、データから「指紋」のような短い値を作る技術です。
元データが少しでも変わると、ハッシュ値も大きく変わるため、ファイルやメッセージが変化していないかを確認するために使われます。

ただし、ハッシュ関数だけでは「誰がそのハッシュ値を作ったのか」までは分かりません。
そこで、共有鍵を使うMACや、秘密鍵を使うデジタル署名と組み合わせることで、改ざん検知に加えて「正しい相手が作ったものか」も確認できるようになります。

2.4 認証：相手や送信者が本物か確認する

認証は、相手や送信者が本物であることを確認する性質です。
ここでいう認証は、ログイン画面でIDとパスワードを入力する話だけではありません。

たとえば、ブラウザで銀行のサイトにアクセスしたとき、見た目だけでは本物のサイトか偽物のサイトか判断できない場合があります。
そこで、Webサイトの証明書やTLSの仕組みを使って、「このサーバーは本当にそのドメインのサーバーなのか」を確認します。

また、APIやサーバー間通信では、「このリクエストは本当に信頼できる相手から送られてきたのか」を確認する必要があります。
このような場面では、MACやデジタル署名が使われることがあります。

ここでのポイントは、暗号技術が「中身を隠す」だけでなく、「誰から来たものか」を確かめるためにも使われることです。

2.5 否認防止：後から「やっていない」と言いにくくする

否認防止は、ある操作や文書について、後から「自分はそんなことをしていない」と否定しにくくする性質です。
少し固い言葉ですが、電子契約やブロックチェーンを考えるとイメージしやすくなります。

たとえば、電子契約では、契約内容に対して本人の秘密鍵で署名することで、その人が内容を確認して署名したことを示します。
ブロックチェーンでも、送金するときには秘密鍵で署名し、その署名をネットワーク上の参加者が検証します。

NIST FIPS 186-5では、デジタル署名はデータの不正な変更を検出し、署名者の身元を認証するために使われると説明されています。
また、署名されたデータの受信者は、その署名が主張された署名者によって生成されたことを第三者に示す証拠として利用できます。
参考: NIST FIPS 186-5 - Digital Signature Standard

ただし、デジタル署名があるからといって、すべての場面で自動的に法的効力が決まるわけではありません。
実際の契約や法的な扱いは、国や制度、サービスの設計によって変わります。
本記事では、あくまで技術的な意味での否認防止として整理します。

💡 豆知識
デジタル署名は「電子版の手書きサイン」と説明されることがあります。
ただし、実際には見た目のサイン画像ではなく、秘密鍵を使って作られる検証可能なデータです。
そのため、署名画像を貼り付けるだけのものとは意味が大きく異なります。

2.6 鍵共有：秘密の鍵をどうやって安全に準備するか

共通鍵暗号では、同じ鍵を持っている相手同士がデータを暗号化・復号します。
これは便利ですが、すぐに疑問が出てきます。

「その共通鍵を、どうやって相手に安全に渡すのか？」

もし鍵をそのまま通信で送ってしまえば、途中で盗み見られたときに意味がありません。
この問題を解決するために使われるのが、鍵共有や鍵確立の仕組みです。

HTTPS通信では、最初の段階で通信相手と安全に鍵を準備し、その後のデータ通信では高速な共通鍵暗号を使います。
つまり、公開鍵暗号や鍵共有は「大量のデータを直接暗号化する主役」というよりも、「安全に会話を始めるための準備役」として重要です。

この考え方は、次の章で扱う共通鍵暗号・公開鍵暗号の違いを理解するときにも役立ちます。

💡 豆知識
共通鍵暗号は「同じ合鍵を持つ人だけが開けられる箱」に例えられます。
ただし、本当に難しいのは箱そのものよりも、「その合鍵をどうやって相手に渡すか」です。
暗号の世界では、この“鍵を渡す問題”を解くために多くの工夫が積み重ねられてきました。

2.7 プライバシー保護：必要以上に情報を出さない

最近の暗号技術では、「秘密を隠す」だけでなく、「秘密を隠したまま必要なことだけを示す」考え方も重要になっています。

たとえば、あるサービスで「20歳以上であること」だけを確認したい場合を考えます。
このとき、本当に必要なのは年齢条件を満たしているかどうかであり、生年月日、住所、氏名などをすべて見せる必要はありません。

このように、余計な情報を明かさずに必要な条件だけを示す技術として、ゼロ知識証明があります。
また、複数の組織が互いのデータをそのまま見せずに共同計算するMPC、暗号化したまま計算する完全準同型暗号なども、プライバシーを守りながらデータを活用するための技術として研究・標準化が進められています。

NISTのPrivacy-Enhancing Cryptographyプロジェクトでは、ゼロ知識証明、MPC、完全準同型暗号などが、プライバシーを高める暗号技術として扱われています。
参考: NIST Privacy-Enhancing Cryptography

ただし、これらの技術は便利な一方で、計算コスト、実装の難しさ、標準化や相互運用性などの課題もあります。
本記事では名前と位置づけだけを紹介し、詳しい仕組みは個別記事で整理します。

2.8 この章のまとめ

ここまで見ると、暗号技術は「情報を読めなくする技術」だけではないことが分かります。

暗号技術は、機密性、完全性、認証、否認防止、鍵共有、プライバシー保護といった複数の目的を支えています。
そして、実際のサービスでは、これらを単独ではなく組み合わせて使うことで、安全な通信や安全な取引を実現しています。

次の章では、これらの性質を実現するために使われる具体的な道具として、共通鍵暗号、ハッシュ関数、MAC、公開鍵暗号、デジタル署名などを整理します。

3. 暗号技術の道具箱

この章では、暗号技術の地図のうち 「どの道具を使うのか」 を見ます。
詳しいアルゴリズムには入らず、それぞれの道具がどんな役割を持つのかに絞って整理します。

前の章では、暗号技術が「機密性」「完全性」「認証」「否認防止」「鍵共有」「プライバシー保護」といった性質を支えていることを整理しました。

ここからは、それらを実現するために使われる代表的な道具を見ていきます。
ただし、本記事では各方式の詳しいアルゴリズムや実装コードには入りません。

細かい数式や内部構造をいきなり追いかけるよりも、まずは「どの道具が、何のために使われるのか」をつかむ方が、暗号技術の全体像を理解しやすいからです。

3.1 まずは全体像を見る

暗号技術の道具箱には、さまざまな道具が入っています。
それぞれの役割をざっくり整理すると、次のようになります。

道具	やさしく言うと	主な役割	代表例
共通鍵暗号	同じ鍵で閉めて、同じ鍵で開ける方式	データを高速に暗号化する	AES、ChaCha20
認証付き暗号	暗号化と改ざん検知をまとめて行う方式	中身を隠しつつ、書き換えも検知する	AES-GCM、ChaCha20-Poly1305
ハッシュ関数	データの指紋を作る方式	改ざん検知、識別子、署名の前処理	SHA-256、SHA-3
MAC	秘密の鍵つきでメッセージの正しさを確認する方式	改ざん検知、送信者確認	HMAC、CMAC
公開鍵暗号	公開鍵と秘密鍵を使う方式	鍵共有、暗号化、署名の土台	RSA、楕円曲線暗号
デジタル署名	秘密鍵で署名し、公開鍵で検証する方式	本人性、改ざん検知、否認防止	RSA署名、ECDSA、EdDSA
鍵共有・鍵カプセル化	通信相手と安全に鍵を準備する方式	通信開始時の共通鍵生成	ECDH、ML-KEM
パスワードハッシュ	パスワードを保存用に変換する方式	パスワード漏えい時の被害軽減	Argon2、bcrypt、scrypt

図にすると、暗号技術の道具箱は次のように整理できます。

この図で大切なのは、どれか一つの技術だけで安全なシステムが完成するわけではない、という点です。
実際のWebサービスやスマホアプリでは、これらの道具を目的に応じて組み合わせています。

3.2 共通鍵暗号：大量のデータをすばやく守る

共通鍵暗号は、暗号化と復号に同じ鍵を使う方式です。
イメージとしては、同じ合鍵を持っている人だけが開けられる箱に近いです。

たとえば、メッセージアプリで送信内容を暗号化したり、保存ファイルを暗号化したりするときには、大量のデータを効率よく処理する必要があります。
このような場面で、共通鍵暗号はとても重要です。

代表的な方式としては、AES があります。
AESはNISTのFIPS 197として標準化されている共通鍵暗号で、現在の暗号技術を学ぶ上で避けて通れない基本的な方式です。
参考: NIST FIPS 197 - Advanced Encryption Standard (AES)

また、ソフトウェア実装で使われる代表例として ChaCha20 もあります。
ChaCha20は、後述するPoly1305と組み合わせて、ChaCha20-Poly1305という認証付き暗号としても使われます。

ここで注意したいのは、共通鍵暗号では「鍵をどう共有するか」が大きな問題になることです。
同じ鍵を使うということは、通信相手も同じ鍵を持っていなければなりません。
しかし、その鍵をそのまま通信で送ってしまうと、盗み見られたときに意味がなくなってしまいます。

そのため実際の通信では、共通鍵暗号だけでなく、後述する鍵共有の仕組みと組み合わせて使います。

💡 豆知識
共通鍵暗号は「速いけれど、鍵の受け渡しが難しい」技術です。
一方、公開鍵暗号は「鍵の受け渡しには便利だけれど、大量データの処理には重い」技術です。
そのため、実際の通信では両者を組み合わせることが多いです。

共通鍵暗号と認証付き暗号の詳しい整理は、次の個別記事で扱います。

3.3 認証付き暗号：隠すだけでなく、書き換えも見つける

暗号化というと「中身を読めなくすること」に注目しがちです。
しかし、実際の通信では「中身が途中で書き換えられていないこと」も同じくらい重要です。

たとえば、通信内容が暗号化されていても、攻撃者が暗号文を細工して、受信側の処理に影響を与えられる可能性があります。
そのため、現代の通信では、単に暗号化するだけでなく、改ざん検知もあわせて行う設計が重要になります。

この考え方を実現する代表的な技術が、認証付き暗号です。
英語では Authenticated Encryption と呼ばれます。

特に、AEAD は「暗号化するデータ」と「暗号化はしないが改ざんされていないか確認したい関連データ」を一緒に扱える仕組みです。
RFC 5116では、AEADが平文の機密性に加えて、平文や関連データの完全性・真正性を確認する仕組みとして説明されています。
参考: RFC 5116 - An Interface and Algorithms for Authenticated Encryption

代表例としては、次のような方式があります。

方式	ざっくりした位置づけ
AES-GCM	AESを使った代表的な認証付き暗号
ChaCha20-Poly1305	ChaCha20とPoly1305を組み合わせた認証付き暗号

ここでは詳しいアルゴリズムには入りませんが、初学者向けには次の理解が大切です。

暗号化は「読まれないようにする」ためのもの。
認証付き暗号は、それに加えて「途中で書き換えられていないこと」も確認するためのもの。

この違いを意識しておくと、後でTLSやAPI通信を学ぶときに理解しやすくなります。

3.4 ハッシュ関数：データの指紋を作る

ハッシュ関数は、入力データから固定長の値を作る技術です。
この値は、よく「データの指紋」のように説明されます。

たとえば、あるファイルをダウンロードしたとき、配布元が公開しているハッシュ値と、自分の手元で計算したハッシュ値が一致すれば、少なくともファイルが途中で変化していないことを確認する材料になります。

代表的なハッシュ関数には、SHA-256などを含むSHA-2系列や、SHA-3系列があります。
NIST FIPS 180-4はSHA-1やSHA-2系列のハッシュアルゴリズムを定めた標準で、メッセージが変更されたかを検出するためのダイジェスト生成に使われると説明されています。
参考: NIST FIPS 180-4 - Secure Hash Standard

また、SHA-3はNIST FIPS 202として標準化されています。
SHA-3はSHA-2とは異なる構造を持つハッシュ関数ファミリーで、KECCAKを基にしています。
参考: NIST FIPS 202 - SHA-3 Standard

ハッシュ関数については、次の点を混同しないことが大切です。

よくある誤解	実際の考え方
ハッシュ化すれば何でも安全	用途に合った方式を選ぶ必要がある
ハッシュ値があれば元データを復元できる	暗号学的ハッシュ関数は基本的に一方向の変換として使う
パスワードはSHA-256でハッシュ化すれば十分	パスワード保存には専用のパスワードハッシュを使うべき
ハッシュだけで送信者も確認できる	送信者確認にはMACやデジタル署名が必要

特に、パスワード保存と通常のハッシュ関数は分けて考える必要があります。
通常のハッシュ関数は高速に計算できることが多く、漏えい時に総当たり攻撃を受けやすくなる場合があります。
そのため、パスワード保存ではArgon2、bcrypt、scryptのような、パスワード保存を意識した方式が使われます。

💡 豆知識
ハッシュ関数は「暗号化」と呼ばれることがありますが、厳密には復号して元に戻すものではありません。
たとえるなら、ミキサーにかけた果物ジュースから元の果物を完全に戻すのが難しいようなイメージです。
ただし、この例えは直感的な説明であり、実際の安全性は数学的な性質に基づいて評価されます。

ハッシュ関数の詳しい整理は、次の個別記事で扱います。

3.5 MAC：鍵を持つ相手から来たことを確認する

MACは、Message Authentication Codeの略です。
日本語では「メッセージ認証コード」と呼ばれます。

ハッシュ関数は、データが変わっていないかを確認するために使えます。
しかし、普通のハッシュ関数だけでは「そのハッシュ値を誰が作ったのか」までは分かりません。

そこで使われるのがMACです。
MACでは、共有された秘密鍵を使って、メッセージに対する確認用の値を作ります。
受信側も同じ鍵を持っていれば、その値を検証できます。

代表的な方式としては、HMAC があります。
NIST FIPS 198-1では、HMACは暗号学的ハッシュ関数と共有秘密鍵を組み合わせて使うメッセージ認証の仕組みとして説明されています。
参考: NIST FIPS 198-1 - The Keyed-Hash Message Authentication Code (HMAC)

MACは、API通信やサーバー間通信などで重要です。
たとえば、あるサーバーが別のサーバーにリクエストを送るとき、「このリクエストは本当に共有鍵を知っている相手から来たものか」を確認するために使われることがあります。

ただし、MACには注意点もあります。
MACを検証できる人は、基本的に同じ秘密鍵を持っている人です。
そのため、第三者に対して「この人が作った」と証明したい場合には、次に説明するデジタル署名の方が向いています。

比較	MAC	デジタル署名
使う鍵	共有鍵	秘密鍵と公開鍵
検証できる人	共有鍵を持つ人	公開鍵を持つ人
向いている場面	内部通信、API、サーバー間通信	電子署名、証明書、ブロックチェーン
第三者への証明	苦手	得意

この違いは、暗号技術を実務で使うときにかなり重要です。

MACとデジタル署名の違いは、次の個別記事で詳しく整理します。

3.6 公開鍵暗号：公開してよい鍵と、秘密にする鍵を分ける

公開鍵暗号は、公開鍵と秘密鍵のペアを使う方式です。
名前の通り、公開鍵は他人に渡してもよい鍵で、秘密鍵は自分だけが守る鍵です。

この考え方は、共通鍵暗号と大きく異なります。
共通鍵暗号では、同じ鍵を持っている人同士で暗号化と復号を行います。
一方、公開鍵暗号では、役割の異なる2つの鍵を使います。

身近なイメージとしては、「誰でも入れられる郵便受け」と「持ち主だけが開けられる鍵」に近いです。
公開鍵を使えば誰でもデータを暗号化できますが、それを復号できるのは秘密鍵を持つ人だけ、という説明がよく使われます。

代表例としては、RSAがあります。
RFC 8017は、RSAに基づく公開鍵暗号の実装に関する推奨を示し、暗号化方式、署名方式、鍵表現などを扱っています。
参考: RFC 8017 - PKCS #1: RSA Cryptography Specifications Version 2.2

ただし、現代の通信では、公開鍵暗号で大きなデータを直接すべて暗号化するよりも、鍵共有やデジタル署名の土台として使う場面が多くあります。
大量の通信データは共通鍵暗号で処理し、その共通鍵を安全に準備するために公開鍵暗号系の仕組みを使う、という組み合わせがよく使われます。

💡 豆知識
公開鍵暗号は「公開してもよい鍵がある」という点で、最初は少し不思議に感じる技術です。
しかし、公開鍵でできることと秘密鍵でしかできないことを分けることで、インターネット上の見知らぬ相手とも安全な通信を始めやすくなります。

公開鍵暗号の全体像と共通鍵暗号との違いは、次の個別記事で詳しく扱います。

3.7 デジタル署名：データに「確認できる署名」を付ける

デジタル署名は、秘密鍵で署名を作り、公開鍵で検証する仕組みです。
手書きのサインや印鑑のように「誰が確認したのか」を示す役割がありますが、実際には画像ではなく、数学的に検証できるデータです。

デジタル署名を使うと、主に次のことを確認できます。

確認できること	説明
署名者の確認	対応する秘密鍵を持つ人が署名したことを確認する
改ざん検知	署名後にデータが変わっていないか確認する
否認防止の材料	後から「署名していない」と否定しにくくする

NIST FIPS 186-5は、RSA、ECDSA、EdDSAを含むデジタル署名方式を扱う標準です。
この標準では、デジタル署名がデータの不正な変更の検出や署名者の認証に使われることが説明されています。
参考: NIST FIPS 186-5 - Digital Signature Standard

デジタル署名は、さまざまな場面で使われます。

利用場面	何を確認しているか
TLS証明書	Webサイトが本物か確認する
ソフトウェア配布	配布ファイルが正規のものか確認する
電子契約	文書に対する署名を確認する
ブロックチェーン	送金者が秘密鍵を持っていることを確認する

ここでも大切なのは、署名は「データを隠す技術」ではないという点です。
署名されたデータの中身は、別途暗号化しなければ読める場合があります。
デジタル署名の主な役割は、本人性と改ざん検知です。

3.8 鍵共有・KEM：安全な会話を始めるための準備

共通鍵暗号は高速ですが、同じ鍵をどうやって安全に共有するかが課題でした。
この課題を解決するために使われるのが、鍵共有や鍵カプセル化の仕組みです。

従来よく使われてきた代表例に、Diffie-Hellman鍵共有や、楕円曲線を使うECDHがあります。
これらは、通信相手とやり取りしながら、盗聴者には分からない形で共通鍵を準備するために使われます。

TLS 1.3のような現代的な通信プロトコルでも、通信の最初に鍵を準備し、その後の通信を保護する流れがあります。
参考: RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3

また、耐量子暗号の文脈では、KEM という言葉が重要になります。
KEMはKey Encapsulation Mechanismの略で、日本語では鍵カプセル化メカニズムと呼ばれます。
将来の量子コンピュータを意識した鍵共有の候補として、ML-KEMなどが標準化されています。

ただし、耐量子暗号の詳しい話は本記事の後半で最近の動向として扱い、アルゴリズムの詳細は別記事に分けます。

3.9 パスワードハッシュ：パスワードをそのまま保存しない

ログイン機能を作るときに特に注意したいのが、パスワードの保存です。

パスワードは、原則としてそのまま保存してはいけません。
もしデータベースが漏えいしたとき、平文のパスワードがそのまま残っていると、被害が一気に大きくなってしまいます。

ここで使われるのが、パスワード保存用のハッシュ方式です。
代表例には、Argon2、bcrypt、scryptなどがあります。

通常のハッシュ関数とパスワードハッシュの違いを、ざっくり整理すると次のようになります。

用途	代表例	ポイント
ファイルやメッセージの改ざん検知	SHA-256、SHA-3	高速に計算できることが重要な場面が多い
パスワード保存	Argon2、bcrypt、scrypt	攻撃者による大量推測を難しくすることが重要

つまり、パスワード保存では「高速に計算できること」が必ずしも良いとは限りません。
攻撃者も高速に試せてしまうためです。

本記事では実装方法には入りませんが、初学者向けには次の点だけ覚えておくとよいです。

パスワードは、暗号化して保存するというより、パスワード保存に適した方式でハッシュ化して保存する。
通常のSHA-256などをそのまま使えば十分、とは考えない。

パスワード保存は、実務で非常に重要なテーマなので、次の個別記事で詳しく整理します。

3.10 道具は単体ではなく、組み合わせて使う

ここまで、暗号技術の代表的な道具を見てきました。
ただし、実際のサービスでは、これらの道具が単体で使われることはあまりありません。

たとえば、HTTPS通信では、ざっくり見ると次のような技術が組み合わさっています。

この図はかなり簡略化していますが、雰囲気としては次のような役割分担があります。

役割	関係する技術
サーバーが本物か確認する	証明書、デジタル署名
通信に使う鍵を準備する	鍵共有
通信内容を守る	共通鍵暗号、認証付き暗号
改ざんを検知する	MAC、AEAD

つまり、暗号技術を理解するときは、「どのアルゴリズムが強いか」だけを見るのではなく、どの目的のために、どの道具を、どのように組み合わせているのかを見ることが大切です。

3.11 この章のまとめ

この章では、暗号技術を支える代表的な道具を整理しました。

共通鍵暗号は、大量のデータを高速に暗号化するために使われます。
ハッシュ関数は、データの指紋を作り、改ざん検知などに使われます。
MACは、共有鍵を使ってメッセージの正しさを確認します。
公開鍵暗号は、公開鍵と秘密鍵を分けることで、鍵共有や署名の土台になります。
デジタル署名は、本人性や改ざん検知、否認防止を支えます。
鍵共有やKEMは、安全に通信を始めるための準備として重要です。
パスワードハッシュは、パスワード漏えい時の被害を抑えるために欠かせません。

ここまでで、暗号技術の「道具」の名前と役割が少し見えてきました。
次の章では、これらの道具が実際のサービスやプロトコルの中でどのように組み合わされているのかを、もう少し具体的に見ていきます。

4. 暗号技術はどう組み合わされているか

この章では、暗号技術の地図のうち 「実サービスではどう組み合わせるのか」 を見ます。
1つの技術だけを見るのではなく、HTTPS、ログイン、API、ブロックチェーン、クラウド保存の中で複数の技術がどう連携するかを整理します。

前の章では、共通鍵暗号、ハッシュ関数、MAC、公開鍵暗号、デジタル署名、鍵共有、パスワードハッシュなどを「暗号技術の道具箱」として整理しました。

ただし、実際のサービスでは、これらの道具が単体で使われることはあまりありません。
たとえば「HTTPSで通信する」と一言で言っても、その裏側では、サーバー確認、鍵共有、暗号化、改ざん検知など、複数の処理が組み合わさっています。

料理でたとえるなら、包丁、鍋、フライパン、まな板をそれぞれ知っているだけでは料理は完成しません。
大切なのは、それぞれの道具をどの順番で、どの目的で使うかです。

この章では、細かいアルゴリズムやコードには入らず、身近なサービスの中で暗号技術がどのように組み合わされているのかを見ていきます。

4.1 まずは全体像を見る

暗号技術の組み合わせ方は、利用するサービスによって少しずつ変わります。
しかし、代表的な場面を整理すると、次のように見ることができます。

身近な場面	主に守りたいこと	組み合わされる主な技術
HTTPS通信	通信相手の確認、盗聴防止、改ざん検知	証明書、デジタル署名、鍵共有、共通鍵暗号、AEAD
ログイン機能	パスワード漏えい時の被害軽減、ログイン状態の安全な管理	パスワードハッシュ、ソルト、セッション、JWT
API通信	リクエストの改ざん検知、送信元確認、再送攻撃への対策	HMAC、デジタル署名、タイムスタンプ、nonce
ブロックチェーン送金	送金者の確認、取引改ざんの検知、履歴のつながり	デジタル署名、ハッシュ、公開鍵暗号、ハッシュチェーン
クラウド保存	保存データの保護、通信経路の保護、鍵管理	ストレージ暗号化、TLS、鍵管理

この表を見ると、暗号技術は「1つの魔法の技術」ではなく、目的ごとに道具を組み合わせる設計だと分かります。

ここからは、特にイメージしやすい例を順番に見ていきます。

4.2 HTTPS通信：ブラウザで鍵マークが出るまで

Webサイトを開いたとき、URLが https:// から始まっていると、ブラウザに鍵マークが表示されます。
この鍵マークは、「なんとなく安全そう」という飾りではありません。

HTTPSでは、HTTPの通信をTLSというプロトコルで保護しています。
TLS 1.3を定義するRFC 8446では、TLSはインターネット上のクライアントとサーバーの通信について、盗聴、改ざん、メッセージ偽造を防ぐよう設計されていると説明されています。

参考: RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3

かなりざっくり見ると、HTTPS通信では次のような流れで暗号技術が組み合わされます。

それぞれの役割を整理すると、次のようになります。

流れ	何をしているか	関係する技術
サーバーの証明書を確認する	本物のWebサイトか確認する	証明書、デジタル署名
通信用の鍵を作る	ブラウザとサーバーだけが使える鍵を準備する	鍵共有
データを暗号化する	通信内容を第三者に読まれにくくする	共通鍵暗号
改ざんを検知する	通信内容が途中で変えられていないか確認する	AEAD、MAC

ここで大切なのは、公開鍵暗号だけで通信全体を暗号化しているわけではないことです。
実際には、通信の最初に鍵を安全に準備し、その後の大量データは高速な共通鍵暗号で守る、という組み合わせになっています。

TLS 1.3で暗号技術がどう組み合わされているかは、次の個別記事で詳しく整理します。

💡 豆知識
ブラウザの鍵マークは、「そのサイトの内容が正しい」「その会社が安全」と保証しているわけではありません。
主に、通信経路がTLSで保護されていることや、証明書によって接続先を確認できていることを示します。
そのため、鍵マークがあっても、フィッシングサイトや偽の入力フォームには注意が必要です。

4.3 ログイン機能：パスワードはそのまま保存しない

Webサービスにログインするとき、ユーザーはIDとパスワードを入力します。
このとき、サービス側がパスワードをそのまま保存していると、データベースが漏えいした瞬間に大きな被害につながります。

そのため、パスワードは原則として平文のまま保存しません。
OWASPのPassword Storage Cheat Sheetでは、パスワードは平文で保存せず、Argon2id、bcrypt、PBKDF2などの強く遅いハッシュアルゴリズムで保護すべきだと説明されています。
また、レインボーテーブルのような事前計算攻撃を防ぐため、パスワードごとに一意なソルトを加えることも説明されています。

参考: OWASP Password Storage Cheat Sheet

ログイン機能をかなり簡略化すると、次のような流れになります。

この図は実装の細部を省略していますが、考え方としては「入力されたパスワードそのものを保存済みパスワードと比べる」のではなく、「保存用に変換された値を使って確認する」という流れです。

ログインに成功した後は、毎回パスワードを送るのではなく、セッションIDやトークンを使ってログイン状態を管理することが多いです。
ここで出てくる代表的な形式の一つがJWTです。

JWTはRFC 7519で定義されており、2者間でクレーム、つまりユーザーIDや有効期限などの情報をコンパクトに表現するための形式です。

参考: RFC 7519 - JSON Web Token (JWT)

ただし、JWTについては注意が必要です。
署名されたJWTは「改ざんされていないこと」を確認できますが、暗号化されていないJWTの中身はBase64URLで表現されているだけで、秘密情報として隠されているわけではありません。

💡 豆知識
JWTは「暗号化された秘密の箱」と誤解されることがあります。
しかし、署名付きJWTは主に「中身が改ざんされていないこと」を確認するためのものです。
中身を隠したい場合は、JWEなど暗号化を含む別の仕組みを検討する必要があります。

ログイン機能のうち、パスワード保存の注意点は、後半の個別記事一覧から深掘りできます。

JWTについては、今後API・認証認可の記事として別途整理する予定です。

深掘り予定: JWTの仕組みと注意点
深掘り予定: セッション管理とトークン管理の違い

4.4 API通信：リクエストが途中で変わっていないか確認する

Webサービス同士が連携するとき、APIを通じてデータをやり取りすることがあります。
たとえば、決済サービス、クラウドサービス、外部認証サービスなどは、APIを使って他のシステムとつながります。

このとき重要なのは、単に通信を暗号化するだけではありません。
「このリクエストは本当に正しい相手から送られたのか」「途中で内容が書き換えられていないか」「過去のリクエストをコピーして再送していないか」も確認したくなります。

このような場面では、HMACやデジタル署名、タイムスタンプ、nonceなどが組み合わされることがあります。

確認したいこと	使われることがある技術	やさしい説明
リクエストが改ざんされていないか	HMAC、デジタル署名	メッセージに検証用の印を付ける
正しい相手から送られたか	HMAC、デジタル署名	鍵を持つ相手だけが作れる印か確認する
古いリクエストの再送ではないか	タイムスタンプ、nonce	使い回しを検出しやすくする

nonceは、ざっくり言うと「一度だけ使う値」です。
毎回違う値をリクエストに含めることで、過去の通信をコピーしてもう一度送るような攻撃を検出しやすくします。

ただし、ここで注意したいのは、HMACや署名を付ければ自動的に安全になるわけではないことです。
どの項目を署名対象に含めるか、タイムスタンプをどの範囲で許容するか、nonceをどう保存して再利用を防ぐか、といった設計が必要になります。

このあたりは実装に踏み込むと長くなるため、本記事では「API通信では、TLSに加えてメッセージ単位の検証が使われることがある」と押さえておきます。

深掘り予定: HMACでAPIリクエストを検証する考え方
深掘り予定: リプレイ攻撃とnonceの基本
深掘り予定: 署名付き命令でAIエージェントの操作を検証する考え方

4.5 ブロックチェーン送金：暗号化ではなく署名とハッシュが主役になる

ブロックチェーンという言葉を聞くと、「暗号資産だから取引内容は暗号化されている」と感じるかもしれません。
しかし、多くのパブリックブロックチェーンでは、取引データは公開されており、誰でも確認できる形になっています。

ここで主役になるのは、暗号化よりも、デジタル署名やハッシュです。

たとえば、ブロックチェーンで送金する場合、利用者は自分の秘密鍵で取引に署名します。
ネットワーク上の参加者は、その署名を検証することで「この取引は対応する秘密鍵を持つ人によって作られたらしい」と確認できます。

また、ブロック同士をハッシュでつなげることで、過去のデータを後から書き換えにくくしています。
Bitcoinのホワイトペーパーでは、取引をハッシュベースのProof-of-Workのチェーンに入れてタイムスタンプし、後から変更するにはProof-of-Workをやり直す必要がある記録を作る、と説明されています。

参考: Bitcoin: A Peer-to-Peer Electronic Cash System

この例から分かるように、暗号技術は「隠す」ためだけに使われるわけではありません。
ブロックチェーンでは、むしろ「誰でも検証できること」が重要になる場面があります。

💡 豆知識
「暗号資産」という名前から、取引内容がすべて暗号化されて見えないと思われることがあります。
しかし、BitcoinやEthereumのような多くのパブリックチェーンでは、取引履歴は公開されています。
暗号技術は、主に署名、ハッシュ、改ざん耐性のある記録のために使われています。

4.6 クラウド保存：データを守るだけでなく鍵を守る

クラウドストレージにファイルを保存するときも、暗号技術は重要です。
通信中のデータを守るためにはTLSが使われ、保存後のデータを守るためにはストレージ暗号化が使われることがあります。

ただし、ここでも「暗号化しているから安心」と言い切ることはできません。
実際には、暗号化に使う鍵をどこで作るのか、誰が管理するのか、どのタイミングで更新するのか、漏えい時にどう無効化するのかが重要になります。

NIST SP 800-57 Part 1 Rev.5は、暗号鍵管理の一般的なガイダンスとベストプラクティスを扱う文書です。
暗号技術を実システムで使うときは、アルゴリズムだけでなく鍵管理まで含めて考える必要があります。

参考: NIST SP 800-57 Part 1 Rev.5 - Recommendation for Key Management

クラウド保存をざっくり図にすると、次のようになります。

この図で一番見落としやすいのは、最後の「暗号鍵を管理」の部分です。
暗号化されたデータが安全でも、鍵が漏えいしたり、権限の広すぎる人が鍵を使えたりすると、守りたい情報にアクセスされる可能性があります。

そのため、暗号技術を考えるときは「どの方式を使うか」だけでなく、「鍵を誰が、どのように扱うか」まで含めて見ることが大切です。

4.7 組み合わせるときに意識したいこと

ここまでの例から分かるように、暗号技術は道具を組み合わせて使います。
ただし、組み合わせ方を間違えると、安全に見えても弱い設計になることがあります。

特に、次のような点は注意が必要です。

観点	注意したいこと
目的の整理	何を守りたいのかを先に決める。機密性なのか、完全性なのか、認証なのかを混同しない。
標準の利用	独自方式を作らず、標準化された方式や十分検証されたライブラリを使う。
鍵管理	鍵をソースコードに直接書かない。漏えい時の更新・失効も考える。
設定	古い方式や危険なモードを使わない。推奨設定を確認する。
運用	ライブラリ更新、証明書更新、アルゴリズム移行に追従する。

このように見ると、暗号技術は数学だけの話ではなく、設計と運用の話でもあります。
安全なシステムを作るには、アルゴリズムを知るだけでなく、それをどの場面で、どのように使うかを考える必要があります。

4.8 この章のまとめ

この章では、暗号技術が実際のサービスの中でどのように組み合わされているかを見てきました。

HTTPS通信では、証明書、デジタル署名、鍵共有、共通鍵暗号、AEADが組み合わさっています。
ログイン機能では、パスワードハッシュ、ソルト、セッション、JWTなどが関係します。
API通信では、TLSに加えてHMACや署名、タイムスタンプ、nonceが使われることがあります。
ブロックチェーンでは、暗号化よりもデジタル署名やハッシュが重要な役割を持ちます。
クラウド保存では、データの暗号化だけでなく鍵管理が重要です。

つまり、暗号技術は単体で覚えるよりも、「どの目的のために、どの道具を、どう組み合わせるのか」と考える方が理解しやすくなります。

次の章では、ここまで見てきた暗号技術が、最近どのように変化しているのかを整理します。
特に、耐量子暗号、暗号アジリティ、軽量暗号、プライバシー強化暗号といった最近の動向を見ていきます。

5. 最近の動向：暗号技術は「一度決めたら終わり」ではない

この章では、暗号技術の地図に 「時間軸」 を加えます。
暗号技術は昔からある分野ですが、量子計算機、IoT、プライバシー保護の需要によって、現在も使い方や推奨が変わり続けています。

ここまで、暗号技術が何を守るのか、どのような道具があるのか、実際のサービスでどう組み合わされるのかを見てきました。
ここで最後に押さえておきたいのが、暗号技術は一度選んだら終わりではないという点です。

暗号技術は、数学的な研究、計算機の性能向上、攻撃手法の発見、標準化の更新によって、少しずつ使い方や推奨が変わります。
昔は十分安全だと考えられていた方式でも、現在では新規利用を避けるべきものがあります。

たとえるなら、暗号技術は「一度買えばずっと使える金庫」というより、定期的に点検し、必要に応じて交換する鍵や防犯設備に近いです。

この章では、最近の動向を単なる用語紹介としてではなく、次の視点で整理します。

なぜ今、その技術が話題になっているのか
既存の暗号技術とどのようにつながっているのか
初学者はどの程度まで押さえればよいのか

最近の動向	ざっくり言うと	なぜ今見るべきか	初学者が押さえる範囲
耐量子暗号	量子コンピュータ時代に備える暗号	長期的に守る情報や大規模システムでは移行準備が必要になるため	RSAや楕円曲線暗号の将来的な課題と、PQCという方向性
暗号アジリティ	暗号方式を交換しやすくする設計	暗号方式や推奨は変わるため、固定しすぎると移行が難しくなるため	「どこで何を使っているか」を把握し、変更できる設計にする考え方
軽量暗号	小さな機器でも使いやすい暗号	IoTや組込み機器では計算能力・メモリ・電力に制約があるため	サーバー向け暗号とは違う制約があること
プライバシー強化暗号	秘密を見せずに証明・計算する暗号	データ活用とプライバシー保護を両立したい場面が増えているため	ゼロ知識証明、MPC、FHEなどの考え方

5.1 耐量子暗号：将来の量子コンピュータに備える

最近の暗号分野で特に大きな話題が、耐量子暗号です。
英語では Post-Quantum Cryptography、略して PQC と呼ばれます。

ざっくり言うと、耐量子暗号は「将来、十分に強力な量子コンピュータが登場しても破られにくいように設計された暗号技術」です。

現在広く使われているRSAや楕円曲線暗号は、特定の数学問題が現在のコンピュータでは解きにくいことを安全性の土台にしています。
しかし、将来的に大規模な量子コンピュータが実用化されると、これらの前提が崩れる可能性があります。

ここで注意したいのは、「量子コンピュータが出たら、明日すぐにすべての暗号が終わる」という話ではないことです。
現実的には、長期的に守る必要がある情報や、大規模システムの移行に時間がかかることを考えて、早めに準備を始める必要がある、という話です。

NISTは2024年8月に、耐量子暗号に関する3つのFIPS標準を公開しました。
2026年6月25日時点では、少なくとも次の3つはPQCを学ぶときの重要な入口になります。

標準	方式	主な用途	この記事での見方
FIPS 203	ML-KEM	鍵共有・鍵カプセル化	将来の安全な鍵共有の候補
FIPS 204	ML-DSA	デジタル署名	将来の署名方式の候補
FIPS 205	SLH-DSA	ハッシュベースのデジタル署名	別の設計思想を持つ署名方式

参考: NIST - NIST Releases First 3 Finalized Post-Quantum Encryption Standards
参考: NIST FIPS 203 - ML-KEM
参考: NIST FIPS 204 - ML-DSA
参考: NIST FIPS 205 - SLH-DSA

また、NISTは2025年に、ML-KEMのバックアップとなる追加の耐量子暗号アルゴリズムとしてHQCを選定したと公表しています。
参考: NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption

日本でも、CRYPTREC暗号リストが更新され、2026年3月30日の改訂で鍵共有のML-KEMが電子政府推奨暗号リストに追加されています。
参考: CRYPTREC - 新着情報
参考: CRYPTREC暗号リスト

💡 豆知識
耐量子暗号は「量子コンピュータを使った暗号」ではありません。
量子コンピュータに対しても破られにくいように、現在のコンピュータ上で動く暗号方式です。
名前だけ見ると少し誤解しやすいポイントです。

Harvest Now, Decrypt Later という考え方

耐量子暗号の話でよく出てくるのが、Harvest Now, Decrypt Later という考え方です。
これは、今すぐ解読できなくても、暗号化された通信を今のうちに保存しておき、将来の技術で解読しようとする攻撃を指します。

たとえば、数年後・十数年後にも秘密である必要がある情報は、現在の暗号で守られていても、将来の解読リスクを考える必要があります。

CISA、NSA、NISTの共同資料では、量子耐性への移行に向けて、ロードマップ作成、暗号資産の棚卸し、リスク評価、ベンダーとの連携などを始めることが推奨されています。
参考: Quantum-Readiness: Migration to Post-Quantum Cryptography

この話は、初学者にとって少し遠い未来の話に見えるかもしれません。
しかし、ここで大切なのは「PQCの細かい数式を今すぐ理解すること」ではなく、暗号技術には移行準備が必要になることを知ることです。

耐量子暗号の全体像は、次の個別記事で詳しく整理します。

5.2 暗号アジリティ：暗号方式を交換しやすくする

耐量子暗号とセットで重要になるのが、暗号アジリティです。

暗号アジリティとは、暗号方式、鍵長、ライブラリ、プロトコルの設定などを、必要に応じて交換・更新しやすくしておく考え方です。
英語では cryptographic agility や crypto-agility と呼ばれます。

たとえば、システムのあちこちに暗号方式が直接書き込まれていて、どこで何を使っているか分からない状態だと、古い方式をやめたいときに大変です。
逆に、どこでどの暗号を使っているか整理されていて、設定変更やライブラリ更新で切り替えられる設計なら、移行しやすくなります。

NIST SP 800-131A Rev.2は、より強い暗号鍵やより堅牢なアルゴリズムへの移行に関するガイダンスを示しています。
また、SP 800-131A Rev.3の初期公開ドラフトでも、暗号技術の変化に応じた移行計画の重要性が扱われています。
参考: NIST SP 800-131A Rev.2
参考: NIST SP 800-131A Rev.3 Initial Public Draft

暗号アジリティは、特定のアルゴリズム名を覚えることよりも、実務では重要になる場合があります。
なぜなら、暗号技術は時間とともに変わるため、「今どの方式が強いか」だけでなく、「将来どう交換できるか」も設計に含める必要があるからです。

💡 豆知識
暗号アジリティは、スマホのOSアップデートに少し似ています。
今の状態で問題なく動いていても、脆弱性や新しい攻撃が見つかれば更新が必要になります。
暗号も同じで、「使えること」と「安全に使い続けられること」は別の問題です。

暗号アジリティの考え方は、次の個別記事で詳しく整理します。

5.3 軽量暗号：小さな機器でも使いやすくする

暗号技術は、サーバーやPCだけで使われるわけではありません。
センサー、家電、ICカード、医療機器、車載機器など、計算能力やメモリ、電力に制約のある機器でも使われます。

このような環境では、通常のPCやサーバーで使いやすい方式が、そのまま最適とは限りません。
そこで注目されるのが、軽量暗号です。

軽量暗号は、限られた資源の中でも使いやすいように設計された暗号技術です。
ただし、「軽いから安全性が低い」という意味ではありません。
限られた環境でも、必要な安全性を実現できるように設計・評価された方式を使うことが重要です。

NISTは2025年8月に、制約のあるデバイス向けの軽量暗号標準として、AsconベースのSP 800-232を公開しました。
この文書では、Ascon-AEAD128、Ascon-Hash256、Ascon-XOF128、Ascon-CXOF128が扱われています。
参考: NIST SP 800-232 - Ascon-Based Lightweight Cryptography Standards for Constrained Devices

利用環境	重要になりやすい観点
Webサーバー	処理性能、標準対応、証明書管理
スマートフォン	バッテリー、OS・ブラウザの対応
IoT機器	メモリ、消費電力、実装サイズ、長期運用
ICカード・組込み機器	物理的な攻撃、処理時間、コスト

軽量暗号は、今後IoTやエッジデバイスが増えるほど重要になります。
特に、長期間交換されない機器では、設計時点で暗号方式と更新方法をよく考える必要があります。

ここでも、この記事の軸である「地図」として見る考え方が役立ちます。
軽量暗号は、AESやTLSを置き換える万能の技術というより、制約のある場所で安全性を確保するための選択肢として理解すると分かりやすいです。

軽量暗号とAsconの位置づけは、次の個別記事で詳しく整理します。

5.4 プライバシー強化暗号：隠したまま証明・計算する

近年は、データをただ隠すだけでなく、隠したまま活用する技術も注目されています。
これらは、プライバシー強化暗号、または Privacy-Enhancing Cryptography と呼ばれることがあります。

たとえば、次のような場面を考えます。

年齢そのものを見せずに「20歳以上であること」だけを示したい
会社同士が顧客リストを直接見せずに、共通する顧客だけを調べたい
医療データを暗号化したまま、統計処理だけを行いたい

このような場面では、ゼロ知識証明、MPC、完全準同型暗号、Private Set Intersectionなどが関係します。

技術	やさしく言うと	使われる場面の例
ゼロ知識証明	秘密を見せずに、条件を満たすことを証明する	ブロックチェーン、匿名認証、本人確認
MPC	複数人がデータを隠したまま共同計算する	金融、統計、不正検知
完全準同型暗号	暗号化したまま計算する	クラウド上の秘匿計算
Private Set Intersection	お互いの集合を見せずに共通部分を調べる	顧客照合、不正対策

NISTのPrivacy-Enhancing Cryptographyプロジェクトでは、ゼロ知識証明、MPC、完全準同型暗号などが、プライバシーを高める暗号技術として扱われています。
参考: NIST Privacy-Enhancing Cryptography

💡 豆知識
ゼロ知識証明は、「答えそのものを見せずに、答えを知っていることを示す」ような考え方です。
たとえば、合言葉を直接言わずに、合言葉を知っている人だけが通れる仕組みを作るイメージに近いです。

この分野は、暗号技術の中でも発展的な内容です。
そのため本記事では、「暗号技術には、秘密にするだけでなく、秘密を保ったまま証明・計算する方向もある」と押さえれば十分です。

ゼロ知識証明の考え方は、次の個別記事で詳しく整理します。

5.5 最近の動向を学ぶときの注意

最近の動向は面白い一方で、用語だけを追いかけると混乱しやすくなります。
そのため、初学者の段階では、次のように位置づけると学びやすいです。

学ぶ内容	最初の理解として十分なこと	深掘りするタイミング
耐量子暗号	将来の量子計算機に備えるための移行先候補	RSA、楕円曲線暗号、鍵共有を学んだ後
暗号アジリティ	暗号方式は将来交換できる設計にしておく	システム設計や運用を考えるとき
軽量暗号	IoTや組込み機器では制約が違う	組込み・IoTセキュリティを学ぶとき
プライバシー強化暗号	秘密を見せずに証明・計算する技術群	ゼロ知識証明や秘匿計算を学ぶとき

本記事では、ここまでの章で「何を守るのか」「どの道具を使うのか」「どう組み合わせるのか」を整理してきました。
最近の動向も、その地図の上に置いてみると理解しやすくなります。

次の章では、ここまでの内容を踏まえて、初学者が特に混同しやすいポイントを整理します。
用語を一つずつ覚えるだけでなく、「どの場面で何を使うのか」を意識すると、暗号技術はかなり見通しやすくなります。

6. 初学者が混同しやすいポイント

この章では、暗号技術の地図を読むときに 道を間違えやすいポイント を整理します。
似た言葉の違いを確認しておくと、個別記事に進んだときに理解しやすくなります。

ここまで、暗号技術の道具と、その組み合わせ方、最近の動向を見てきました。
ただ、暗号技術は似た言葉が多いため、最初のうちは混同しやすい部分があります。

この章では、初学者がつまずきやすいポイントを、できるだけ身近な例に置き換えながら整理します。
詳しいアルゴリズムやコードはここでは扱わず、「何が違うのか」「どんな場面で注意するのか」に絞って見ていきます。

6.1 「暗号」と「暗号化」は同じではない

まず混同しやすいのが、「暗号」と「暗号化」という言葉です。

日常会話では「暗号」と聞くと、文章を読めない形に変換するイメージが強いかもしれません。
たしかに、暗号化は暗号技術の代表的な使い方です。

しかし、この記事で扱っている暗号技術は、それよりも広い意味を持ちます。
情報を読まれないようにするだけでなく、改ざんされていないか確認したり、本当に本人が送ったものかを確かめたり、秘密を見せずに条件だけを証明したりする技術も含まれます。

用語	ざっくりした意味	例
暗号技術	情報を安全に扱うための技術全体	暗号化、署名、ハッシュ、鍵共有など
暗号化	情報を読めない形に変える処理	メッセージやファイルの暗号化
復号	暗号化された情報を元に戻す処理	暗号化ファイルを開く

たとえるなら、「暗号技術」は工具箱全体で、「暗号化」はその中に入っているドライバーのような道具の一つです。
ドライバーだけでも便利ですが、実際の作業ではペンチ、レンチ、メジャーなど、いろいろな道具を組み合わせます。

暗号技術も同じで、暗号化だけでは現代のサービスを十分に守れません。
たとえばHTTPSでは、通信内容の暗号化だけでなく、サーバー証明書による相手確認、鍵共有、改ざん検知などが組み合わされています。
TLS 1.3の仕様であるRFC 8446でも、TLSは通信の盗聴、改ざん、メッセージ偽造を防ぐための安全な通信路を提供するプロトコルとして説明されています。
参考: RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3

6.2 「ハッシュ化」は「暗号化」ではない

次によくある混同が、「ハッシュ化」と「暗号化」です。

暗号化は、正しい鍵を持っていれば元のデータに戻せます。
一方、暗号学的ハッシュ関数は、基本的には元に戻すことを目的としていません。

たとえば、料理で考えると分かりやすいです。

暗号化: 鍵付きの箱にレシピを入れる
復号: 正しい鍵で箱を開けてレシピを読む
ハッシュ化: 完成した料理の「特徴的な指紋」を作る

完成した料理を見ても、元の材料や分量を完全に復元するのは難しいですよね。
ハッシュもそれに近く、入力データから固定長の値を作りますが、その値から元の入力を復元するためのものではありません。

比較項目	暗号化	ハッシュ化
元に戻すこと	鍵があれば戻せる	基本的に戻さない
主な目的	内容を読まれないようにする	改ざん確認、識別、照合
代表例	AES、ChaCha20	SHA-256、SHA-3
身近な例	暗号化された通信、暗号化ファイル	ファイルの改ざん確認、ブロックチェーンの取引ID

ここで注意したいのは、「ハッシュ化しているから安全」と単純には言えないことです。
特にパスワード保存では、通常の高速なハッシュ関数をそのまま使うと、攻撃者が大量の候補を高速に試せてしまう可能性があります。

OWASP Password Storage Cheat Sheetでは、パスワードを平文で保存してはいけないことに加え、Argon2id、bcrypt、PBKDF2のような、パスワード保存に適した方式を使うことが説明されています。
また、SHA-256のような高速なハッシュ関数は、攻撃者が多くの推測を素早く試せるため、パスワード保存には適さないとされています。
参考: OWASP Password Storage Cheat Sheet

💡 豆知識
「ハッシュ化されたパスワードを復号する」という表現を見かけることがありますが、厳密には少し不自然です。
ハッシュは元に戻すためのものではないため、「復号」ではなく「推測したパスワードを同じ方法でハッシュ化して照合する」と考える方が正確です。

6.3 「暗号化している」だけでは改ざんを防げない

「通信内容を暗号化しているなら、改ざんも防げるのでは？」と思うかもしれません。
しかし、暗号化の方式や使い方によっては、機密性は守れても、改ざん検知が十分でない場合があります。

ここで登場するのが、MACや認証付き暗号です。

MACは、共有鍵を使って「このメッセージは途中で変わっていないか」「同じ鍵を持つ相手が作ったものか」を確認する仕組みです。
認証付き暗号、特にAEADは、暗号化による機密性と、改ざん検知・認証をまとめて扱える方式です。

RFC 5116では、Authenticated Encryptionは、暗号化された平文の機密性に加えて、完全性と真正性を確認する方法を提供すると説明されています。
参考: RFC 5116 - An Interface and Algorithms for Authenticated Encryption

守りたいこと	必要になる考え方
内容を読まれたくない	暗号化
内容を書き換えられたくない	MAC、認証付き暗号、署名
誰が送ったか確認したい	MAC、署名、証明書

最近の実装では、暗号化だけを単独で考えるより、AES-GCMやChaCha20-Poly1305のような認証付き暗号を使う場面が多くあります。
本記事では内部アルゴリズムには入りませんが、「暗号化と改ざん検知はセットで考える」という感覚を持っておくと、後の理解が楽になります。

6.4 MACとデジタル署名は似ているが、使いどころが違う

MACとデジタル署名は、どちらも「データが改ざんされていないか」「正しい相手が作ったものか」を確認するために使われます。
そのため、最初はかなり似て見えます。

違いをざっくり言うと、MACは「同じ秘密を知っている仲間内で確認する仕組み」、デジタル署名は「公開鍵を使って第三者にも確認してもらえる仕組み」です。

比較項目	MAC	デジタル署名
使う鍵	共有鍵	秘密鍵と公開鍵
作成できる人	共有鍵を持つ人	秘密鍵を持つ人
検証できる人	共有鍵を持つ人	公開鍵を持つ人
第三者への証明	あまり向かない	向いている
例	サーバー間API通信	電子署名、証明書、ブロックチェーン送金

たとえば、社内の2つのサーバーだけが同じ鍵を持っていて、「このAPIリクエストは本物か」を確認するならMACが向いている場合があります。
一方で、ブロックチェーンの送金のように、世界中のノードが「この送金は秘密鍵の持ち主が作ったものか」を検証する場合は、デジタル署名が重要になります。

NIST FIPS 186-5では、デジタル署名はデータの不正な変更の検出、署名者の認証、さらに署名者が後から署名を否定しにくくする性質に関係すると説明されています。
参考: NIST FIPS 186-5 - Digital Signature Standard

💡 豆知識
MACは「合言葉を知っている人同士の確認」に近く、デジタル署名は「印鑑証明付きのサイン」に近いイメージです。
ただし、これはあくまで理解しやすくするための例えです。実際の安全性は、鍵の管理、アルゴリズム、実装方法に大きく左右されます。

6.5 公開鍵暗号は「大量データをそのまま暗号化する主役」ではない

公開鍵暗号は、初学者向けの説明では「公開鍵で暗号化して、秘密鍵で復号する」と紹介されることが多いです。
この説明自体は間違いではありません。

ただし、実際の通信では、大量のデータを公開鍵暗号だけで直接暗号化することは一般的ではありません。
公開鍵暗号は計算コストが高いため、通信の最初に安全な鍵を準備したり、デジタル署名で本人性を確認したりする場面で重要になります。

HTTPS通信をかなり単純化すると、次のようなイメージです。

ここで大切なのは、公開鍵暗号と共通鍵暗号が役割分担していることです。

技術	得意なこと	苦手なこと
共通鍵暗号	大量データを高速に暗号化する	事前に鍵を安全に共有する必要がある
公開鍵暗号	鍵共有、署名、相手確認に使いやすい	大量データの直接暗号化には向きにくい

つまり、公開鍵暗号は「全部を一人で処理する主役」というより、「安全な通信を始めるための準備役」や「本人確認のための証明役」として活躍することが多いです。

6.6 JWTは「見えない」わけではない

Web APIやログイン機能を学んでいると、JWTという言葉を見かけることがあります。
JWTは、ユーザーIDや権限などの情報を、コンパクトな形でやり取りするための形式です。

ここで注意したいのは、JWTは常に暗号化されているわけではないという点です。
JWTはJWSとして署名されることもあれば、JWEとして暗号化されることもあります。
署名されたJWTは、改ざんされていないかは検証できますが、中身そのものはBase64URLでエンコードされているだけの場合があります。

RFC 7519では、JWTは2者間でクレームを表現するコンパクトでURL-safeな手段として定義され、クレームはJWSのペイロードとして完全性保護されたり、JWEの平文として暗号化されたりすると説明されています。
参考: RFC 7519 - JSON Web Token (JWT)

JWTの状態	中身は読めるか	主な目的
署名なしJWT	読める	基本的に実運用では注意が必要
JWSとして署名されたJWT	読めることが多い	改ざん検知
JWEとして暗号化されたJWT	読めない	機密性の保護

そのため、署名付きJWTにパスワードや秘密情報を入れるのは危険です。
「署名されている」ことと「暗号化されている」ことは別物として考える必要があります。

💡 豆知識
JWTの文字列はドットで3つに区切られていることが多いです。
ただし、見た目がそれっぽいからといって安全とは限りません。重要なのは、署名検証、期限、発行者、受信者、保存場所などを正しく扱うことです。

6.7 「ライブラリを使っているから安全」とは限らない

暗号技術を自作しないことはとても重要です。
実務では、十分に検証された標準的なライブラリやプロトコルを使うべきです。

ただし、ライブラリを使っていれば必ず安全、というわけでもありません。

たとえば、次のようなミスがあると、強いアルゴリズムを使っていても安全性が下がる可能性があります。

よくあるミス	なぜ危険か
秘密鍵やAPIキーをソースコードに書く	GitHubなどに漏れる可能性がある
nonceやIVを誤って再利用する	暗号方式によっては安全性が大きく崩れる
古い方式を新規利用する	既知の攻撃や非推奨化の影響を受ける
署名検証を省略する	改ざんされたデータを信じてしまう
エラー時の処理が甘い	例外時に安全でない状態になる
鍵の更新・失効手順がない	漏えい時に被害を止めにくい

暗号の安全性は、アルゴリズムだけで決まるわけではありません。
鍵管理、乱数、設定、エラー処理、ログ、運用ルールまで含めて考える必要があります。

NIST SP 800-57 Part 1 Rev.5は、暗号鍵の管理に関する一般的なガイダンスとベストプラクティスを扱っています。
参考: NIST SP 800-57 Part 1 Rev.5 - Recommendation for Key Management

6.8 量子コンピュータで「明日すべての暗号が終わる」わけではない

最近の暗号技術の話題として、量子コンピュータと耐量子暗号があります。
この話題は重要ですが、少し誤解も生まれやすいです。

量子コンピュータが発展すると、現在広く使われているRSAや楕円曲線暗号の安全性に影響が出ると考えられています。
そのため、NISTは耐量子暗号の標準化を進め、2024年にFIPS 203、FIPS 204、FIPS 205を承認しました。
参考: NIST - Post-Quantum Cryptography FIPS Approved

ただし、これは「明日からすべての暗号が使えなくなる」という意味ではありません。
現実的には、長期間守る必要のある情報をどう移行するか、既存システムでどの暗号方式が使われているかを棚卸しすることが重要になります。

前章で触れた暗号アジリティは、この文脈で特に大切です。
将来アルゴリズムを変更しやすい設計にしておくことで、標準や推奨の変化に対応しやすくなります。

6.9 この章のまとめ

ここまで見てきた混同ポイントを、最後にもう一度整理します。

混同しやすいこと	正しくは
暗号 = 暗号化	暗号技術には署名、ハッシュ、鍵共有なども含まれる
ハッシュ化 = 暗号化	ハッシュは基本的に元に戻すためのものではない
暗号化すれば改ざんも防げる	改ざん検知にはMAC、署名、認証付き暗号などが必要
MACと署名は同じ	MACは共有鍵、署名は秘密鍵・公開鍵を使う
公開鍵暗号だけで通信を全部守る	実際には共通鍵暗号と組み合わせることが多い
JWTは中身が見えない	署名付きJWTは読めることがある。暗号化とは別
ライブラリを使えば安全	設定、鍵管理、乱数、運用を間違えると危険
量子コンピュータで明日すべて終わる	重要なのは段階的な移行準備と暗号アジリティ

暗号技術は、最初から細かい数式やアルゴリズムをすべて理解しようとすると、かなり難しく感じます。
しかし、「どの技術が、何を守るために使われるのか」を分けて考えると、全体像は少しずつ見えてきます。

次の章では、暗号技術をこれから学んでいくときに、どの順番で理解すると進めやすいかを整理します。

7. 暗号技術を学ぶ順番

本記事を読み終えた後に、どの個別記事から深掘りすればよいかを決めるための章です。

前の章では、暗号技術で混同しやすいポイントを整理しました。
ここまで読んで、「結局、どこから学べばよいのか」と感じた人もいるかもしれません。

暗号技術は範囲が広いため、最初からすべてを細かく理解しようとすると大変です。
そのため、まずはアルゴリズム名ではなく、何を守りたいのかから考えると学びやすくなります。

7.1 学習ロードマップ

この記事の内容をもとに学習順を作るなら、次の流れが進めやすいです。

Step	学ぶこと	まず見るポイント
1	暗号技術が守る性質	機密性、完全性、認証、否認防止、鍵共有、プライバシー保護
2	共通鍵暗号と公開鍵暗号	大量データを守るのか、鍵共有や署名に使うのか
3	ハッシュ・MAC・署名	改ざん検知、送信者確認、第三者による検証の違い
4	TLS・JWTなどのプロトコル	複数の暗号技術がどう組み合わされるか
5	パスワード保存・鍵管理	アルゴリズムだけでなく、運用で何を守るか
6	耐量子暗号・軽量暗号	将来の移行や制約環境にどう備えるか
7	ゼロ知識証明・MPC・FHE	秘密を見せずに証明・計算する考え方

この順番にすると、最初に全体像をつかみ、その後に具体的な技術や応用へ進めます。
逆に、いきなり耐量子暗号やゼロ知識証明から入ると、前提となる共通鍵暗号、公開鍵暗号、ハッシュ関数などの理解が追いつかず、途中でつまずきやすくなります。

7.2 迷ったときの選び方

学ぶ順番に迷ったときは、次のように「知りたいこと」から選ぶと分かりやすいです。
この章では学習の選び方に集中し、個別記事へのリンクは後半の「関連する個別記事一覧」にまとめます。

知りたいこと	次に読むテーマ	深掘りする内容	優先度
ハッシュ化と暗号化の違いを整理したい	ハッシュ関数とは何か	ハッシュ関数の役割、暗号化との違い、改ざん検知	A
MACと署名の違いがまだ曖昧	MACとデジタル署名の違い	共有鍵の有無、検証できる人、否認防止の違い	A
共通鍵暗号と認証付き暗号を理解したい	共通鍵暗号と認証付き暗号	AES、AEAD、AES-GCM、改ざん検知との関係	A
公開鍵と秘密鍵の関係を整理したい	公開鍵暗号とは何か	公開鍵・秘密鍵、鍵共有、署名、証明書	A
HTTPSの裏側をもう少し知りたい	TLS 1.3での暗号技術の組み合わせ	証明書、鍵共有、共通鍵暗号、AEADの組み合わせ	A
パスワード保存で何をしてはいけないか知りたい	パスワード保存と専用ハッシュ	ソルト、ストレッチング、Argon2id、bcrypt、漏えい時のリスク	A
最近よく聞くPQCを整理したい	耐量子暗号とは何か	ML-KEM、ML-DSA、SLH-DSA、移行準備	B
暗号方式を将来交換しやすくする考え方を知りたい	暗号アジリティ	暗号移行、棚卸し、設計・運用上の注意	B
IoTや組込み機器での暗号を知りたい	軽量暗号	制約デバイス、Ascon、軽量暗号の位置づけ	B
秘密を見せずに証明する技術を知りたい	ゼロ知識証明	証明者、検証者、ブロックチェーンや本人確認での使われ方	B

この表は、総論記事から個別記事へ進む前に、「どのテーマを読むと自分の疑問に近いか」を選ぶためのものです。
実際の個別記事リンクは、まとめとして後半に掲載します。

7.3 この章のまとめ

暗号技術を学ぶときは、いきなり難しい数式やアルゴリズムから入るよりも、次の順番で進めると理解しやすくなります。

暗号技術が守る性質を理解する
共通鍵暗号と公開鍵暗号の違いを理解する
ハッシュ関数、MAC、デジタル署名を整理する
TLSやJWTなど、実際のプロトコルでの使われ方を見る
パスワード保存、鍵管理、運用上の注意を学ぶ
耐量子暗号、軽量暗号など最近の動向を追う
ゼロ知識証明、MPC、FHEなど発展的な暗号へ進む

暗号技術は範囲が広いですが、役割ごとに分けて学ぶと、少しずつ地図が見えてきます。
次の章では、本記事全体の内容をまとめます。

8. まとめ

最後に、本記事で作った「暗号技術の地図」を振り返ります。
暗号技術を用語として覚えるのではなく、何を守り、どの道具を使い、どこで組み合わせるのかという視点で整理します。

この記事では、暗号技術をいきなり数式やアルゴリズムから説明するのではなく、スマホ決済、Webログイン、HTTPS通信、API、ブロックチェーン、クラウド保存などの身近な例から整理しました。

暗号技術と聞くと、「情報を読めない形に変換する技術」というイメージが強いかもしれません。
もちろん、通信内容や保存データを第三者に読まれないようにすることは、暗号技術の大切な役割です。

ただし、本記事で見てきたように、暗号技術が支えているものはそれだけではありません。

通信内容を盗み見られないようにする
データが途中で書き換えられていないか確認する
通信相手や送信者が本物か確認する
後から「自分は操作していない」と否定しにくくする
安全に共通鍵を準備する
必要以上に情報を出さずに証明・計算する

このように見ると、暗号技術は「情報を隠すための技術」というより、デジタル社会の中で安全なやり取りを成立させるための土台と言えます。

8.1 暗号技術は単体ではなく組み合わせて使われる

本記事で特に意識したいポイントは、暗号技術は単体で完結するものではないということです。

たとえばHTTPS通信では、サーバー証明書による相手確認、鍵共有による共通鍵の準備、共通鍵暗号による通信内容の保護、MACやAEADによる改ざん検知など、複数の仕組みが組み合わされています。

ログイン機能でも、パスワード保存にはパスワードハッシュが使われ、ログイン後のAPI通信ではトークンや署名が関係することがあります。
ブロックチェーンでは、ハッシュ関数やデジタル署名が、取引の検証やデータのつながりを支えています。

つまり、暗号技術を理解するときは、「どの方式が一番強いか」だけを見るのではなく、次のように考えることが大切です。

見るべき観点	考えること
何を守りたいのか	機密性、完全性、認証、否認防止など
どこで使うのか	通信、保存、ログイン、API、署名、ブロックチェーンなど
どの技術を組み合わせるのか	共通鍵暗号、公開鍵暗号、ハッシュ、MAC、署名など
鍵をどう扱うのか	生成、保存、更新、失効、用途分離など
将来の変更に対応できるか	暗号アジリティ、耐量子暗号への移行など

8.2 「正しいアルゴリズム」だけでは足りない

暗号技術では、標準化された安全なアルゴリズムを選ぶことが重要です。
しかし、それだけで安全になるわけではありません。

たとえば、強い暗号方式を使っていても、秘密鍵をソースコードに直接書いてしまったり、乱数の使い方を間違えたり、古い方式を使い続けたりすると、安全性は大きく下がります。

暗号では、アルゴリズムだけでなく、実装、設定、鍵管理、運用、移行計画まで含めて考える必要があります。
NIST SP 800-57 Part 1 Rev.5でも、暗号鍵管理に関する考え方やベストプラクティスが整理されています。
参考: NIST SP 800-57 Part 1 Rev.5 - Recommendation for Key Management

ここは、実務でも研究でもとても重要な点だと思います。
暗号技術を学ぶときは、「仕組みを理解すること」と「安全に使うこと」を分けずに、両方を意識したいです。

8.3 最近の動向も押さえておきたい

暗号技術は、昔からある技術でありながら、現在も変化し続けています。

特に近年は、量子コンピュータの発展を見据えた耐量子暗号、IoTや組込み機器に向けた軽量暗号、ゼロ知識証明やMPC、完全準同型暗号のようなプライバシー強化暗号が注目されています。

NISTは2024年に耐量子暗号標準としてFIPS 203、FIPS 204、FIPS 205を公開しており、ML-KEM、ML-DSA、SLH-DSAが標準化されています。
参考: NIST - Post-Quantum Cryptography FIPS Approved

また、日本のCRYPTRECでも、2026年3月30日の暗号リスト更新でML-KEMが電子政府推奨暗号リストに追加されています。
参考: CRYPTREC 新着情報

このような動向を見ると、暗号技術は「一度学んだら終わり」ではなく、標準化や推奨の変化を追い続ける必要がある分野だと分かります。

8.4 この記事の位置づけ

本記事では、暗号技術を広く浅く整理することを目的にしました。
そのため、AESの内部構造、RSAや楕円曲線暗号の数学的な仕組み、TLS 1.3の詳細なハンドシェイク、ゼロ知識証明の具体的なプロトコル、実装コードなどは扱っていません。

それらを一つの記事に詰め込むと、全体像が見えにくくなってしまうためです。

本記事の役割は、暗号技術を「用語の一覧」として覚えることではなく、次の3つの視点で見通せるようにすることです。

この方針にした理由は、暗号技術では同じ単語を知っていても、使う場面を誤ると安全性につながらないためです。
たとえば、ハッシュ関数を知っていても、パスワード保存に通常の高速なハッシュ関数だけを使ってよいわけではありません。
また、公開鍵暗号を知っていても、大量データをすべて公開鍵暗号だけで処理するのが一般的とは限りません。

そのため本記事では、「何を守るのか」「どの道具を使うのか」「どう組み合わせるのか」を繰り返し確認できる構成にしました。

この記事を入口として、次のような個別記事で少しずつ深掘りできます。
本文中で同じリンクが何度も登場すると読みづらくなるため、個別記事へのURLはここにまとめます。
次に読みたいテーマに合わせて、以下の個別記事へ進んでください。

系列	個別記事テーマ	本記事とのつながり
基礎編	ハッシュ関数とは何か：暗号化との違いから整理する	ハッシュ化と暗号化の違い、改ざん検知の考え方を深掘りする
基礎編	MACとデジタル署名の違いを整理する	完全性・認証・否認防止の違いを深掘りする
基礎編	共通鍵暗号とは何か：AESと認証付き暗号をざっくり整理する	大量データを守る暗号化とAEADの考え方を深掘りする
基礎編	公開鍵暗号とは何か：共通鍵暗号との違いから整理する	公開鍵・秘密鍵、鍵共有、署名の前提を深掘りする
通信編	TLS 1.3では暗号技術がどう組み合わされているのか	HTTPSで複数の暗号技術がどう連携するかを深掘りする
運用編	パスワード保存に普通のハッシュ関数を使ってはいけない理由	パスワード保存、ソルト、ストレッチング、Argon2idなどを深掘りする
最近動向編	耐量子暗号とは何か：なぜ今移行準備が必要なのか	量子計算機時代に向けた暗号移行を深掘りする
最近動向編	暗号アジリティとは何か：暗号方式を差し替えられる設計を考える	暗号方式を将来変更できる設計・運用を深掘りする
最近動向編	軽量暗号とは何か：IoTや組込み機器でなぜ必要になるのか	制約のある機器で暗号技術を使う考え方を深掘りする
発展編	ゼロ知識証明とは何か：秘密を見せずに正しさを証明する考え方	秘密を見せずに証明するプライバシー強化暗号を深掘りする

暗号技術は、最初は難しく見えます。
しかし、「何を守るための技術なのか」「どの場面で使われるのか」「どの道具を組み合わせているのか」に分けて考えると、少しずつ理解しやすくなります。

この記事が、暗号技術を学び始めるための地図のような役割になればうれしいです。