← 一覧へ
セキュリティ・個人情報
#대칭암호#비대칭암호#공개키#AES#RSA#132회
最終更新 · 2026-10-01

対称暗号化と非対称暗号化

1. 概要

A. 定義

対称暗号化(Symmetric Key Cryptography) は暗号化と復号に同一の秘密鍵を用いる方式であり、非対称暗号化(Asymmetric、公開鍵暗号) は数学的に対をなす公開鍵・秘密鍵のペアを用いて、一方の鍵で暗号化すると必ずもう一方の鍵でのみ復号されるように設計された方式である。

両方式の根本的な違いは「鍵を共有するのか、分けるのか」にある。対称暗号は送・受信者が同じ秘密をあらかじめ共有しなければならないため演算は速いが、その秘密を安全に伝達する問題が必ず残る。非対称暗号は鍵を公開用と秘密用に分離し、公開鍵は誰にでも配布し秘密鍵は所有者のみが密かに保管する。この「非対称性(一方を公開しても他方を逆算できないこと)」のおかげで、事前共有がまったくない見知らぬ相手とも安全な通信と身元証明が可能になる。

両方式は競合関係というより役割が異なる相互補完関係として理解すべきである。対称は「速い金庫」であり、非対称は「鍵を安全に手渡す手段」である。実際のプロトコルはほぼ例外なく両者を併用する。技術士の観点で重要なのは、各方式の数学的根拠(難問)と性能特性を理解し、与えられたセキュリティ要件(機密性・完全性・認証・否認防止)と性能・規制の制約に合わせて組み合わせを設計する能力である。

B. 登場背景および必要性

初期の暗号はすべて対称方式であり、参加者が増えるほど鍵配送(Key Distribution) が難問となった。n人が互いに1:1で通信するにはn(n-1)/2個の秘密鍵が必要であり、これらの鍵をどう安全に分け合うかはそれ自体がまた別のセキュアチャネルを要求した。「暗号化されたメッセージをやり取りするにはまず鍵を安全に共有しなければならないが、その鍵を安全に共有するにはまた別の暗号が必要だ」という循環問題が、暗号学の長年の壁であった。

1976年にWhitfield DiffieとMartin Hellmanが公開鍵の概念と鍵交換プロトコルを提示してこの循環を破り、1977年にRivest・Shamir・AdlemanがRSAによってこれを実用的なアルゴリズムとして実装した。公開鍵暗号は「公開チャネルで事前共有なしに秘密を合意できる」という革新であり、電子商取引・インターネットバンキング・証明書ベースの信頼体系(PKI)の土台となった。

しかし公開鍵演算は大きな整数のべき乗などの重い数学演算を伴い、対称と比べて数百〜数千倍遅いため大容量データの暗号化には不向きである。そこで実務では非対称で鍵を安全に交換し、実際の本文は対称で高速に暗号化するハイブリッド構造により、両方式の長所だけを取る。この構造こそが今日のHTTPS、VPN、メッセンジャーの端末間暗号化に共通する骨格である。

