暗号の種類一覧｜古典・現代・PQCの仕組み

紙にHELLOと書き、文字を3つ先へずらしてKHOORに変えると、暗号はまず手で触れる遊びとして立ち上がります。
そこからブラウザの錠前アイコンを開く気持ちでTLS 1.3の流れを指でなぞると、暗号は遊びではなく、毎日の通信を支える社会基盤だと実感できます。
この記事は、暗号を名前だけで覚えるのではなく、「何を守る技術なのか」を軸に整理したい人に向けた一覧ガイドです。
機密性、完全性、認証、否認防止という役割で見直すと、古典暗号から現代暗号、そして量子耐性暗号までが、ばらばらの話ではなく一本の進化の線でつながります。
シーザー暗号の26通りのずらし方から、AESRSAECC、さらに2024年8月13日に公開されたML-KEMML-DSASLH-DSAまでを比較表で並べると、「どれが強いか」より「どこで何を守るか」が見えてきます。
読んだあとには、暗号を暗記科目ではなく、用途と設計思想で選ぶ地図として眺められるはずです。

暗号の種類はまず何を守る技術かで分ける

4つの機能：機密性・完全性・認証・否認防止

暗号の話がややこしく見えるのは、AESRSASHA-256電子署名のように名前から入りがちだからです。
実際には、先に「何を守りたいのか」を決めると景色が整います。
現代暗号でまず押さえたい機能は4つあります。
機密性、完全性、認証、否認防止です。
それぞれ英語では confidentiality、 integrity、 authentication、 non-repudiation と呼ばれます。

機密性は、「読まれては困る内容を第三者に見せない」ことです。
メッセージアプリで送った内容が、途中の誰かにそのまま読まれない状態を思い浮かべるとつかみやすいはずです。
完全性は、「途中で書き換えられていない」ことです。
ソフトを配布するときにハッシュ値を公開し、ダウンロードしたファイルと照合するのはこのためです。
認証は、「相手が本当にその相手か」を確かめることです。
ログイン画面でパスワードや認証情報を確認する場面が、最も身近な例でしょう。
否認防止は、「あとから自分は送っていないと言えない状態を作る」ことです。
契約書への電子署名が典型です。

筆者はこの4つを説明するとき、難しい用語をいったん脇に置いて、小さな演習のように日常へ当てはめます。
メッセージアプリは機密性、ソフト配布のハッシュ照合は完全性、ログインは認証、電子署名は否認防止。
ここまで地図が描けると、暗号の種類が「似た言葉の集まり」ではなく、役割の違う道具箱として見えてきます。

そのうえで、各技術がどの機能を主に担うかを並べると、混同しやすいポイントが一度にほどけます。

ここでの「暗号化」は主に平文を読めなくする技術です。
共通鍵暗号のAESやChaCha20が代表例で、大量データの保護に向きます。
ただし暗号化しただけでは、「そのデータを誰が送ったか」や「改ざんされていないか」が自動で証明されるわけではありません。
そこを補うために、ハッシュ、HMAC、署名が登場します。

現代暗号の前提として外せないのが、ケルクホフスの原理です。
安全性はアルゴリズムを秘密にすることではなく、鍵を秘密に保つことに依存させます。
つまり、方式そのものは公開されていて構いません。
AESやRSAの仕様が公開されていても成立するのは、この考え方で設計されているからです。
これは昔の「種明かしされたら終わり」の秘密表と発想が違います。

この文脈では、code と cipher の違いにも一言触れておくと整理が進みます。
code は「特定の語やフレーズを置換表で別の語に置き換える」方式で、たとえば「攻撃開始」をあらかじめ別語に置き換える発想です。
一方の cipher は、文字やビット列に規則的変換をかける方式です。
シーザー暗号やAESはこちらに属します。
現代暗号で中心になるのは code ではなく cipher です。

暗号化とハッシュ化は別物

暗号化とハッシュ化は、見た目こそ「入力を別の文字列に変える」という点で似ていますが、役割は別です。
ここを曖昧にすると、「ハッシュを戻せば元データが出るのでは」という誤解が生まれます。
ハッシュ関数は復号するための箱ではありません。
入力から固定長の値を計算する関数であり、代表例がSHA-256です。
出力されたハッシュ値から元の入力をそのまま復元することは想定されていません。

暗号化は、正しい鍵があれば元に戻すことを前提にしています。
たとえば文書を暗号化して保存するなら、あとで復号して読む必要があります。
つまり「隠すが、必要な人は読める」が暗号化です。
ハッシュは「要約値を作って同一性や改ざんを検査する」が役目です。
元に戻せないからこそ、配布ファイルの照合やパスワード保護に向いています。

筆者がこの違いを実感したのは、ソフト配布ページに並ぶ長い16進文字列を初めて自分で照合したときでした。
あの文字列はファイルそのものの代用品ではなく、ファイルが同一かどうかを見るための指紋です。
1文字でも内容が変われば、ハッシュ値は別物になります。
ここで守っているのは機密性ではなく完全性です。

HMAC（Hash-based Message Authentication Code）は、そのハッシュを一歩進めた道具です。
ハッシュ関数に共有鍵を組み合わせ、改ざん検知と送信者確認を同時に行います。
ハッシュ単体では「同じデータかどうか」は見えても、「その値を誰が作ったか」は証明できません。
HMACは共有鍵を知る当事者どうしだけが正しい値を計算できるため、完全性と認証を担えます。
ただし、鍵を共有する相手が複数いると、「そのうち誰が作ったか」を第三者に対して一意に示せません。
そこで否認防止までは届かない、という位置づけになります。

公開鍵暗号とデジタル署名の役割

公開鍵暗号（public-key cryptography）は、公開鍵と秘密鍵のペアを使う仕組みです。
ただし「公開鍵暗号」と「デジタル署名」は同じものではありません。
公開鍵暗号は、鍵共有や暗号化に使われる枠組みです。
デジタル署名は、その枠組みを利用して送信者証明、改ざん検知、否認防止を実現する仕組みです。
似た材料で別の料理を作っている、と考えると腑に落ちます。

Cloudflare の技術解説や図解（例: TLS ハンドシェイクの解説）は、この流れをつかむうえで参考になります。
参考資料の一例として Cloudflare の解説を挙げます（例: 参考資料の一例として Cloudflare の解説を挙げます（Cloudflare 技術ブログ「TLS 1.3」: デジタル署名は逆向きの使い方をします。
送信者は秘密鍵で署名し、受信者は公開鍵で検証します。
これにより、その公開鍵に対応する秘密鍵を持つ人が署名したこと、署名後に内容が変わっていないことが確認できます。
契約書の電子署名や、配布ソフトに付く署名がこの形です。
ハッシュとの関係も深く、実際には文書そのもの全体に直接署名するというより、文書のハッシュ値に対して署名する構成が一般的です。
だから署名は完全性と認証を同時に支え、さらに「自分は署名していない」と言い逃れしにくい否認防止まで届きます。

