暗号アルゴリズム比較｜AES・RSA・ECC・TLS・PQCの全体図

暗号は1つの方式で全部を片づける世界ではなく、共通鍵暗号・公開鍵暗号・ハッシュ関数が役割を分担して、はじめて安全な通信や保存を成立させます。
HTTPSのサイトを開いた瞬間も、数百ミリ秒のあいだに鍵交換、証明書検証、共通鍵の合意、そしてAESやChaCha20-Poly1305のようなAEADの確立までが一気に進み、本文の暗号化そのものはAESやChaCha20が担い、RSAやECCは主に鍵合意や署名に回っています。
この記事は、AESRSAECCChaCha20-Poly1305SHA-2SHA-3を、用途・安全性・速度・いま選ぶべき度合いまで含めて見比べたい人に向けたものです。
スマホのストレージ暗号化やZIPパスワード付きファイルに触れたとき、「実際に何が守られ、どの方式が働いているのか」を自分の言葉で説明できるところまで、全体地図を整理します。

暗号アルゴリズムとは何か——まず全体地図をつかむ

暗号アルゴリズムとは、データを読めない形に変えたり、正しい相手とだけ鍵を共有したり、途中で書き換えられていないかを確かめたりするための計算手順です。
全体像は 共通鍵暗号・公開鍵暗号・ハッシュ関数 の3分類でつかむのが最短で、実務ではこの3つを単独ではなく組み合わせて使います。
1種類で全部をまかなえないのは、秘匿、鍵共有、改ざん検知という目的そのものが別だからです。

たとえば、筆者が外出先でWi‑Fiにつないだ瞬間にまず気になるのは、「この通信は途中で盗み見られないか」という点です。
この不安に正面から効くのが、データ本体を高速に守る共通鍵暗号です。
ただし、共通鍵暗号だけでは「その鍵を最初にどう安全に渡すか」が残ります。
そこで公開鍵暗号が入り、さらに「内容がこっそり書き換えられていないか」はハッシュ関数やMACが受け持つ、という分担になります。

3分類の違い

共通鍵暗号は、送る側と受け取る側が同じ鍵を共有してデータを暗号化・復号する方式です。
代表例はAESで、128ビットのブロックを扱い、鍵長は128・192・256ビットです。
AESはDESの後継として公募から選ばれたRijndaelをもとに2001年に標準化され、内部ではSubBytesShiftRowsMixColumnsAddRoundKeyという操作を重ねてデータをかくはんします。
Wi‑Fi通信やストレージ暗号化のように大量のデータを連続して処理する場面で主役になるのは、この「高速なかくはん役」がいるからです。

公開鍵暗号は、公開鍵と秘密鍵の2つを使う方式です。
公開してよい鍵と、持ち主だけが隠して持つ鍵を分けることで、共通鍵暗号が抱える鍵配送問題を解決します。
代表例のRSAは1977年に公開され、大きな合成数の素因数分解が難しいことを安全性の土台にしています。
もうひとつの代表がECCで、こちらは楕円曲線離散対数問題の困難性を使い、256ビットでRSA 3072ビット級に相当する安全性を狙えます。
ここが暗号の美しいところなのですが、公開鍵暗号は「鍵を安全に渡す」「署名で本人性を示す」役には向いていても、長い本文をひたすら暗号化する役には向きません。

ハッシュ関数は、入力データから固定長の要約値を作る仕組みです。
代表例はSHA-2やSHA-3で、通常は鍵を持たず、元の文章へ戻すための復号手順もありません。
役割は暗号化そのものではなく、改ざん検知や署名の補助です。
同じ入力なら同じ出力になり、入力が少しでも変わると出力も大きく変わる性質を使って、「内容が変わっていないか」を確かめます。
認証付きの仕組みでは、ハッシュ関数を土台にしたHMACや、暗号化と認証を一体化したAEADも使われます。

実生活のどこで動いているか

いちばん身近なのはHTTPSです。
ブラウザでサイトを開くと、最初に公開鍵暗号の考え方で鍵交換や署名検証が行われ、その後の通信本体は共通鍵暗号ベースのAES-GCMやChaCha20-Poly1305で守られます。
TLS 1.3では暗号スイートの整理が進み、構成はAEADとハッシュの組に絞られ、鍵交換や署名方式は分離されました。
役割が分かれたことで、通信のどこで何が働いているかを追いやすくなっています。

この流れは、公開鍵暗号で共通鍵を安全に共有し、その共通鍵でデータ本体を暗号化し、整合性確認はハッシュやMACで受け持つ、というハイブリッド構成です。
速度の面でも理にかなっています。
公開鍵暗号は鍵を届ける短距離走者、共通鍵暗号は大量データを運ぶ長距離走者、ハッシュ関数は荷物が途中で入れ替わっていないかを見る検品係、と考えると腑に落ちます。

筆者はブラウザの錠前アイコンをクリックして証明書の詳細を眺める癖があるのですが、あの画面を見ると公開鍵基盤の役割がよく見えます。
そこに出てくる証明書は、「この公開鍵は本当にこの相手のものだ」と結び付けるための仕組みです。
公開鍵暗号だけを裸で置いても、相手の鍵が本物か偽物か判定できなければ中間者に差し替えられます。
証明書と署名の連鎖があるからこそ、ブラウザは正しい相手と鍵交換できます。

ここで「AESが安全なら全部安全」という短絡は避ける必要があります。
鍵の受け渡し、認証、整合性確認がそろって初めて全体として十分に安全と言えるのです。
アルゴリズム名だけを見るのではなく、運用や鍵管理、認証の設計まで含めて初めて実用上の安全性が担保されます。