C. 両方式の中核的特徴

  • 対称: 演算が速く実装が単純なため大量・リアルタイム処理に適するが、通信相手ごとに秘密鍵を安全に事前共有しなければならず、共有という性質上、否認防止は成立しない。
  • 非対称: 事前共有なしに開放型環境で安全な通信と電子署名・否認防止が可能だが、演算が重く本文暗号化には不向きで、公開鍵が本当に所有者のものであることを保証する信頼基盤(PKI・証明書) が必ず必要である。
  • 共通の前提: いずれの方式でも安全性は「鍵の秘密保持」に全面的に依存しており、アルゴリズムが公開されても鍵さえ安全なら安全だというケルクホフスの原理(Kerckhoffs's principle) に従う。

2. 動作方式と数学的根拠の比較

A. 全体構造図

flowchart LR
  subgraph SYM["対称暗号化(同じ鍵)"]
    A[平文] -->|秘密鍵 K| B[暗号文] -->|同じ秘密鍵 K| C[平文]
  end
  subgraph ASYM["非対称暗号化(公開/秘密鍵)"]
    D[平文] -->|受信者の公開鍵| E[暗号文] -->|受信者の秘密鍵| F[平文]
  end

対称方式は一つの秘密鍵が暗号化・復号の両方でそのまま使われるため演算が単純で速い。AESのようなブロック暗号は置換・順列(SPN)またはFeistel構造を複数ラウンド繰り返す比較的軽いビット演算から成り、最新CPUのハードウェア加速命令(AES-NI)まで支援され、毎秒数GBを処理する。すなわち性能が重要な大量トラフィック・ディスク暗号化に適する。このような撹乱(Confusion)と拡散(Diffusion)の繰り返しが平文-暗号文間の統計的相関を消し去り、全数探索以外では破りにくくする。

一方、非対称は数学的難問に安全性を委ねる。RSAは「二つの大きな素数の積は容易に求められるが、その積を再び素因数分解するのは極めて難しい」という素因数分解難問に、ECC(楕円曲線暗号)は「楕円曲線上の点加算は容易だがその逆(離散対数)は難しい」という難問に基づく。公開鍵を公開しても秘密鍵を現実的な時間内に逆算できないため、鍵を事前共有する必要がなくなる。その代償として演算コストが大きく、大容量処理には不向きである。

B. 特性比較とトレードオフ

区分 対称暗号化 非対称暗号化
鍵 同一の秘密鍵 公開鍵/秘密鍵のペア
速度 速い 遅い(数百〜数千倍)
鍵配送 難しい(事前共有が必要) 容易(公開鍵の配布)
鍵の個数 n(n-1)/2 2n
安全性の根拠 置換・順列の撹乱・拡散 素因数分解・離散対数の難問
代表的アルゴリズム AES, SEED, ARIA, LEA, DES(廃止) RSA, ECC, ElGamal, DH
主な用途 大容量データの暗号化 鍵交換・電子署名・認証

鍵の個数の違いが中核的なトレードオフをよく示す。100人が互いに通信する際、対称は約4,950個(=100×99/2)の鍵を生成・保管・廃棄しなければならないが、非対称は各自が一対ずつで計200個あればよい。すなわち参加者が多く事前関係のない開放型環境ほど非対称の鍵管理の利点が極大化する。逆に少数の固定された当事者が大量データをやり取りする閉鎖網・ストレージ暗号化では対称が圧倒的に有利である。

速度の差は数値で実感できる。サーバ級CPUでAES-256は毎秒数GBを暗号化するが、RSA-2048の署名検証は毎秒数千〜数万件程度、署名生成はそれよりさらに遅い。このため「本文自体を公開鍵で暗号化する」設計は性能上ほとんど使われず、公開鍵は小さなセッション鍵やハッシュ値にのみ適用する。

安全性の根拠が異なる点も含意が大きい。対称暗号の安全性は「鍵空間が大きすぎて全数探索が不可能だ」という点にあり、鍵長さえ十分なら量子コンピュータ時代にも比較的耐えられる(Grover攻撃は探索を平方根のレベルで速くするにすぎない)。一方、非対称は特定の数学的難問の「難しさ」に委ねるため、その難問を破るアルゴリズム(例: 量子のShor)が登場すれば鍵長に関係なく崩れる。この構造的な違いが、後で扱うPQC移行の核心的な背景である。

C. 対称暗号の運用モード

対称ブロック暗号は平文を固定サイズのブロック(AESは128ビット)に分けて処理するため、ブロックをどう連結・反復するかを定める運用モード(Mode of Operation) が安全性を左右する。最も単純なECBモードは同じ平文ブロックが常に同じ暗号文になりパターンが露呈するため、事実上使用禁止である。CBCは前のブロックの暗号文を次のブロックに混ぜてパターンを消すが、完全性は保証しない。

今日の事実上の標準はAES-GCMのような認証付き暗号(AEAD) モードである。暗号化と同時に認証タグを生成して「機密性 + 完全性 + 認証」を一度に提供するため、別途MACを付ける過程で生じていた実装ミスを減らす。またCTR系列は並列処理が可能で高速ネットワークに適する。技術士の答案では「対称暗号を使う」とだけ書くよりもどのモードをなぜ使うのかまで記述すれば深みが表れる。

モード選択で見落としやすい要素が初期化ベクトル(IV)・ノンス(Nonce) の管理である。CBC・CTR・GCMいずれも同じ鍵に同じIVを再利用すると安全性が急激に崩れ、特にGCMはノンス再利用時に認証鍵まで露出しうるため致命的である。したがってIVは予測不可能であるか(CBC)、絶対に重複しないように(GCM)管理せねばならず、これは「アルゴリズムは安全でも運用が安全性を左右する」という原則をよく示す。

D. 国産アルゴリズムと鍵長

国内の公共・金融システムでは、KISAが開発・検証したSEED(128ビットブロック)、ARIA(128/192/256)、LEA(軽量) などの国産対称アルゴリズムの使用が推奨・要求される場合が多い。ARIAは国家標準(KS)であり国際標準としても登録されており、LEAはIoT・モバイルなど資源制約環境を狙った軽量高速暗号である。電子署名・認証領域では国産公開鍵署名アルゴリズム(KCDSA/EC-KCDSA)も併せて活用される。

安全な鍵長としては、対称はAES-128以上(長期保護は256)、非対称はRSA-2048以上(長期保護は3072以上)が通用し、同じセキュリティ強度を短い鍵で達成するECC(例: 256ビット ≈ RSA 3072ビット) がモバイル・IoTで好まれる。鍵が短いほど演算・保存・伝送・電力の負担が減るため、バッテリ・帯域幅が制限されたセンサノードやスマートカードでのECCの実務的含意は特に大きい。

3. 提供するセキュリティサービス

暗号方式の選択は「どのセキュリティサービスが必要か」によって変わる。情報保護の中核的な目標は機密性・完全性・可用性(CIA)に加えて認証と否認防止であり、各目標をどの方式がどう達成するのかを区別して設計せねばならない。

機密性(Confidentiality) は対称・非対称どちらでも提供できるが、性能のため実際には本文を対称で暗号化し、そのセッション鍵だけを非対称で保護する。平文がいくら大きくても暗号化は対称が担い、非対称は「小さな鍵を安全に手渡す」役割だけを担うのが定石である。

認証(Authentication)と否認防止(Non-repudiation) は非対称固有の強みである。送信者が自分の秘密鍵で署名すれば誰でも彼の公開鍵で検証できるが、秘密鍵は本人のみが保有するため「彼が署名したこと」を後で否認できない。対称暗号では両者が同じ鍵を共有するため「二人のうち誰が作ったのか」を第三者に証明できず、否認防止が成立しない。この違いが、電子署名・証明書が必ず公開鍵ベースである理由である。

完全性(Integrity) は原文のハッシュ値(SHA-256など)を署名するか、メッセージ認証コード(MAC/HMAC)を付けて、伝送中に1ビットでも改ざんされればハッシュ・MACが変わって検証に失敗するという原理で保証する。電子署名は「完全性 + 認証 + 否認防止」を同時に提供する一方、HMACは対称鍵ベースで速いが否認防止は提供できない。したがって「二者間のメッセージ改ざんだけ防げばよい」内部通信にはHMACが、「第三者に作成者を証明せねばならない」電子文書・電子契約には電子署名が適するというように、要件に合わせて選択する。

サービス 実現方式 主に使う方式
機密性 本文暗号化 対称(本文) + 非対称(セッション鍵保護)
認証・否認防止 秘密鍵による電子署名 → 公開鍵で検証 非対称
完全性 ハッシュ(SHA-256) + 署名、またはHMAC 非対称/対称

ここで一点注意すべきは、公開鍵で「暗号化」する動作と秘密鍵で「署名」する動作が方向が反対だという点である。機密性のための暗号化は受信者の公開鍵で行い(受信者だけが秘密鍵で開けられねばならないため)、認証・否認防止のための署名は送信者の秘密鍵で行う(誰もが送信者の公開鍵で検証できねばならないため)。この方向性を混同すると「暗号化したのに誰でも開ける」設計の誤りが発生するため、技術士の答案ではどの鍵をどの目的に使うのかを明確に記述することが重要である。

RSA vs ECC — 同じ非対称でも異なる選択

同じ非対称系列でもRSAとECCは実務の選択が分かれる。RSAは歴史が長く実装・互換性が広いため、サーバ証明書とレガシーシステムで依然として幅広く使われる。一方ECCははるかに短い鍵で同等の強度を出すため、証明書サイズ・ハンドシェイク遅延・電力消費が重要なモバイル・IoT・大規模トラフィック環境で好まれる。例えばECC 256ビットがRSA 3072ビットと同等の強度を出すため、同じセキュリティ水準でECCは鍵・署名サイズを大きく減らす。ただし両方式とも量子コンピュータには脆弱であるため、長期的にはPQCへの移行という共通の課題を抱えている。

4. ハイブリッド方式(電子封筒)と適用手順

対称は速いが鍵配送が難しく、非対称は鍵配送が容易だが遅い。二つの弱点が互いの強みで正確に相殺されるため、両者を結合すれば「速くかつ安全に鍵を分ける」設計が可能になる。

両方式の限界を互いに補う代表的な設計が電子封筒(Digital Envelope) である。送信者はセッションごとに任意のセッション鍵(対称) を生成して大容量の本文を高速に暗号化し、そのセッション鍵だけを受信者の公開鍵(非対称) で暗号化して暗号文とともに送る。受信者は自分の秘密鍵でセッション鍵を復元したあと本文を復号する。こうすれば遅い非対称演算は小さなセッション鍵だけに、速い対称演算は大きな本文に使われ、性能と鍵配送を同時に解決する。

sequenceDiagram
  participant S as 送信者
  participant R as 受信者
  S->>S: セッション鍵(対称)を生成
  S->>S: 本文をセッション鍵で暗号化
  S->>S: セッション鍵をRの公開鍵で暗号化
  S->>R: 暗号文 + 暗号化されたセッション鍵を送信
  R->>R: 秘密鍵でセッション鍵を復元
  R->>R: セッション鍵で本文を復号

セッション鍵を毎回新しく生成することには明確な理由がある。もし同じセッション鍵を再利用すると、一度の鍵漏洩が過去・未来のすべての通信を崩し、同一の鍵で暗号化された大量のデータが統計的攻撃の標的になる。セッションごとに独立した一時鍵を使えば、たとえ一つが露出しても被害はそのセッションに限定される。この原則が、後で説明する前方秘匿性の土台でもある。

この構造はTLSハンドシェイク、S/MIMEメール暗号化、ディスク・文書暗号化ソリューションがすべて共有する。例えばHTTPS接続時、ブラウザはサーバ証明書の公開鍵(またはECDHE鍵交換)で対称セッション鍵を安全に合意したあと、実際のWebトラフィックはAES-GCMのような対称暗号でやり取りする。一度の接続で公開鍵演算はハンドシェイクの瞬間にのみ起き、以後の数十MBのページ・動画はすべて対称で処理されるため性能低下はほとんどない。

現代のTLS 1.3はここからさらに一歩進み、セッション鍵をRSAで「そのまま伝達」する代わりに、セッションごとに一時鍵ペアを使うECDHE鍵交換によって前方秘匿性(Forward Secrecy) を確保する。すなわちサーバの長期秘密鍵が後日漏洩しても、過去にキャプチャされたトラフィックは復号できない。これは「セッション鍵を公開鍵で包んで送る」という古典的電子封筒の限界(長期鍵漏洩時に過去すべてが露出)を克服した進化である。

具体的な適用事例

  • 電子商取引の決済: カード会社・PG社は加盟店との通信をTLSで保護し、機微なカード番号はさらにトークン化・対称暗号化して保存する。公開鍵は決済サーバの身元証明とセッション鍵合意に、対称鍵は実際の取引データ暗号化に使われる。
  • メッセンジャーの端末間暗号化(E2EE): 代表的なメッセンジャーは各ユーザ端末の公開鍵でセッション鍵を合意し(非対称)、実際のメッセージ・メディアは対称で暗号化する。サーバすら本文を見られず、中央サーバ侵害時にも内容が保護される。
  • ディスク・DB暗号化(TDE): 大容量の保存データは性能上必ず対称(AES-256)で暗号化しつつ、そのデータ暗号化鍵(DEK)を再びマスタ鍵(KEK)で包む鍵の階層化(Envelope Encryption) 構造で管理する。これは電子封筒の概念を保存領域に適用した事例である。

5. 深化 — 耐量子暗号(PQC)への移行動向

最も重要な最新の変化は量子コンピュータの脅威とPQC(Post-Quantum Cryptography)移行である。十分に大きな量子コンピュータで動作するShorアルゴリズムは素因数分解と離散対数を多項式時間で解けるため、現在のRSA・ECC・DHを根本的に無力化する。対称暗号はGroverアルゴリズムで探索が速くなるが鍵長を二倍に増やせば(例: AES-256)安全性が維持され、相対的に影響が小さい。したがって脅威の核心は公開鍵領域である。

特に「今収集して後で復号(Harvest Now, Decrypt Later)」 攻撃が実質的な危険である。攻撃者が今の暗号文を保存しておき、量子コンピュータが商用化される時点で復号すれば、長期間秘密に守るべきデータ(医療・国家機密・金融)は未来に露出する。すなわち「量子コンピュータがまだないから大丈夫だ」という判断は、長期機密データには通用しない。

これを受けて米国NISTは2024年8月にPQC標準を最終確定した。鍵カプセル化用のFIPS 203(ML-KEM、CRYSTALS-Kyberベース)、電子署名用のFIPS 204(ML-DSA、CRYSTALS-Dilithiumベース)、ハッシュベース署名のFIPS 205(SLH-DSA、SPHINCS+ベース) が代表的で、大半は格子(Lattice)ベースの難問に安全性を置く。実務の移行は既存アルゴリズムとPQCを併用するハイブリッド方式で漸進的に移行するのが推奨され、国内でもKISA主導でPQC移行ロードマップと耐量子性検証体系が推進されている。技術士の答案では「暗号アジリティ(Crypto-Agility)の確保 → 暗号資産の識別 → ハイブリッド適用 → 段階的な全面移行」という戦略の流れで整理すれば説得力が高い。

移行が簡単でない理由は、暗号がアプリケーション・プロトコル・ハードウェア・証明書体系に深く絡んでいるためである。PQCアルゴリズムは鍵・署名サイズが大きく、ネットワーク帯域幅・保存空間・ハンドシェイク遅延に影響を与え、レガシー装備・組込システムは交換周期が長く、混在期間が数年に及ぶ。したがって組織はまずどこにどの暗号が使われているかを全数調査(暗号資産インベントリ) し、アルゴリズムを設定で容易に変えられるよう抽象化したあと、危険度の高い(長期機密・対外露出)資産から優先して移行する段階的なアプローチを取らねばならない。

関連する過去問・連携テーマ

本テーマは情報管理技術士において、電子署名、PKI、電子封筒([[digital-envelope]])、ブロック暗号([[block-cipher]])、耐量子暗号([[post-quantum-crypto]])、準同型暗号([[homomorphic-encryption]])などと密接に連携して出題される。「対称・非対称の比較」は短答型としても、「ハイブリッド設計方策」や「PQC移行戦略」は論述型としても変形されるため、比較表の暗記を超えて要件→方式選択→実装モード→鍵管理→将来対応へとつながる設計論理を備えねばならない。

6. 考慮事項および示唆点

  • 鍵管理がすなわちセキュリティ水準: アルゴリズムがいくら強くても鍵が漏洩すれば無意味である。HSM(ハードウェアセキュリティモジュール) やKMSで鍵を保護し、生成・配布・使用・保管・更新・廃棄に至る鍵ライフサイクル(Key Lifecycle) を統制せねばならない。鍵漏洩時に被害を限定するには、セッション鍵を毎回新しく使う設計と前方秘匿性が重要である。
  • 安全な鍵長・アルゴリズムの選択: 計算性能の向上に備えてAES-256、RSA-2048/3072以上を維持し、資源制約環境では同等強度を短い鍵で出すECCを採用する。DES・MD5・SHA-1など脆弱・廃止アルゴリズムは即座に排除する。
  • PQC移行ロードマップの先制的策定: 「今収集して後で復号」の脅威を考慮し、長期機密データからNIST標準(ML-KEM/ML-DSA)ベースのハイブリッドへ先制的に移行し、アルゴリズムを容易に交換できる暗号アジリティをアーキテクチャに内在化する。
  • 要件・規制ベースの設計: 機密性だけが必要なのか、否認防止まで必要なのかによって対称・非対称・ハイブリッドを組み合わせる。国内システムはSEED・ARIA・LEAなど国産アルゴリズムの使用要件と、個人情報保護法・電子署名法などの規制順守も併せて考慮する。
  • 実装・運用上の落とし穴の警戒: 安全なアルゴリズムを使っても乱数品質の低下、パディングオラクル、証明書検証の省略、セッション鍵の再利用のような実装欠陥が実質的な漏洩経路になる。検証された暗号ライブラリと標準モード(AES-GCMなど認証付き暗号)を使い、自前実装(Roll-your-own crypto)は避ける。
  • 性能・規制・相互運用性のバランス: 金融・公共は処理量(TPS)と遅延の要求が厳しいため、ハードウェア加速・セッション再利用・コネクションプーリングで公開鍵演算コストを償却する。同時に国産アルゴリズム義務、個人情報暗号化告示、電子署名の有効性など規制順守と、外部システムとのアルゴリズム・証明書の相互運用性を併せて設計せねばならない。

総合すると、技術士の観点での暗号設計は「対称か非対称か」の二者択一ではなく、セキュリティ要件(機密性・完全性・認証・否認防止)と性能・規制・ライフサイクルの制約を総合して両方式を適材適所に組み合わせ、鍵管理体系で下支えし、量子時代に備えたアジリティまで内在化する総体的なアーキテクチャ設計として取り組まねばならない。

参考資料


一言まとめ: 対称暗号化は同一の秘密鍵で速いが鍵配送が難しく、非対称暗号化は公開/秘密鍵で鍵配送・電子署名に有利だが遅いため、実務では電子封筒・TLSのように非対称でセッション鍵を保護し対称で本文を暗号化するハイブリッドで結合し、量子コンピュータの脅威に備えてNIST PQC(ML-KEM/ML-DSA)ベースの移行を先制的に準備せねばならない。