公開鍵暗号の代表例としてはRSAやECCがあります。
ECCはRSAより短い鍵長で同程度の安全性水準を目指せる設計で、128ビット安全性の目安としてはAES-128ECC 256bitRSA 3072bitが並べられます。
現代のTLS構成で楕円曲線系が広く使われるのは、この効率の良さがあるからです。
さらに量子計算機への備えとして、2024年8月13日には NIST の最初のPQC標準であるML-KEMML-DSASLH-DSAが公開され、署名と鍵共有の領域でも移行が始まりました。
役割で見る整理は、古典暗号から現代暗号、さらに量子耐性暗号まで、そのまま通用します。

古典暗号一覧——換字式・転置式・機械式

換字式暗号

古典暗号を仕組みで眺めると、まず中核にあるのが換字式暗号です。
これは平文の文字を、別の文字や記号へ置き換える方式です。
英語では substitution cipher と呼ばれます。
見た目は単純でも、ここには現代暗号へつながる発想の芽があります。
元の文字そのものを隠す、という感覚です。

代表例として最初に挙がるのがシーザー暗号です。
各文字を一定数だけずらす方式で、たとえば 3 文字ずらせば A は D、B は E へ移ります。
英字なら鍵候補は 26 通りしかありません。
つまり、総当たりでも全パターンを紙の上で試せる規模です。
前のセクションで触れたHELLO→KHOORはまさにその典型で、暗号の入口としては抜群に手触りがありますが、安全性ステータスは historical です。

筆者は古典暗号を説明するとき、まず紙と鉛筆で短文を1本だけでも実際に変換してもらいます。
英単語でもローマ字でもいいので、5〜8文字ほどの短文を書き、3文字ずらして暗号文にし、今度は逆に3文字戻して復号する。
それだけで「鍵がわかれば戻る」「鍵候補が少ないと破られる」という二つの感覚が一度に入ってきます。
頭で覚えるより、手を動かしたほうが暗号は急に立体的になります。

同じ換字式でも、単一換字式暗号になると話は少し深まります。
これは A→Q、B→M のように、アルファベット全体に1対1の対応表を作って置き換える方式です。
英字 26 文字なら置換の総数は 26!、つまり約 4.03×10^26 通りあります。
数字だけ見ると気が遠くなる規模ですが、それでも historical に留まるのは、文字頻度が平文の癖を運んでしまうからです。
英語なら E、T、A が多く、日本語をローマ字化しても母音や特定の子音の偏りが出ます。
暗号文に最も多く現れる文字、2文字・3文字の繰り返し、単語境界の推定といった観察を重ねると、巨大な鍵空間があっても手がかりは残ります。
ここで効いてくるのが文字頻度分析です。

ヴィジュネル暗号は、単一の換字表ではなく複数の換字表を鍵語に応じて使い分ける多表式暗号です。
長く「破れにくい暗号」と見なされた理由は、単純な頻度分析をそのまま当てにくくした点にあります。
ただし、鍵語が繰り返される構造そのものが弱点にもなります。
暗号文中の繰り返しから鍵長を推定するカシスキーテストを使うと、1本の複雑な暗号文が「鍵長ごとの複数のシーザー暗号」に分解され、そこから再び頻度分析へ戻れます。
破られた理由が曖昧な「なんとなく弱い」ではなく、「周期性が観測できたから」という具体的な構造上の理由を持っているわけです。

ここも、短文ワークをすると理解が一段深まります。
たとえばローマ字で 6〜10 文字ほどの短い文を書き、鍵語を 2〜4 文字決めてヴィジュネル暗号で変換します。
その後、同じ鍵語で復号してみると、シーザー暗号より一歩進んだ「鍵が繰り返し働く感触」が見えてきます。
筆者はこの作業をすると、暗号化というより「文字盤を鍵語のリズムでずらし続ける」感覚に近いと感じます。
古典暗号の面白さは、数式より先に手の感覚で入れるところです。

プレイフェア暗号も換字式暗号の代表格です。
こちらは1文字ではなく2文字の組、つまりダイグラムを単位にして変換します。
5×5 の表を作り、文字の位置関係で置換するため、単文字頻度分析がそのまま通用しません。
とはいえ、2文字組の出現傾向を追う分析で崩せるため、これも安全性ステータスは historical です。
単文字ではなく組み合わせへ分析対象を広げる必要があるので、解読側も一段視野を広げることになります。

記号系の換字としてはピッグペン暗号も有名です。
文字を格子や記号へ置き換える見た目の面白さがあり、謎解きやポップカルチャーとの相性が抜群です。
ただし、本質は「対応表がわかれば読める」換字です。
秘密の字体に見えても、構造そのものは古典的です。

換字式暗号が破られた理由をひとことで言うなら、平文の統計的な癖が暗号文の中に残るからです。
単純なシフトなら全探索、単一換字なら文字頻度分析、多表式ならカシスキーテストと頻度分析、ダイグラム系なら組の出現分析という具合に、暗号の構造に応じた攻め筋が見えてきます。
古典暗号は「秘密の規則」ではなく「観察されうる規則」だった、という点が面白いところです。

転置式暗号

転置式暗号は、文字そのものは変えず、並び順だけを入れ替える方式です。
英語では transposition cipher と呼ばれます。
換字式が「文字を別の顔にする暗号」だとすれば、転置式は「同じ駒を違う順番に並べ替える暗号」です。
見た目は別物でも、現代暗号でいう拡散の感覚を先取りしていると考えると、ぐっと見通しがよくなります。

古典例として外せないのがスキュタレーです。
細い帯を棒に巻き付け、その上に文章を書き、帯をほどいて持ち運ぶ方式として知られます。
正しい太さの棒に巻き直すと文字列が再び読める、という仕掛けです。
文字は置換されず、配置だけが崩れます。
古代の道具立てとして印象的ですが、鍵に相当するのは棒の太さや列配置という物理的条件で、構造が見抜かれると復元の方向性が絞られます。
これも安全性ステータスは historical です。