量子計算の話題も、この地図に置くと整理できます。
共通鍵暗号はGroverの影響で実効鍵長を半分で見る発想が必要になり、公開鍵暗号のRSAやECCはShorの影響を強く受けます。
そのため、公開鍵の領域では移行準備が進んでおり、2024年には最初の3つのPQC標準が正式化され、2035年を目安に量子脆弱な既存方式を段階的に外す流れが見えています。
今の実務でRSAやECCが使われていることと、将来の移行が必要なことは、時間軸の違いとして並立します。

まずの結論：役割の要約

読者が30秒で復唱するなら、こう整理すると崩れません。
共通鍵暗号はデータ本体を速く隠す方式、公開鍵暗号は鍵共有と署名の方式、ハッシュ関数は改ざん検知と要約の方式です。
3つは競合ではなく分業で、通信でも保存でもこの並びが基本形になります。

この地図を持っておくと、AESRSAECCSHA-2SHA-3の個別論に入ったとき、どの方式に何を期待すべきかがぶれません。
暗号アルゴリズムを覚えるとは名前を丸暗記することではなく、誰が本文を守り、誰が鍵を渡し、誰が改ざんを見抜くのかを切り分けて語れる状態を指します。

なぜ複数の方式が必要になったのか——鍵配送問題から公開鍵暗号へ

共通鍵暗号は、同じ鍵で暗号化と復号を行うぶん処理が速く、大きなデータを守る役として今も中心にあります。
ただ、その強さは「相手と先に同じ鍵を持てていること」を前提にしており、この前提が現実の通信では最大の難所でした。
そこから「鍵そのものは公開してよい情報と秘密にすべき情報に分けられないか」という発想が生まれ、古典暗号とは別の地平として現代暗号が立ち上がります。

鍵配送問題とは何か

共通鍵暗号の魅力は明快です。
送信者と受信者が同じ鍵を共有していれば、暗号化も復号も効率よく行えます。
大量の本文を守る場面では、公開鍵暗号に比べて計算コストが低く、同じハードウェアでより高いスループットを得られるため有利で、現在の実務でもデータ本体の保護はAESのような共通鍵暗号が主役です。
AESは128ビットのブロックを扱い、鍵長は128・192・256ビットを取り、大容量データを現実的な速度で処理できます。

ところが、歴史的にも運用上でも、共通鍵暗号にはひとつ厄介な問いがつきまといます。
その共通鍵を最初にどう届けるのかという問題です。
暗号文が安全でも、鍵を渡す瞬間に盗まれれば意味がありません。
映画や小説では、封筒を持った伝令や、口頭で合言葉を伝える使者が緊張感を生みますが、あの危うさは現代のネットワークでも本質的には同じです。
伝令が捕まれば作戦が漏れるように、鍵配送の経路が破られれば通信全体が崩れます。

筆者が現場目線でこの問題をいちばん実感するのは、会社間で機密ファイルをやり取りする場面を想像したときです。
ファイル本体は暗号化してメールで送るとして、共通鍵はどう渡すのか。
別メールで送れば同じ経路ですし、電話で伝えるのも録音や聞き取りのリスクが残ります。
ではUSBに鍵を入れて物理配送するのかという話になるのですが、それはそれで配送の遅れ、紛失、受け渡し確認、保管の手間が増えます。
相手先が10社、100社と増えると、鍵そのものより鍵管理の運用が先に破綻します。
ここに、共通鍵暗号の「速い」という長所と、「事前共有が必要」という弱点がはっきり現れます。

古典暗号の時代にも、秘密の文字表や決まり事を事前に共有する必要がありました。
換字式でも転置式でも、規則を相手と共有できなければ解読できません。
つまり鍵配送問題は、現代ネットワークになって突然生まれた課題ではなく、暗号が運用に乗った瞬間から続いている宿題です。
違うのは、通信相手の数と速度が増え、手渡しや密使ではもう支えきれなくなった点です。

公開鍵暗号の発想の転換

ここで起きた転換は、直感に反するかもしれませんが、「秘密の鍵を安全に配る方法」を探すのではなく、「そもそも配らなくてよい設計」を考えることでした。
1976年に公開鍵暗号の概念が示され、同じ年にDiffie–Hellmanが鍵共有の考え方を世に出します。
送る相手にあらかじめ秘密の共通鍵を届けておかなくても、公開してよい情報を使って安全に共有鍵を作れる、という発想です。
ここで暗号は、単なる文字の隠し方から、数学的な性質を利用したプロトコル設計へと踏み込みました。

さらに1977年にはRSAが公開され、公開鍵暗号の具体像が広く認識されるようになります。
RSAは公開鍵と秘密鍵を分け、公開鍵は知られても構わず、秘密鍵だけを保持者が守る構造をとります。
安全性の根拠は、大きな合成数を素因数分解することの困難さにあります。
ここが暗号の美しいところなのですが、相手に渡す情報そのものを秘密にしなくてよい設計に変えたことで、何百何千という相手との通信でも、鍵配送の問題をまったく別の形に組み替えられたのです。

年表で見ると流れはつかみやすくなります。

1. 1976年に公開鍵暗号の概念が示され、Diffie–Hellmanが鍵共有の新しい考え方を提示しました。
2. 1977年にRSAが公開され、公開鍵と秘密鍵を分ける方式が実装可能な暗号として定着していきました。
3. その後の実務では、公開鍵暗号で共通鍵を安全に共有し、本文は共通鍵暗号で処理するハイブリッド構成が標準形になります。