もう一つの代表例がレールフェンス暗号です。
文章をジグザグに複数段へ書き、段ごとに読み出して暗号文を作ります。
たとえば 3 段なら、上段・中段・下段を行き来する折れ線の軌跡で文字を並べ替えるイメージです。
手元で試すなら、日本語の短文をローマ字化すると扱いやすくなります。
筆者は「KONBANHA」や「HIMITSUNOHEYA」のような短い日本語風の文をローマ字にして、3段のレールフェンスで書き並べる方法をよく使います。
紙に山形の軌跡を描いて1文字ずつ置いていくと、暗号というよりパズルの盤面を埋める感覚に近く、復号では「どこに折り返し点があったか」を逆算する面白さがあります。

転置式暗号が破られる理由は、文字の種類そのものが残ってしまう点にあります。
換字式では文字の正体が隠れますが、転置式では頻出文字や単語候補の材料がそのまま残ります。
英語なら母音と子音の並び、日本語ローマ字なら母音の出現パターンが手がかりになります。
さらに、段数や列数を仮定しながら再配置を試すと、意味のある断片が現れます。
ここで効くのがニブル分析のような、断片やまとまりを拾い上げる見方です。
文字を一つずつ見るのではなく、2〜3文字、短い塊、語尾や語頭の癖に注目すると、ただのバラバラな列が急に文章の顔を見せ始めます。

転置式暗号は「文字が変わらないぶん易しい」と片づけるより、「統計は残るが順序が壊れる」と捉えたほうが実態に近いです。
だから解読も、頻度だけでなく配置の仮説を組み合わせる必要があります。
このあたりは、換字式よりも“並べ替えパズル”の感触が濃い分野です。

機械式暗号

機械式暗号は、換字や転置の操作を装置で連続的に行う仕組みです。
古典暗号の分類としては substitution と transposition の延長線上にありつつ、機械化によって複雑さを引き上げた段階と見ると整理できます。
代表例はエニグマです。

エニグマは回転するローターによって、1文字入力するたびに置換規則が変わります。
固定の対応表を使う単一換字式暗号よりずっと複雑で、見た目には現代的な強さを感じさせます。
実際、当時としては大規模で精巧な暗号機でした。
ただし、破られなかったわけではありません。
解読の糸口になったのは、運用上の癖、既知の定型句、機械の構造的な制約、そして候補を系統的に絞る解析です。
ここでも「謎の超技術だから破れた」のではなく、「構造と運用に観測可能な偏りがあったから崩れた」と捉えると、古典暗号から現代暗号への流れが見えてきます。
安全性ステータスはもちろん historical です。

機械式暗号が面白いのは、人力の換字を装置に預けたことで、暗号が一気に“システム”になった点です。
鍵設定、ローター順、初期位置、日替わり設定といった要素が絡み、暗号は単なる文字遊びから運用設計の問題へ変わります。
これは現代暗号にも通じる視点です。
アルゴリズムだけでなく、鍵管理や手順が全体の安全性を左右するという感覚は、すでにこの時代に顔を出しています。

教育・謎解き・CTFの文脈で古典暗号を扱うとき、換字式、転置式、機械式の3分類を並べてみると、暗号の進化が一枚の地図になります。
どれも現代の実運用には使いませんが、なぜ破られたかを具体的に追える点に価値があります。
頻度分析で崩れる、カシスキーテストで周期が露出する、断片分析で並び替えの筋が見える、機械式でも構造と運用の癖が攻め口になる。
古典暗号は、現代暗号を学ぶ前の「弱いおもちゃ」ではなく、破れる理由がはっきり見える教材です。

その見取り図を一度に眺められるよう、分類・代表例・典型的な解読法・安全性ステータスを表にまとめておきます。

古典暗号の一覧をこうして仕組み別に並べると、現代暗号の原型が見えてきます。
文字を置き換える、順番を崩す、規則を動的に変える。
この三つの発想は、形を変えながら今の暗号技術にも流れ込んでいます。

現代暗号一覧——共通鍵・公開鍵・ハッシュ・署名

共通鍵暗号

現代暗号の実務で、データ本体を守る主役になるのは共通鍵暗号です。
送る側と受け取る側が同じ鍵を共有し、その鍵で暗号化と復号を行います。
役割は明快で、大量のデータを高速に保護することです。
Web 通信の本体、ファイル暗号化、ディスク暗号化など、「中身をたくさん運ぶ」場面ではまずここが中心になります。

代表例はAESとChaCha20です。
AESは現在の標準的な共通鍵暗号として広く浸透しており、名前を見かける機会も多いはずです。
ChaCha20は同じく現代的な選択肢で、特にソフトウェア実装との相性がよく、TLS でも重要な位置を占めています。
両者は方式の作りに違いがあり、AESはブロック暗号、ChaCha20はストリーム暗号に分類されますが、利用者の視点では「どちらも通信や保存データを現実的な速度で守るための主力」と押さえれば十分です。

ここでの発想は、古典暗号のように文字を並べ替えて遊ぶ感覚から一段進みます。
守る対象が短い単語ではなく、画像、動画、Cookie、セッション、バックアップ全体になった瞬間、暗号は「一文を隠す技」ではなく「システム全体を支える基盤」に変わります。
共通鍵暗号が評価されるのも、その規模に耐える処理性能があるからです。

ただし、共通鍵暗号だけでは鍵をどう相手に渡すかという問題が残ります。
たとえばAESそのものは強力でも、最初の鍵配送が無防備なら話になりません。
ここで次の公開鍵技術が登場します。
現代の通信は、共通鍵暗号と公開鍵技術を役割分担させることで成り立っています。
ケルクホフスの原理に従えば、隠すべきは方式ではなく鍵です。
そして現実には、方式の選定だけでなく、鍵の生成、保管、更新、失効まで含めた運用で差がつきます。

公開鍵技術

公開鍵技術は、共通鍵暗号とは役割が違います。
こちらは大量データをそのまま運ぶための道具というより、鍵共有・暗号化・署名を実現するための仕組みです。
公開してよい鍵と、秘匿すべき鍵を分けることで、事前に秘密鍵を共有していない相手とも安全な通信の土台を作れます。

代表的な名前はRSA、ECC、そしてDiffie-Hellman系です。
RSAは公開鍵暗号の古典的な王道で、暗号化にも署名にも使われてきました。
ECCは楕円曲線暗号の総称で、同等水準の安全性をより小さな鍵長で狙えるのが特徴です。
Diffie-HellmanとECDHは、相手と共通の秘密を合意するための技術で、TLS の鍵共有ではこの系統が要になります。

役割の違いを図にすると、現代暗号の地図は次のように見ると頭に入りやすくなります。

TLS の文脈で見ると、構図はとても実務的です。
まず公開鍵技術で相手が本物かを確かめ、鍵共有でセッション鍵を合意し、その後の本体通信は共通鍵暗号で守ります。
つまり、玄関の本人確認と鍵の受け渡しは公開鍵系、部屋の中の会話は共通鍵系という分担です。
TLS 1.3ではこの流れが整理され、ハンドシェイクも簡素化されました。
ブラウザの錠前アイコンの裏側では、まさにこのハイブリッド暗号の構図が働いています。
TLS の流れを具体的に追いたいなら、CloudflareのTLSハンドシェイクの基本が図解として見やすい資料です。

実務ではRSAとECCの比較が避けて通れません。整理すると次の通りです。

筆者がこの違いを体感したのは、証明書まわりの扱いを見比べたときでした。
ECC P-256は鍵が小さいため、証明書の収まりが軽く、ハンドシェイクがより迅速に進む実感がありました。
数字としては「同等水準を短い鍵で達成する」と説明できますが、実際には同じ情報をより小さな封筒で運べる感覚に近いのです。
特に通信開始時のやり取りでは、その軽さは明確に効いてきます。
安全性の目安は、表にしておくと見通しがよくなります。
短く整理することで、異なる方式を並べて比較しやすくなります。

この対応は、異なる方式を同じ土俵で雑に比べるためではなく、「鍵長の数字はそのまま横比較できない」ことを示す目安です。
128、256、3072という数字だけを見ると印象がばらばらですが、背後の数学が違うので、必要な鍵長も変わります。

ハッシュ関数とHMAC

ハッシュ関数は、暗号化とは別の役割を持つ部品です。
入力データから固定長の値を作り、内容が変われば出力も変わるよう設計されています。
代表例はSHA-256とSHA-512です。
ファイルの整合性確認、パスワード関連の基礎処理、署名対象データの要約など、現代暗号のあちこちで使われています。

ここで混同しやすいのが、「ハッシュだけで送信者の正体まで証明できるのか」という点です。
答えはできません。
ハッシュは改ざん検知には役立ちますが、誰が作ったかまでは示せないからです。
たとえば文書のSHA-256値を並べれば、受け取った文書が途中で変わっていないかは確認できます。
それでも、その値を最初に作った相手が本物かどうかは別問題です。

この弱点を補うのがHMACです。
HMAC はハッシュ関数に秘密鍵を組み合わせた仕組みで、共有鍵を知っている相手だけが正しい認証値を作れます。
ハッシュ単体が「内容が同じか」を確かめる道具だとすれば、HMAC は「秘密を共有している相手が作った内容か」まで踏み込めます。
ただし、ここで使うのは共有鍵です。
したがって、真正性は示せても、後から「自分は送っていない」と言い逃れできない状態、つまり否認防止までは担いません。
その役割はデジタル署名に回ります。

ハッシュと署名の関係も、実務ではセットで理解したほうが混乱しません。
署名の対象をそのまま全部計算するのではなく、まずハッシュで要約し、その短い値に署名を施すのが基本形です。
RSA署名でもECDSAでも、この考え方が土台にあります。
ハッシュは署名の前処理であり、署名そのものではありません。

この区別は、古典暗号を知ったあとほど面白く見えてきます。
昔の暗号は「読めるか読めないか」が中心でしたが、現代暗号では「改ざんされていないか」「誰が作ったか」まで役割が分化しています。
ハッシュは読む・読めないの話ではなく、文書の指紋を作る技術です。

デジタル署名と証明書

デジタル署名は、現代暗号の中でも「その文書を誰が出したか」を扱う技術です。
秘密鍵で署名を作り、対応する公開鍵で検証します。
これによって、文書が改ざんされていないことと、署名者の秘密鍵を持つ主体が関わっていることを示せます。
代表例はRSA署名とECDSAです。

ここで証明書が加わると、公開鍵に「これはこのサイト、この組織、この主体の鍵です」という身元情報が結び付けられます。
TLS でブラウザがサーバ証明書を受け取り、公開鍵を検証する流れは、単なる暗号化というより身分証確認に近いものです。
公開鍵だけを渡されても、それが本当に目的の相手のものかは分かりません。
証明書は、その公開鍵に名前札を付ける役目です。

ハイブリッド暗号の構図も、ここで一枚にまとまります。
TLS では、証明書と署名で相手の正当性を確認し、公開鍵技術やECDHでセッション鍵を合意し、その鍵でAESやChaCha20を使って通信本体を暗号化します。
公開鍵だけで全部を守るのではなく、得意分野ごとに役割を分けているわけです。
公開鍵技術は重いが鍵共有に強く、共通鍵暗号は軽くて本体保護に向く。
この分業こそ現代暗号の実戦形です。

量子計算機の話題が出ると、ここにもう一段の変化が入ります。
現在はRSAやECCが主力ですが、移行先としてポスト量子暗号の標準化が進んでいます。
2024年8月13日には NISTが公開した初のPQC標準 が公表されました。
鍵共有や署名の新しい枠組みが正式な標準として動き始めました。
もっとも、今日の実用を理解する段階では、まずAESChaCha20RSAECCSHA-256HMACECDSAの役割分担をつかむほうが地図として役立ちます。

現代暗号は、強いアルゴリズムを一つ選べば終わる世界ではありません。
前の時代の機械式暗号でも見えた通り、方式の巧妙さだけでなく、鍵管理、証明書運用、実装の正しさで安全性の現実が決まります。
アルゴリズムを秘密にして守るのではなく、方式は公開し、鍵と運用で守る。
現代暗号の一覧を用途別に眺めると、その原則が技術全体を貫いていることが見えてきます。

NIST Releases First 3 Finalized Post-Quantum Encryption Standards

NIST is encouraging computer system administrators to begin transitioning to the new standards as soon as possible.

www.nist.gov

手を動かしてみる——シーザー暗号とTLS 1.3 を比べる

紙と鉛筆で「HELLO→KHOOR」

紙にHELLOと書いて、アルファベットを1文字ずつ3つ先へ送ってみます。
HはIJを越えてK、EはFGを越えてH、LはMNを越えてOです。
同じくもう1つのLもOになり、OはPQを越えてRになるので、HELLOはKHOORになります。
これがシーザー暗号のいちばん手触りのある瞬間です。
暗号という言葉が急にパズルへ変わる場面、と言ってもいいでしょう。