この構成が定着した理由は、役割分担が理にかなっているからです。
公開鍵暗号は長い本文を延々と暗号化する用途には向きません。
一方で、鍵が共有できた瞬間から、共通鍵暗号は公開鍵暗号に比べて暗号化・復号の処理が高速で効率的になります。
そこで、公開鍵暗号に「最初の鍵を渡す役」を担せ、データ本体はAESのような高速な方式に引き渡す形が最も自然になります。
いまHTTPSの裏側で起きていることも、基本原理だけ見ればこの延長線上にあります。

古典暗号から現代暗号へ

古典暗号と現代暗号のあいだには、明確な断絶があります。
換字式や転置式の中心課題は、文字の並びや置換規則をどう隠すかでした。
そこでは言語の癖、特に文字の出現頻度が弱点になり、頻度分析が強力な攻撃手段になります。
つまり古典暗号は、自然言語の統計的な偏りとの戦いでした。

現代暗号では土台が変わります。
安全性は「文字頻度から読まれにくい」ではなく、「ある数学的問題を現実的な計算量で解くのが難しい」という計算量的仮定に乗ります。
RSAなら素因数分解の困難さ、ECCなら楕円曲線離散対数問題の困難さがその代表です。
ここで暗号は、言葉の癖を隠す技法から、計算資源をどれだけ投入しても突破が現実的でない設計へと移りました。
断絶といえるのはこの部分です。

一方で、連続している部分もあります。
古典暗号も現代暗号も、「相手だけが読めるようにする」「第三者に規則を悟らせない」という目的は同じです。
さらに、鍵や規則を相手と共有しなければ始まらないという悩みも連続しています。
公開鍵暗号はその悩みに新しい答えを与えましたが、問い自体は古典の時代から変わっていません。
映画の中で伝令が命がけで暗号表を運ぶ構図は、そのまま現代の鍵配送問題の比喩になります。

現代暗号への移行は、古いものを全部捨てたというより、古典暗号が抱えていた課題を数学の言葉で再定式化した流れだと見ると理解しやすくなります。
共通鍵暗号の高速性は今も必要で、公開鍵暗号は鍵配送の難所を越えるために導入され、両者を組み合わせることで実用が成立しました。
つまり複数方式が必要になったのは、技術が複雑になりたかったからではなく、速さ・鍵共有・安全性の根拠をひとつの方式だけでは同時に満たせなかったからです。

代表的な暗号アルゴリズム一覧——AES・RSA・ECC・ChaCha20・SHA系を比較

主要な暗号アルゴリズムは、名前だけ並べると複雑に見えますが、データ本体を速く守る方式、鍵共有や署名を担う方式、改ざん検知のための要約を作る方式に分けると整理できます。
筆者が実務で説明するときも、「大容量ファイルを暗号化するときに本当に全文を処理しているのは何か」という視点を置くと、共通鍵・公開鍵・ハッシュの出番の違いが一気に見えてきます。

共通鍵

共通鍵暗号は、送信者と受信者が同じ鍵を1つ共有して使う方式です。
長い本文や大容量データの処理に向いており、実際の通信や保存データの暗号化では主役になります。
前述の通り、公開鍵暗号は鍵配送問題を解くために導入されましたが、暗号化するデータ本体まで公開鍵で抱え込むわけではありません。
たとえば数GBのバックアップや動画ファイルを暗号化するとき、現場で動いている中核はAESやChaCha20-Poly1305であり、公開鍵はその共通鍵を安全に渡す入口を担います。
AESは128ビットのブロック暗号で、鍵長は128/192/256ビットです。
鍵長に応じてラウンド数は10/12/14となり、現在の実務ではデータ本体の暗号化の標準的存在です。
ここが暗号の美しいところなのですが、公開鍵暗号のような派手さはなくても、実際に大量のデータを支えているのはこの種の高速な共通鍵です。
ChaCha20-Poly1305はブロック暗号ではなくストリーム暗号系のChaCha20と認証のPoly1305を組み合わせたAEADで、暗号化と改ざん検知を一体で扱える点が実務上の強みになります。

量子計算との関係も見ておきたい点です。
共通鍵系はShorで直ちに崩れる性質ではなく、Groverの影響で実効鍵長が半減する向きに考えます。
そのため量子時代を意識する文脈では、AES-256を選ぶ意味が明確になります。

公開鍵

公開鍵暗号は、公開してよい鍵と秘密にすべき鍵の2つを分ける方式です。
主な役割は長文の暗号化ではなく、鍵共有と電子署名です。
実務で「大容量ファイルを暗号化するとき、公開鍵は何をしているのか」と問われたら、答えは「ファイル全体ではなく、そのファイルを守るための共通鍵を安全に受け渡している」です。
ここを取り違えると、公開鍵暗号を万能の暗号化エンジンのように見てしまいますが、実際の設計は役割分担で成り立っています。

RSAの安全性は素因数分解の困難さに立脚しており、実務では2048ビット以上が基準線です。
鍵共有、署名、短いデータの暗号化に使われてきた古典的な代表格で、PKIや証明書の文脈でも長く存在感を保ってきました。
一方のECCは楕円曲線離散対数問題の困難性を安全性の土台にしており、同等の安全性をより短い鍵で実現できるため、通信量や計算資源に制約のある端末で有利になることが多いです（ただし、速度や消費電力は処理の種類や実装に依存します）。