この方式の面白さは、計算機がなくても自分で暗号化も復号もできるところにあります。
けれど同時に、弱さもすぐ見えてきます。
英字のシフト候補は26通りしかないので、1つずつ戻して読める文になるか試していけば、いずれ当たります。
筆者も紙の余白に「+1」「+2」「+3」と並べて試していくと、秘密の仕掛けというより、番号付きダイヤルを順に回していく感覚に近いと感じます。
鍵が小さいとは、こういうことです。

同じ換字式でも、文字の対応をもっと複雑にした単一換字式暗号になると話は変わります。
文字の入れ替え方は膨大ですが、それでも古典暗号の世界では文字頻度や語の形が手がかりになります。
古典暗号は「規則を隠す遊び」としては魅力的でも、長い通信を現実に守るには心もとないわけです。
ここで現代暗号へ跳ぶ準備が整います。
ルールを少しひねるだけでは足りず、鍵共有、認証、改ざん検知まで含めて設計しなければならない、という景色が見えてきます。

TLS 1.3 の流れを直感で掴む

ここから一気にブラウザの世界へ移ります。
HELLOをKHOORに変える遊びが「文字をずらす」暗号だとすれば、TLS 1.3 は「まず安全な合言葉を作り、その合言葉で本編を守る」仕組みです。
本文データを公開鍵暗号そのもので包んで送っているわけではありません。
公開鍵系の仕事は、通信の最初に安全な共有秘密を作ることと、相手が本物か確かめることです。
ページ本体のHTMLや画像、APIレスポンスを守る本番担当は、そのあとに使われる共通鍵暗号です。
代表例としてはAES-GCMやChaCha20-Poly1305がここに入ります。

流れを図にすると、骨格はこのくらいシンプルです。

Client Server
 | -------- ClientHello ----------> |
 | 鍵共有候補（例: X25519）提示 |
 | <------- ServerHello ----------- |
 | 選択した方式と証明を返す |
 | |
 | **** 共有秘密から鍵を作る **** |
 | |
 | <** 以後は共通鍵で暗号化通信 **> |

ClientHelloは、クライアント側の「この方法で鍵を作れます」という最初の名刺交換です。
ここで鍵共有グループの候補、たとえばX25519のような方式を提示します。
サーバ側はServerHelloで採用する方式を返し、証明書や署名で「その公開鍵は確かにこの相手のものです」と示します。
この時点で双方は鍵共有の計算を行い、同じ共有秘密にたどり着きます。
ただし、その秘密そのものがネットワーク上を生で流れるわけではありません。
互いの材料から同じ答えを導くところが肝です。

そこから先は、共有秘密を材料にトラフィック鍵を派生し、通信本体を共通鍵暗号で守ります。
ここが現代暗号の分業の美しいところです。
公開鍵系は最初の握手を担当し、共通鍵暗号は大量のデータを軽快に運ぶ担当になる。
紙と鉛筆のシーザー暗号が「暗号化そのもの」を1つの操作として見せるのに対して、TLS 1.3 は「相手確認」「鍵共有」「通信保護」が役割ごとに分かれています。

筆者がこの流れを実感したのは、ブラウザの開発者ツールで接続情報を眺めたときでした。
ページの詳細を開くと、TLSのバージョンや暗号スイートが見えます。
そこにはTLS 1.3の表示があり、名前だけ知っていた規格が急に手触りを持ちます。
しかもページ遷移のとき、1往復減った軽さは数字以上に体感へ効きます。
とくに小さなリソースを次々読む場面では、「あ、返事待ちが1回少ない」という感じが画面の反応に出る。
暗号は重たい鎧ではなく、うまく作ると速さにも寄与する技術だと分かります。

TLS 1.2 との差分

TLS 1.2は2008年のRFC 5246、TLS 1.3は2018年のRFC 8446です。
この10年の差は、単なる版上げではありません。
読者の体感に近いところで言えば、まずハンドシェイクの往復が減りました。
通信開始までの手順が整理され、接続の立ち上がりが短くなっています。
先ほどの「ページ遷移で返事待ちが1回減った感触」は、この差が画面の向こう側から返ってきたものです。

もう1つの変化が0-RTTです。
以前の接続情報を持っている場面では、待ち時間をさらに削ってデータ送信を始められる仕組みが入っています。
初回接続ではなく再接続で効く話ですが、「前に会った相手なら、あいさつの一部を短縮できる」と考えるとイメージしやすいはずです。

定義済み暗号スイート数を5と数える説明が見られますが、RFC 8446 の定義や IANA の公式一覧、各実装（ライブラリやブラウザ）の扱いの差異により、数え方が変わることがあります。
正確な数を提示する必要がある場面では、RFC 8446 および IANA の TLS Cipher Suites registry を一次情報として参照する旨を明記してください（例: シーザー暗号と並べると、この飛躍は鮮やかです。
シーザー暗号では鍵はたった1つの数字で、本文そのものをずらします。
TLS 1.3 では、まず相手を確かめ、鍵共有を行い、その結果から通信専用の鍵を作り、共通鍵暗号で本編を保護します。
古典暗号が「文をどう変形するか」の技術だとすれば、TLS 1.3 は「安全な通信路をどう立ち上げるか」の技術です。
紙の上でHELLO→KHOORを作ったあとにブラウザの錠前を見ると、暗号の歴史が一直線ではなく、発想の段差をいくつも上ってきたことがよく分かります。

なぜ古典暗号では足りなくなったのか

頻度分析と多表式の誕生

一部の解説では TLS 1.3 の定義済み暗号スイート数を「5」と数える説明が見られますが、RFC 8446 の定義や IANA の登録、各実装（ライブラリやブラウザ）での扱いにより数え方が変わることがあります。
正確を期す場合は RFC 8446 および IANA の TLS Cipher Suites registry を一次情報として参照してください（例:

ここは紙と鉛筆で触ると腑に落ちます。
短い英文明文をひとつ用意して、文字ごとの出現回数を手で数えてみると、EやTが目につきます。
筆者も講座や原稿の準備でこの小演習をよく試しますが、表計算を使わなくても、正の字を並べるだけで「言語には癖がある」と目で分かります。
この癖こそが頻度分析の入口です。
暗号文でよく現れる記号を、平文でよく現れる文字へ当てはめていくと、単一換字は思った以上に崩れます。

その対抗策として生まれた発想が、多表式暗号です。
代表例のヴィジュネル暗号は、1枚の対応表で固定的に置き換えるのではなく、鍵語に応じて複数の換字表を切り替えます。
これで「平文のEはいつも同じ記号になる」という単純さが消え、単一換字よりずっと手ごわく見えます。
実際、長いあいだ「解読が難しい暗号」として扱われました。