筆者がこの差を強く実感したのは、IoTデバイスの証明書更新まわりを見ていたときです。
台数が多い環境では、1台ごとの証明書処理が少し軽くなるだけでも全体の待ち時間に効きます。
ECCはこの種の場面で、鍵や署名データが比較的コンパクトにまとまり、限られた計算資源でも回しやすいため、机上の効率差ではなく運用時間の差として現れます。

量子時代の見通しでは、RSAとECCはどちらもShorの影響を強く受けます。
したがって、現在は安全でも長期的には移行対象であり、歴史的に重要な方式であることと、将来永続的に使えることは別問題です。
すでにポスト量子暗号の標準化も進み、初回の正式標準は3本に到達しています。
2035年を見据えた移行の流れの中で、RSAとECCは「今の実務ではsecure、量子耐性の観点では将来置き換え対象」という位置づけで読むのが正確です。

ハッシュ

ハッシュ関数は、平文を固定長の要約値に変換する仕組みで、暗号化そのものとは役割が異なります。
秘密を隠すというより、改ざんの有無を確かめたり、署名対象を短く整えたりするために使います。
長文処理に強いというより、長いデータから検証向けの指紋を作る道具と考えると位置づけがつかみやすくなります。

代表格はSHA-2とSHA-3です。
どちらも現行の実務で使えるハッシュ系として扱われ、電子署名の前処理や改ざん検知の補助に登場します。
ここで注意したいのは、ハッシュは通常は鍵を持たないため、共通鍵暗号や公開鍵暗号の代役にはなりません。
署名と組み合わさって初めて本人性の確認に関与し、AEADやMACと組み合わさって初めて完全性保護の一部になります。

使い分け早見表

方式ごとの差は、「鍵の数」「何を守るか」「長文に向くか」で見ると一目で整理できます。
TLS 1.3では暗号スイートの構成が整理され、このため暗号スイートは5つに絞られ、古い構成で見られた複雑な組み合わせから、AEADとハッシュを軸にした理解へ寄っています。

個別アルゴリズムまで並べると、選び分けは次の表が把握しやすくなります。

なお、推奨度の読み方は文脈付きで捉える必要があります。
今回並べた方式は現行の主要方式としてはすべてsecureですが、量子計算の観点ではRSAとECCは長期維持の前提を置きにくく、将来はhistorical側へ移る可能性を抱えています。
一方で共通鍵系は量子影響を受けても直ちに使えなくなるわけではなく、鍵長の選び方で余裕を持たせる発想が取れます。

AESは何をしているのか——現代の共通鍵暗号を直感でつかむ

AESは、現代の共通鍵暗号の中心にある「データ本体を高速に守る仕組み」です。
やっていること自体は、128ビット単位のデータに対して複数回のかき混ぜを加え、鍵を知らない相手には元の形が見えない状態へ変えることにあります。
ここが暗号の美しいところなのですが、強さは難しい数式だけで決まるのではなく、どのモードで使うか、改ざん検知をどう組み合わせるか、鍵や乱数をどう扱うかまで含めて初めて実用上の安全性になります。

仕様と4つの基本操作

AESの仕様をまず押さえると、ブロック長は128ビットです。
つまり、平文を128ビットずつの固まりに区切って処理します。
鍵長は128ビット、192ビット、256ビットの3種類があり、それに対応してラウンド数は10回、12回、14回になります。
鍵が長いほど、かき混ぜる回数も増える設計です。

この「ラウンド」は、同じ型の操作を何度も重ねる工程だと考えると直感がつかめます。
図解があると最も理解しやすいのですが、言葉だけでいえば、AESはデータの並びを置き換え、ずらし、列方向にも混ぜ、最後に鍵を重ねることを繰り返します。
4つの基本操作は、料理で材料をかき混ぜる感覚に近いです。
ただ混ぜるだけでは偏りが残るので、混ぜ方の違う工程を重ねて、元の形を追えないようにしていきます。

SubBytesは、各バイトを別の値に置き換える操作です。
見た目には「同じ文字を別の記号に一斉変換する」工程に近く、単純な規則性を崩します。
ShiftRowsは、行ごとに少しずつ位置をずらす操作で、もともと同じ列にいた値の関係を崩します。
MixColumnsは、列単位で値を混ぜ合わせる操作で、1か所の変化が列全体へ広がるように働きます。
AddRoundKeyは、ラウンド鍵をデータに重ねる工程で、ここに秘密鍵の情報が直接効いてきます。

この4つを並べて見ると、AESは「鍵で一発変換する暗号」ではありません。
局所的な規則を崩し、位置関係を崩し、隣接データにも影響を広げ、鍵の情報を注入する。
その積み重ねで、入力と出力の関係を人間の目にも機械的な推測にも見えにくくします。
筆者は実装検証の場面で内部状態の変化を追ったことがありますが、数ラウンド進んだだけで元の並びとの対応が急速に追えなくなる感覚があります。
直感に反するかもしれませんが、AESの強さは「派手な1回の変換」ではなく、「性質の違う混ぜ方を何度も重ねる設計」にあります。

モードとAEADが必要な理由

AESを理解するとき、アルゴリズム本体だけ見ていると実務の感覚を外します。
AESは128ビットのブロックを処理する仕組みなので、実際のファイルや通信のような長いデータを扱うにはモードが必要です。
ここでいうモードは、ブロックごとの暗号化をどうつなぐかという運用ルールです。