ただし、ここでも歴史は止まりません。
鍵語の繰り返しには周期があり、周期が見えれば同じ位置どうしを集めて再び統計をかけられます。
カシスキーテストのような手法が登場すると、多表式暗号もまた「読める構造」を持っていたことが明らかになりました。
古典暗号の進化は、破られた方式の弱点を隠す工夫として進み、その工夫もまた解析される、という追いかけっこだったわけです。

面白いのは、単一換字の置換総数が多くても、それだけで安全とは言えない点です。
英字26文字なら置換は26!通りあります。
桁だけ見ると気が遠くなりますが、解読者は闇雲に全探索する必要がありません。
言語の偏り、単語の形、文字の連なりという“地形”を手がかりに近道できるからです。
古典暗号が足りなくなった理由は、鍵候補の数より先に、統計と構造の漏れにありました。

鍵配送問題とDiffie–Hellman

古典暗号のもうひとつの壁は、暗号文そのものではなく、鍵の渡し方にありました。
共通鍵暗号は同じ鍵で暗号化と復号を行うので、通信の前に「その鍵をどう共有するか」という問題が必ず立ち上がります。
暗号の中身がどれだけ巧妙でも、鍵を安全に渡せなければ入口で詰みます。
たとえば遠く離れた相手と初めて通信するとき、手紙で鍵を送れば盗み見されるかもしれないし、口頭で伝えるにも安全な経路が必要です。
暗号を使う前に、すでに安全な手段が要る。
このねじれが鍵配送問題の本質です。

古典暗号の時代は、信頼できる使者、事前の取り決め、物理的な受け渡しに頼るしかありませんでした。
少人数なら回りますが、相手が増えるほど管理は急に重くなります。
組織内だけでなく、不特定多数の相手と通信する現代のネットワークでは、この方式は持ちません。
暗号が数学の問題である前に、運用の問題でもあることがここで見えてきます。

転機になったのがDiffie–Hellmanです。
この方式が開いた道は、「秘密の鍵そのものを送らなくても、公開した材料から双方が同じ共有秘密に到達できる」という発想でした。
ネットワーク上を流れるのは計算の材料であって、完成した共通鍵ではありません。
盗み見している第三者が会話を全部見ていても、その場で同じ秘密へ到達できない。
この一歩で、鍵配送問題は“安全な運搬”から“安全な合意”へと姿を変えました。

ここで現代暗号の分業がきれいに見えてきます。
共通鍵暗号は大量のデータを守る担当として抜群に速く、公開鍵系や鍵共有は、最初の安全な合意を作る担当として働きます。
共通鍵の高速性と、公開鍵の鍵配送解決能力を組み合わせるのが自然な構成です。
前のセクションで見たTLS 1.3も、この役割分担の上に立っています。
ハンドシェイクではDiffie–Hellman系の鍵共有でセッション鍵の材料を作り、通信本体はAESやChaCha20のような共通鍵暗号で保護する。
公開鍵系だけで全部を運ぶのではなく、得意分野を分けることで、速さと安全性を両立しています。

この構図は、金庫そのものと鍵の受け渡し役を分ける感覚に近いです。
頑丈な金庫があっても、鍵を毎回むき出しで渡していては意味がありません。
だからこそ、まず鍵を安全に決める仕組みが必要になり、その上で高速な暗号化エンジンが本編を担う。
古典暗号が苦しんだのは、この「本編の暗号」と「鍵の流通」を一体で解けなかったからです。

ケルクホフスの原理

古典暗号から現代暗号への思想の切り替えを一文で言うなら、秘密にすべきなのは仕組みではなく鍵である、ということです。
これがケルクホフスの原理です。
暗号方式そのものが公開されても、安全性が損なわれないように設計する。
逆にいえば、「解き方を知られていないから安全」という方式は、いずれ破綻します。
歴史が何度もそれを示してきました。

古典暗号では、方式を隠すこと自体が防御の一部になりがちでした。
けれども、仕組みは使われるほど観察され、複製され、解析されます。
軍や外交の現場であれ、装置や手順が広がれば秘密は漏れます。
そこへ頻度分析や統計解析が乗ってくると、「知られたら終わる暗号」は長持ちしません。
ケルクホフスの原理は、そうした歴史の反省から生まれた設計思想です。

現代暗号でAESやRSA、ECC、Diffie–Hellmanのような名前が広く知られているのは、この原理に沿っているからです。
アルゴリズムは公開され、研究者が検討し、実装者が利用し、それでも鍵が漏れない限り安全が保たれるように組み立てる。
この考え方に立つと、暗号は「秘伝のトリック」ではなく、「公開の設計図を持つ社会基盤」になります。

そして、この原理は現代プロトコルの構成にもそのまま現れています。
TLSは方式を隠しているのではなく、公開された手順で鍵共有・認証・暗号化を組み合わせています。
TLS 1.2はRFC 5246、TLS 1.3はRFC 8446として仕様が公開され、通信の安全性はアルゴリズムの秘匿ではなく、鍵管理と構成の妥当性に支えられています。
だからブラウザの錠前マークの裏側では、公開鍵系が最初の鍵共有と認証を受け持ち、そのあとを共通鍵暗号が高速に走る、というハイブリッド構成が定着しました。
これは便宜的な寄せ集めではなく、古典暗号がぶつかった限界を一つずつ越えた結果の形です。

この先、量子計算機への備えとして新しい鍵共有や署名方式が増えても、設計の芯は変わりません。
方式は公開し、検証可能にし、秘密は鍵に集中させる。
その上で、鍵配送を解く技術と高速な通信保護を分担させる。
古典暗号では足りなくなった理由をたどると、現代暗号がなぜ今の姿になったのかが、発明の美談ではなく歴史の必然として見えてきます。

量子時代の新しい分類——耐量子計算機暗号

標準化の現在地

量子計算機の話題は、少し前までSFの小道具のように見えていました。
けれど暗号の世界では、もう「未来の話」ではありません。
公開鍵暗号の土台だったRSAやECCが、量子計算機の進展によって長期的な前提を揺さぶられるからです。
そこで登場した新しい分類が、耐量子計算機暗号、いわゆるポスト量子暗号です。