この話で最も有名なのがECBです。
ECBは各ブロックを独立に暗号化するので、同じ平文ブロックは同じ暗号文ブロックになります。
つまり、内容は読めなくてもパターンが残るのです。
PNG画像をECBで暗号化すると輪郭が残る例は、その性質をひと目で示します。
筆者も最初にこの話を聞いたときは半信半疑でしたが、「画像なのに暗号化後も形が見える」という口頭の説明を追うだけで、同じ模様が同じ模様のまま置き換わっている情景が頭に浮かびました。
暗号化したのに構造が漏れるという事実は、モード選択を軽く見られないことを強く印象づけます。

そこでECBの代わりに、ブロック間へ関係を持たせるモードが使われます。
代表例がCBCやCTRで、さらに現在の実務ではGCMのようなAEADが主役です。
CBCやCTRは、単に「AESで暗号化する」だけではなく、前のブロックやカウンタ値を取り込んで同じ平文パターンがそのまま並ばないようにします。
ただし、秘匿だけでは足りません。
暗号文が途中で書き換えられたとき、それを検知できなければ通信や保存データの安全性は崩れます。

そこで必要になるのがAEADです。
AEADは、暗号化による秘匿と、改ざん検知のための認証を一体化した構成です。
AESではGCMやCCMが代表例で、いずれも「読めない」だけでなく「勝手にいじられていない」ことまで確認できます。
TLS 1.3でAES系が使われるときも、この発想が中心にあります。
単体のAESを裸で置くのではなく、AEADとして組み込んで初めて現代的な通信保護になります。

ここで見逃せないのが、安全性はアルゴリズム単体で完結しないという点です。
鍵管理が甘ければAES-256でも意味がなく、乱数やノンスの扱いを誤ればモードの前提が崩れます。
実装に不備があれば理論上の強さを現場へ持ち込めません。
暗号はしばしば「方式選定」で語られますが、運用上の差はその周辺で決まります。

通信と保存での使われ方

AESが最も活躍するのは、前述の通りデータ本体の暗号化です。
通信では、TLSのセッションで確立した共通鍵を使って、Webの本文やAPI通信の中身を守る役割を担います。
公開鍵暗号が鍵共有や認証の入り口を担当し、その後の大量データはAESのような高速な共通鍵暗号が引き受ける、という分担です。
公開鍵暗号だけで通信本文を丸ごと処理しないのは、速度と効率の面で役割が違うからです。

保存では、ストレージ暗号化やバックアップ暗号化が典型例です。
ノートPCのフルディスク暗号化、社内サーバーの保存領域、外部媒体へ退避するバックアップデータなど、容量が大きい場面でAESは特に相性が良いです。
筆者自身、手元のPCでディスク暗号化を有効にしたとき、構えるほどの速度低下は体感しませんでした。
暗号化という言葉から重たい処理を想像しがちですが、AESはその印象を裏切るくらい高速で、日常操作の中に自然に溶け込みます。

この高速性があるからこそ、AESは「特別な機密ファイルだけを守る方式」ではなく、「普段使いの通信と保存を標準で守る方式」になりました。
通信路ではTLSの一部として、保存ではディスクやバックアップの暗号化として、見えないところで常時働いています。
読者が普段触れているWindowsのPC、Macのノート、iPhoneのような端末でも、利用者が毎回暗号方式を意識しなくても、データ本体の保護ではこの種の共通鍵暗号が中心です。

その一方で、AESを採用しているという事実だけで安全だとは言い切れません。
通信なら鍵共有の前段や認証の設計まで含めて見る必要があり、保存なら鍵をどこで保持するかが肝になります。
AESは現代暗号の主力ですが、主力であるがゆえに「アルゴリズム名を知って満足する」のでは足りず、どのモードで、どの認証つき構成で、どの鍵管理の上に乗っているかまで見て初めて全体像がつかめます。

RSAとECCは何が違うのか——公開鍵暗号の代表2方式を比べる

RSAとECCはどちらも公開鍵暗号ですが、同じ「公開鍵暗号」という箱に入れてしまうと実務上の違いを見落とします。
RSAは大きな合成数の素因数分解の困難性に依存する構成で、ECCは楕円曲線離散対数問題（EC-DLP）の困難性に基づく構成です。
この違いは、必要な鍵長、署名や鍵交換の効率、TLSや証明書での扱われ方、そして量子計算への備え方にそのまま表れます。

安全性の根拠の違い

RSAの中核にあるのは、大きな合成数を素因数分解することの困難さです。
公開鍵の背後には巨大な整数の積があり、その元になった素数を現実的な計算量で取り出せないことが安全性の前提になります。
ここが暗号の美しいところなのですが、RSAは「掛け算は簡単だが、元の素数へ戻すのは難しい」という非対称性を利用して公開鍵と秘密鍵を分けています。

一方のECCは、楕円曲線上の離散対数問題を解くことの困難さを安全性の土台にしています。
平たく言えば、ある点を何回も足し合わせて得られた結果から、何回足したのかを逆算するのが難しい、という性質です。
RSAが整数の世界で動くのに対し、ECCは楕円曲線という代数的な構造の上で動きます。
数学の景色は違いますが、どちらも「計算しやすい方向」と「逆向きに解きにくい方向」をうまく分けている点で共通しています。

この差は、同じ安全水準を目指すときの鍵サイズに現れます。
実務で広く使われてきたRSAは2048ビットが代表的で、より高い安全性の目安としてはRSA 3072ビットが使われます。
ECCでは256ビット級の鍵で、RSA 3072ビットに近い安全性を狙えるという目安があります。
つまりECCは、数学的な問題設定が違うことで、同じ水準の安全性に届くまでの鍵長を短く抑えられるのです。