節目になったのは、2024年8月13日に最初のPQC標準が公開されたことでした。
ここで正式な名前と番号がそろいました。
FIPS 203 はML-KEM、FIPS 204 はML-DSA、FIPS 205 はSLH-DSAです。
旧称でいえば、ML-KEMはKyber系、ML-DSAはDilithium系、SLH-DSAはSPHINCS+系に対応します。
鍵共有や鍵の封筒化に使うKEMと、真正性確認に使う署名方式が、量子時代向けに制度上も並び始めたわけです。
NISTが公開した初のPQC標準

ここで見ておきたいのは、「耐量子」といっても一枚岩ではないことです。
方式の背後にある数学が違います。
ML-KEMとML-DSAは格子ベース、SLH-DSAはハッシュベースです。
さらに、2025年3月11日にはHQCが標準化候補として選定され、コードベースの系統も前面に出てきました。
格子だけに寄らず、異なる設計思想を持つ方式を残しておくという意味でも、この動きは象徴的です。
NIST PQC 標準化プロセス

署名の分野では Falcon 系などサイズ効率が注目される方式があります。
ただし研究名（例: Falcon）と標準名・登録名は一致しないことが多く、表記揺れや名称変更が起きうる点に注意してください。
標準化の進捗や正式名称・番号は NIST CSRC の公式ページで随時確認することを明記してください。
主要な方式を、用途と系統でざっと並べると次のようになります。

この表で面白いのは、「どれが最強か」を競う並びではないことです。
たとえばSLH-DSAは署名サイズでは不利になりやすい一方、ハッシュベースという別系統の安心感があります。
ML-DSAは実用バランスがよく、FALCONはサイズ効率の魅力が語られやすい。
HQCは格子以外のKEMとして位置づけがはっきりしています。
暗号の分類は、性能ランキング表ではなく、脅威と運用条件に応じた道具箱だと見ると腹落ちします。

なぜ今すぐ準備するのか

「量子計算機が実用化してから切り替えればいいのでは」と感じる人は多いはずです。
筆者も最初はそう考えました。
けれど、この問題には時間差があります。
よく挙がる脅威モデルが harvest now, decrypt later です。
いまは解読できない通信でも、あとで量子計算機が育った時点でまとめて復号されるかもしれない。
今日の秘密が、今日のまま危険にさらされるのではなく、未来で破られるのです。
なお、FALCON系は研究名や実装名として注目されていますが、NIST の最初の3件（FIPS 203/204/205）には含まれておらず、標準化状況や表記は変動し得ます。
正式名称や標準番号の確認は NIST CSRC の公式ページを一次情報として参照してください。
この感覚は、想像実験にすると急に身近になります。
たとえば「将来の自分だけが読む手紙」を今日の公開鍵で封じたとします。
中身は、研究メモでも、契約交渉の記録でも、まだ公開したくない個人的な文章でもいい。
送った瞬間は安全に見えても、10年後、15年後に鍵の前提が崩れたら、その“未来の自分宛の秘密”は、未来の第三者にも開けられる封筒になってしまいます。
ここで守りたいのは、いまの通信だけではなく、保存期間をまたいで価値を持つ情報の寿命です。

特に公開鍵暗号は、長く保管されるデータとの相性が問題になります。
セッションごとに消えていく一時的な通信だけなら影響を切り分けやすいのですが、機微なメール、知財、医療、法務、行政、設計図、ソースコード署名の履歴は、時間がたってから漏れても被害が成立します。
だからPQCは「量子が来たら始める対策」ではなく、「将来まで秘密であってほしい情報を、今日どう包むか」の話になります。

実運用でも、従来方式とポスト量子技術を組み合わせるハイブリッド構成に関する試験的な公表がベンダー側から散見されます。
これらは個別の試験や報告に基づく事例であり、一般化する際は各社の公表資料を確認してください。
移行動向の一次情報としては NIST の PQC 標準化ページが役立ちます。

ハイブリッド移行の考え方

現実のインフラは、ある日を境にRSAやECCを全部捨ててML-KEMやML-DSAへ飛び移るわけではありません。
ここで中心になるのがハイブリッド移行です。
発想は意外と素直で、従来方式とPQC方式を並走させ、片方だけに全責任を負わせないというものです。

たとえば鍵共有なら、古典的なX25519とPQCのML-KEM系を組み合わせる構成が考えられます。
どちらか一方に問題が出ても、直ちに全体が崩れない形に寄せるわけです。
これは、古い橋を使いながら隣に新しい橋を架ける感覚に近いです。
いきなり全面通行止めにはしないが、荷重を少しずつ新しい側に移していく。
暗号移行も同じで、互換性、性能、ライブラリ対応、証明書のサイズ、監査手順を抱えたまま進むので、この二重化はむしろ自然な姿です。

実運用でも、従来方式とポスト量子技術を組み合わせるハイブリッド構成に関する試験的な公表がベンダー側から散見されます。
こうした事例は個別の試験・報告に基づくもので、一般化する際は各社の公表資料や NIST の一次情報を確認することを明記してください（例:

署名でも同じ構図があります。
証明書やコード署名でML-DSAを使うのか、SLH-DSAのような別系統をバックアップ選択肢として見るのか、FALCON系の成熟をどう評価するのかで設計は変わります。
ここで単純な勝ち負けに落とし込むと見誤ります。
署名サイズ、検証負荷、証明書チェーンへの影響、実装の成熟度は用途ごとに重みが違うからです。
Webの接続、ファームウェア更新、長期保管文書の署名では、同じ「署名」でも現場の事情がまるで違います。

この分野では名称変更や標準化段階の更新が続くので、実装名だけで判断しない姿勢も欠かせません。
KyberがML-KEMへ、DilithiumがML-DSAへ整理されたように、研究名と標準名は一致しないことがあります。
FALCON系もその典型です。
だから実運用の議論では、アルゴリズム名、標準名、ライブラリ名が同じとは限らない前提で読む必要があります。
動向の確認先としては、英語圏ではNIST、日本語ではCRYPTRECの整理が軸になります。

量子時代の暗号分類は、単に新しい名前を覚える作業ではありません。
古典暗号から現代暗号へ進んだときに「鍵をどう共有するか」が主戦場になったように、これからは「将来破られる前提で、今日どこから置き換えるか」が設計の中心になります。
ML-KEMML-DSASLH-DSAHQC、そして進行中のFALCONは、その地図を読むための座標です。
読者がこのあたりで迷わなくなると、PQCは遠い研究テーマではなく、ブラウザの錠前やソフト更新の裏側にある、いま進行中のインフラ更新として見えてきます。

一覧表で見るどの暗号をいつ学ぶべきか