鍵長・性能・用途の比較

鍵長が短いことは、単にファイルサイズが小さいという話で終わりません。
公開鍵、署名、証明書チェーン、ハンドシェイク中の計算量にまで効いてきます。
筆者が開発環境でRSA-2048の鍵生成とP-256の鍵生成を試したときも、この差は印象に残りました。
RSA-2048は素数生成を含むため少し待たされる感覚があり、ログを見ながら「今まさに大きな数を探している」と実感しましたが、P-256の鍵生成はそれより軽快で、検証用の鍵を何本も作る場面でも手が止まりませんでした。
理論の違いが、開発者の体感時間にまで降りてくるわけです。

速度面では、RSAは公開鍵演算の中でも比較的重く、ECCはRSAより効率的な場面が多いという整理になります。
ただし、何が速いかは処理の種類で見分ける必要があります。
RSAは歴史的に署名と鍵配送で広く使われ、TLS 1.2以前ではRSA鍵交換も長く使われてきました。
現在のTLSでは、鍵交換はECDHE、署名はECDSAが中心で、TLS 1.3では暗号スイート自体も整理され、古いRSA鍵交換の役割は歴史的なものになりました。
いまの通信でRSAが消えたわけではなく、証明書の署名鍵としてRSAが残る場面はまだあるが、接続時の鍵共有は楕円曲線系が主役という理解が実務に近いです。

証明書の運用でも差が出ます。
RSA鍵の証明書チェーンはサイズが大きくなりやすく、検証時のコストも積み上がります。
ECCの証明書は鍵や署名が小さいため、モバイルやIoTのように通信量や計算資源を節約したい場面と相性が良いです。
iPhoneやMacで体感するHTTPSの軽快さは公開鍵暗号だけで決まるわけではありませんが、ハンドシェイクと証明書まわりの効率差は確実に効いています。

その一方で、互換性の現場ではRSAのしぶとさも感じます。
筆者は古い機器のファーム更新を検証した際、RSA署名の検証は通るのに、楕円曲線方式の署名や鍵交換が未対応という機器に出会いました。
仕様書だけ見ると「公開鍵暗号対応」と書かれていても、中身はRSA前提のまま止まっていることがあります。
ここにRSAの歴史的な厚みがあり、ECCが技術的に優れていても、既存資産との接続ではRSAが残り続ける理由があります。

比較をひと目で整理すると、実務では次のように見ると把握しやすくなります。

量子時代を見据えた使い分け

量子計算を考えると、RSAとECCは対立候補というより同じ側にいる方式です。
どちらもShorのアルゴリズムの影響を強く受けるため、十分な量子計算機が現実化したときには安全性の前提が崩れます。
ECC 128ビット安全を破る量子資源の見積もりとして約2330量子ビットという数字があり、同等水準のRSA 3072ビットはさらに多くの量子資源を要する説明になりますが、実務上の結論は「RSAのほうが少し粘るかもしれない」ではありません。
Shorが現実の攻撃手段になる世界では、両者とも移行対象です。

そのため、現在の使い分けは「RSAかECCか」だけで決める段階を越えつつあります。
短中期では、既存のRSAやECCをすぐ全面停止するのではなく、ハイブリッド署名やハイブリッドKEMを使って、従来方式とポスト量子方式を併用する流れが現実的です。
既存のPKIやTLSの互換性を保ちながら、新しい前提へ橋を架ける形です。
2024年には初回の正式なPQC標準が3つ出そろい、移行の時間軸も具体化してきました。

ここでの整理は明快です。
現時点の実務で古典的公開鍵暗号を使うなら、新規設計ではECCが第一候補になりやすく、RSAは互換性と既存資産の都合で残るという構図です。
とはいえ、RSAをdeprecatedと断じる段階ではなく、証明書や署名基盤では今もsecureとして扱う場面があります。
逆に、TLSにおけるRSA鍵交換は歴史的役割を終えており、ここはhistoricalと見るのが適切です。
量子時代の設計では、RSAとECCの優劣よりも、古典方式をどう安全に畳みながらPQCへ接続するかが中心テーマになります。

TLS 1.3では実際にどう組み合わされるのか

HTTPSの中では、1つの暗号が全部を担当しているわけではありません。
TLS 1.3では、ハンドシェイクで共有鍵を安全に作り、その後の通信本文はAES-GCMまたはChaCha20-Poly1305のようなAEADで保護し、証明書確認やハンドシェイクの認証には署名方式が別に関わる、という役割分担がいっそう明確になりました。
筆者が開発用サーバをTLS 1.2から1.3へ切り替えたときも、体感として最初に感じたのは「暗号スイートの見通しがよくなり、ハンドシェイクが短くなった」という点で、内部の設計思想がそのまま運用の扱いやすさに表れていました。

TLS 1.2との構成差

TLS 1.2以前の暗号スイートは、鍵交換、署名、本文暗号、ハッシュが1本の名前にまとめて入っていました。
たとえば TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 のように、ECDHEで鍵交換し、RSAで認証し、AES-GCMで本文を守り、SHA-256を関連処理に使う、という情報が一続きで表現されます。
仕組みとしては理解できますが、選択肢が増えるほど組み合わせが膨らみ、何が古くて何が現役なのかを見失いがちでした。

TLS 1.3ではここが整理され、暗号スイートはAEADとハッシュの組として定義されます。
鍵交換はスイートの外側で行われ、署名方式も独立して交渉されます。
つまり「どの方法で共有鍵を作るか」と「その共有鍵で本文をどう守るか」を分離したわけです。
ここが暗号の美しいところなのですが、役割を分けるだけで安全性の議論も実装の見通しも一気に明快になります。

この変更によって、TLS 1.2時代に長く使われたTLS_RSA系、つまりRSA公開鍵そのものでセッション鍵を包んで渡す方式は主役から外れました。
古くなった理由ははっきりしていて、前方秘匿性を持てないからです。
後日サーバ秘密鍵が漏れると、過去に記録されていた通信まで復号できる構造になりやすく、現在の安全要件に合いません。
TLS 1.3は一時鍵を使う鍵交換を前提にしたため、過去の通信をまとめて守る設計へ寄せられました。

同時に、RC4やAES-CBCのような古い本文保護方式も外されました。
RC4は方式そのものに問題を抱え、CBC系は実装や運用で注意点が多く、現代のTLSで標準の中心に置く理由が薄れています。
TLS 1.3に切り替えると設定項目が減って見えるのは偶然ではなく、危険な枝をあらかじめ切り落としているからです。

TLS 1.3のスイート5種とAEAD

TLS 1.3で定義される暗号スイートは5種類です。ポイントは、どれも「本文を守るAEAD」と「鍵導出などで使うハッシュ関数」の組になっていることです。

この中で実務の中心にいるのは、AES-GCM と ChaCha20-Poly1305 です。
どちらもAEAD、つまり暗号化と完全性保護を一体で扱う方式で、本文を読めなくするだけでなく、途中で書き換えられていないかも同時に検出します。
前述の通り、いまの通信は「暗号化だけ」では足りず、改ざん検知まで含めてはじめて実用になります。
TLS 1.3の暗号スイートがAEAD中心に整理されたことで、この前提が名前のレベルでも明確になりました。

筆者はモバイル回線が不安定な環境で配信系サービスの接続設計を見ることがありますが、その場でChaCha20-Poly1305を優先したくなる理由はとても実務的です。
AES向けの専用命令を持たないCPUでは、ChaCha20-Poly1305のほうが素直に速く、電力や待ち時間の面でも扱いやすいからです。
古いAndroid端末や軽量な組み込み系SoCを意識する現場では、単に「強い暗号を選ぶ」ではなく、「その端末で無理なく回る暗号を選ぶ」が品質そのものになります。
逆にMacBook Airや最近のスマートフォンのようにAESのハードウェア支援が効く環境では、AES-GCMが自然な第一候補になります。

本文はAES/ChaCha20の実際

直感に反するかもしれませんが、HTTPSでページ本文やAPIレスポンスを守っている主役はRSAではありません。
実際の流れは、まずハンドシェイクでサーバ証明書を確認し、鍵交換でその接続だけの共有秘密を作り、そこからセッション鍵を導出し、そのセッション鍵でHTTP本文をAEAD暗号化する、という順番です。
本文を暗号化しているのはAES-GCMかChaCha20-Poly1305であり、RSAやECCはその前段で鍵交換や署名に関わるという理解が実態に一致します。

たとえばブラウザがChromeやSafariでWebサイトへ接続するとき、サーバは証明書を提示し、その証明書にはRSA鍵やECC鍵が使われていることがあります。
そこで公開鍵暗号が担うのは「相手が本物かを確かめる」「安全に鍵交換を成立させる」という役目です。
接続が成立した後、HTML、画像、Cookie、APIのJSONといった長いデータ列を毎回RSAで暗号化するわけではありません。
公開鍵暗号は長文処理に向かず、速度面でも不利なので、ここは共通鍵暗号に仕事を渡します。

この役割分担を図式化すると、TLS 1.3は次のように見ると腹落ちします。

1. クライアントとサーバがハンドシェイクを始める
2. 鍵交換でその接続専用の共有秘密を作る
3. 署名でサーバの正当性を確認する
4. 共有秘密からセッション鍵を導出する
5. そのセッション鍵で本文をAES-GCMまたはChaCha20-Poly1305で暗号化・認証する

この構造を理解すると、「RSAで通信内容を暗号化している」という古いイメージがなぜずれているかが見えてきます。
RSAは今でも証明書や署名の文脈では残りますが、通信本文を高速に守る担当ではありません。
筆者がTLS 1.3化の作業で感じた簡素さも、まさにここに由来します。
何を選ぶ設定なのかが分離され、本文保護はAESかChaCha20、鍵交換は前方秘匿性を持つ方式、署名は証明書に応じて別管理、という形になったことで、HTTPSの内部がブラックボックスではなく機能分担の集合として見えるようになります。

量子時代に向けて何が変わるのか——PQCの現状

量子計算が実用域に近づくにつれて、暗号の世界で先に揺らぐのは公開鍵暗号であり、共通鍵暗号は同じ形では崩れません。
ここが暗号の美しいところなのですが、同じ「暗号」でも安全性を支える数学が違うため、RSAやECCとAESでは量子計算から受ける打撃の質がまったく異なり、移行計画も一律ではなくなります。

量子計算の影響の受け方の違い

RSAとECCが量子時代で問題になる理由は、どちらも公開鍵暗号として特定の数学的困難性に依存しているからです。
RSAは素因数分解の難しさ、ECCは楕円曲線離散対数問題の難しさを安全性の土台にしていますが、量子計算ではShor型のアルゴリズムによってこの前提が崩れます。
つまり、古典計算機では現実的時間で解けないから安全だった問題が、量子計算機では別の計算量で処理できるようになり、証明書、鍵共有、電子署名といった公開鍵基盤そのものが影響を受けます。