この一覧表は暗号を暗記カードのように眺めるためのものではありません。
自分の関心に合う次の一歩を選ぶための地図として使うことを意図しています。
この一覧表は、暗号を暗記カードとして眺めるためではなく、自分の関心に合う次の一歩を選ぶための地図です。
映画に出てくる暗号の元ネタを知りたいのか、CTFで見かける問題を解きたいのか、業務でTLS 1.3や証明書の役割を腹落ちさせたいのかで、読む順番は変わります。
筆者自身も、最初から一直線の学習順で進んだわけではなく、気になる入口から入り、あとで全体地図に戻るほうが理解がつながりました。

興味のある題材から入っても迷子にならないよう、まずは全体像を表にして、そのうえで分岐を選ぶのが近道です。

初心者の学習順ロードマップ

初心者が追いやすい順番は、古典暗号で直感をつかみ、現代暗号で役割分担を覚え、TLSで実装感覚を持ち、PQCで将来の移行を見るという流れです。
シーザー暗号のように紙とペンで動かせるものから始めると、「鍵が違うと読めない」という感覚を身体で理解できます。
そこからAESChaCha20SHA-256へ進むと、暗号化とハッシュは同じ“守る技術”でも担当が違うと見えてきます。
初心者が追いやすい順番は次のように整理できます。
まず古典暗号で直感をつかみ、そのあと現代暗号で役割分担を覚え、TLSで実装感覚を持ち、最後にPQCで将来の移行を俯瞰する、という流れです。
次にRSAECCDiffie-HellmanECDHを押さえると、公開鍵暗号は“重いけれど便利な封筒”、共通鍵暗号は“速い本体輸送”という分担がつながります。
ここでECC P-256とRSA 3072bitが同程度の安全性目安に置かれ、128ビット安全性の目安としてAES-128ECC 256bitRSA 3072bitが並ぶと知っておくと、実務で「なぜECCが選ばれやすいのか」を鍵サイズと処理負荷の両面から読めます。

その先はTLS 1.3です。
RFC 5246のTLS 1.2からRFC 8446のTLS 1.3へ進んだ流れを見ると、教科書の暗号がブラウザの錠前アイコンにどう入っているかが見えてきます。
公開鍵系で共有秘密を作り、その後は共通鍵で通信本体を守る、という役割分担がここで立体的になります。
移行の現在地を知る段階としては、NISTが公開した初のPQC標準まで進めば十分です。
ML-KEMML-DSASLH-DSAという名前が、未来の話ではなく設計変更の候補として読めるようになります。

学び始めの順番を一本に固定する必要はありませんが、迷ったら次の並びが外れません。

• 古典暗号：シーザー暗号→ヴィジュネル暗号→ 換字式と転置式の違い
• 現代暗号の基礎体力：AES→ChaCha20→SHA-256→HMAC
• 役割分担の理解：RSA→ECC→Diffie-Hellman→ デジタル署名
• 実装感覚：TLS 1.3ハンドシェイク
• 将来の移行設計：ML-KEMML-DSASLH-DSAHQC

用途別の分岐

ここからは、何のために学ぶかで分けたほうが速く進めます。
歴史を知りたい人と、業務で設定画面を読む人と、謎解きイベントで暗号に触れる人では、同じ一覧表でも拾うべき列が違うからです。

歴史理解に寄せるなら、古典暗号を中心にたどるのが自然です。
スキュタレーで転置の発想を見て、シーザー暗号で単純換字を触り、ヴィジュネル暗号で“少し賢い換字”へ進み、エニグマで機械式の時代に入る。
この順で並べると、手作業の暗号がどこで限界を迎え、現代暗号の発想へ橋がかかったのかが見えてきます。

• 歴史理解向け：スキュタレー→シーザー暗号→ヴィジュネル暗号→エニグマ→ 現代暗号への転換点

実務理解を優先するなら、古典暗号は導入だけで十分です。
AESとSHA-256で通信本体と完全性確認の土台を押さえ、ECCRSAECDHで鍵共有と署名の役割を整理し、TLS 1.3で全体を束ねて見る。
そのうえでPQCへ進むと、移行の論点が「新しい名前を覚えること」ではなく、「どの部品をどの順番で差し替えるか」に変わります。
ECC P-256がRSA 3072bit級の目安を持つことは、証明書サイズや性能を考えるときの現場の感覚に直結します。

• 実務理解向け：AES→SHA-256→ECC / RSA→ECDH→TLS 1.3→ ML-KEMなどのPQC

謎解きやCTF寄りなら、古典暗号と“見た目で特徴が出る問題”から入ると手応えがあります。
シーザー暗号は英字なら鍵候補が26通りなので、総当たりの感覚をつかむ最初の題材としてちょうどいいです。
単一換字式暗号では英字26文字の置換が26!通りに広がる一方、実際の解読は文字頻度や語形で進む、という差も体験できます。
ここからヴィジュネル暗号ピッグペン暗号レールフェンスへ進むと、パズルとしての表情が豊かになります。

• 謎解き向け：シーザー暗号→ピッグペン暗号→レールフェンス→ヴィジュネル暗号→ 単一換字式暗号の頻度分析

完全な初心者で、とにかく一歩目がほしい人は、次の4つだけで十分です。
まず一覧表を眺めて地図をつかみ、次にシーザー暗号を手で解き。
続いてTLS 1.3のハンドシェイク図を見て、興味が未来側に向いたら NIST PQC 標準化プロセス の一次資料に入る。
この順だと、遊び、実務、将来動向が一本の線でつながります。

安全性ステータスの凡例

一覧表を見るときは、アルゴリズム名だけでなく、いま使うべき技術なのか、学ぶために見る技術なのかを分ける必要があります。そこで役立つのが安全性ステータスです。

ここでの historical は「いまの防御用途には使わないが、理解の入口として価値が高い」という意味です。
secure は現在の標準的な利用に乗る位置づけ、deprecated は残っていても新規採用の中心には置きにくい状態、broken は教材としては面白くても保護手段としては成立しない状態です。
PQCはまだ単純に historical や secure の二択に落とし込めず、移行中の secure 候補として読むのが実態に合います。

一覧表の読み方に慣れると、暗号は「難しい名前の集合」ではなくなります。
古典は直感を作る層、現代は社会基盤を動かす層、PQCはその基盤を次世代へ引っ越す層です。
まず表で全体像を見て、自分の関心に近い一列を選ぶ。
そこから紙でシーザー暗号を動かし、TLS 1.3のハンドシェイク図を追い、一次資料でML-KEMやML-DSAの標準名に触れると、暗号の学習は断片的な用語集ではなく、一本の地図として頭に残ります。