AESのような共通鍵暗号は同じ意味では壊れません。
量子計算で意識すべきなのはGrover型の探索高速化で、総当たり探索の計算量が平方根程度まで縮むため、実効鍵長が半減的に見える、という整理が正確です。
AESは128ビットのブロック長を持ち、鍵長は128・192・256ビットですが、この文脈ではAESそのものが無効化されるのではなく、十分な余裕を見るならAES-256を選ぶ、という発想になります。
AES-128がただちに使えないと言っているのではなく、量子計算を見据えた長期保護ではAES-256の位置づけが上がる、という理解が実務に近いです。

この差は、前のセクションで見たTLS 1.3の役割分担にもそのまま重なります。
通信本文を守るAEADは引き続き共通鍵暗号が中心ですが、入口の鍵交換や署名は量子耐性のある方式へ置き換える必要が出てきます。
つまり量子対応とは「全部を捨てて全部を入れ替える」話ではなく、どの層が何に依存しているかを分けて考える作業です。

NIST標準化の到達点

2024年8月には、PQCの最初の正式標準が3つ出そろい、議論段階から実装・調達・運用設計の段階へ入ったと見てよい状況になりました。
ここで中核にいるのが ML-KEM で、鍵共有の置き換え先として最も実務的な存在です。
加えて署名系の標準も正式化され、PQCは「候補を眺める研究テーマ」ではなく、「どこから業務に組み込むか」を決める対象になっています。

この節目が大きいのは、従来のRSAやECCに対して、量子耐性を持つ代替手段が名前付きで定まり始めたことです。
公開鍵暗号はプロトコル、証明書、HSM、OSの暗号API、ブラウザ、ライブラリ実装まで横断的に関わるため、標準が定まらない状態では現場が動けませんでした。
標準化が進んだことで、少なくとも鍵交換はどの方式を軸に見ればよいかが見え、設計の前提条件がそろってきています。

筆者は暗号実装の検証に関わった経験から、標準化の意味を机上の形式文書としてではなく、「異なる製品やライブラリ間で会話が成立する条件」として見ています。
ブラウザやOSの暗号APIは数年単位で顔ぶれが変わり、ChromeやSafariの実装方針、WindowsやmacOSの提供機能も追随して動きます。
そのたびにアプリケーション側が暗号方式へべったり依存していると、差し替えのたびに周辺設計まで巻き込まれます。
PQCでよく語られる暗号アジリティは、流行語ではなく、数年後のAPI変更に耐えるための設計原則です。

移行の実務：ハイブリッドと優先順位

移行の現実解は、当面のあいだ従来方式とPQCを組み合わせるハイブリッド運用です。
鍵交換なら既存の方式に ML-KEM を重ね、署名でも従来方式とPQC署名を併用する構成が自然です。
これなら、いきなり全面切替に踏み込まずに互換性と将来耐性の両方を確保できます。

移行時期の目安としては、量子脆弱な方式を2035年ごろまでに段階的に外していく流れが基準になります。
ただし、同じ組織の中でも優先順位は一律ではありません。
暗号資産の秘密鍵、長期間保管するバックアップ、法定保存年限の長い契約文書や医療・知財関連の記録は、いま盗まれて後で解読されると被害が成立します。
逆に、数時間から数日で価値が薄れる通信ログや一時セッションは、公開鍵部分の移行は必要でも、長期秘匿データほど前倒しの圧力はかかりません。

筆者が関わった棚卸しでは、まず暗号方式ではなく「何年守る必要があるデータか」を一覧化しました。
バックアップは保存先ごとに保護年限が違い、法定文書は部門ごとに保持期間がずれていたため、先に移行すべき対象はシステムの重要度順ではなく、漏えい後も価値が残り続ける情報 の順に並びました。
この整理をすると、PQC対応は全社一斉の掛け声ではなく、長期秘匿データ、外部公開PKI、署名基盤、クライアント配布物の順で分けて設計したほうが筋が通ります。

実務では、暗号アジリティをどう実装するかも差になります。
方式名をコードに埋め込まず、鍵交換・署名・鍵導出を抽象化し、将来RSAやECCからPQC系へ差し替えてもアプリケーションの責務が変わらない形にしておくと、移行は現実的な工数に収まります。
逆に、証明書形式、鍵長、ライブラリ関数、保存フォーマットが密結合している設計では、PQCの導入が暗号だけの変更で済みません。
量子時代への備えは新しいアルゴリズム名を覚えることより、「あとで差し替えられる構造」を先に持てるかどうかで明暗が分かれます。

まとめ——用途別に見るどの方式をどう使うか

暗号は、方式名を覚えることより「どの役割をどの層で担うか」を見分けると一気につながります。
通信なら鍵交換と署名で入口を固め、本文はAEADで守る。
保存はデータ本体の暗号化と完全性確認を分けて考え、改ざん検知はハッシュやHMACに任せる。
この切り分けができると、学習でも実務でも次に見るべき論点が迷わなくなります。

筆者は学び始めの頃、自分用の「暗号の地図」をA4一枚に描いて机に貼っていました。
共通鍵暗号・公開鍵暗号・ハッシュ関数を中央に置き、通信、保存、署名、鍵共有、改ざん検知へ線で結ぶだけですが、用語が頭の中でばらばらに浮かぶ状態から、「これは本文用」「これは入口用」と役割で結び直せるようになりました。
読者もまずは、自分の仕事や学習対象をその地図のどこに置くかから始めると、記事全体の内容が実務の判断に変わっていきます。