ストリーム暗号の基礎から現代の実務運用まで—原理・代表アルゴリズム・脆弱性と安全な設計・実装ガイド
エバープレイ編集部はじめに
ストリーム暗号は、データをビットやバイト単位（あるいは小さなワード単位）で逐次的に暗号化する方式です。古典的なワンタイムパッドの考え方を起点に、疑似乱数列（keystream）を生成して平文とXORすることで暗号化を行います。リアルタイム性や低レイテンシ、組み込み機器での省資源実装に向くため、通信分野で広く用いられてきました。本稿では基礎から種類、代表的な方式、攻撃・脆弱性、設計・実装上の注意点、現代における推奨運用までを詳しく解説します。
ストリーム暗号の基本原理
ストリーム暗号は大まかに次の構成要素で成り立ちます。
- 鍵（key）および初期化ベクトル（IV, nonce）: 擬似乱数生成器の初期状態を与える。
- 擬似乱数生成器（PRNG, keystream generator）: 鍵とIVから長い疑似乱数列（keystream）を生成する。
- XOR操作: 平文とkeystreamを逐次XORして暗号文を得る（復号は同一のkeystreamをXORすることで平文を復元）。
理想的には、keystreamは真の乱数列に近い判断不能なものである必要があります。一度のみ使われかつ真に乱数であればワンタイムパッドは情報理論的に安全ですが、現実のストリーム暗号では疑似乱数（決定的）を用いるため、計算上の安全性（攻撃者が鍵や内部状態を推定できない）が求められます。
同期型と自己同期型（自動復帰型）の違い
- 同期型（synchronous stream cipher）: 送受信が同じkeystream生成器を保持し、符号化は独立に進む。欠点は同期がずれると復号が壊れることと、IV/nonceの使い回しが致命的な点。
- 自己同期型（self-synchronizing, cipher feedback）: keystreamが直近の暗号文ビットに依存するため、受信側はある程度の暗号文があれば同期を復元できる。ブロックを用いたストリーム化（CFB）などが該当する。
代表的なストリーム暗号と歴史的背景
- ワンタイムパッド: 理想的な安全性を持つが鍵を平文長分流通させる必要があり実用的ではない。
- RC4: かつて広く使われたバイト指向の擬似乱数生成器。TLSやWEPでの使用が問題となり、多くの脆弱性（初期出力のバイアスやFMS攻撃）が報告され、現在は非推奨・禁止（RFC 7465）となっている。
- SNOW 3G, ZUC: 3G/4G（3GPP）で採用されたストリーム暗号の例。SNOW 3Gは3GPPのUEA1/UIA1で、ZUCはLTE（EEA3/EIA3）で標準化されている。
- ChaCha20（および Salsa20）: Daniel J. Bernstein によるARX（加算・回転・XOR）ベースの高速ストリーム暗号。TLSやSSH、組み込み用途での採用が増え、ChaCha20-Poly1305は実用的なAEAD構成として広く推奨されている（RFC 8439）。
主要な脅威と攻撃手法
ストリーム暗号は設計や運用のミスにより重大な脆弱性を生じます。代表的な問題点を挙げます。
- keystream再利用（nonce/IVの重複）: 同じkeystreamを2つの平文に使うと、暗号文のXORで平文同士のXORが得られ、これが解析の出発点となる（致命的）。
- 初期バイアスと統計的区別攻撃: 一部の生成器は出力の初期部分に偏りがあり、これを利用して鍵や内部状態の推定が可能（RC4の事例）。
- 相関攻撃: 線形帰還移動レジスタ（LFSR）等を組み合わせた生成器では、内部ビットと出力の相関を突かれると内部状態が推定されうる。
- 代数攻撃・状態回復: 非線形構造でも代数的関係を解くことで秘密を求める手法がある。
- サイドチャネル攻撃: 実装上のタイミングや消費電力の変動から鍵が漏れる危険。
設計要素と評価基準
安全なストリーム暗号の設計・評価で注目すべき点は次の通りです。
- 周期の長さ: 実用的に無視できるほど長い周期が必要（十分大きな内部状態）。
- 統計的特性: 出力が一様で、既知のバイアスや相関がないこと。
- 鍵とIVの分離: 同じ鍵下でIVが繰り返されても安全性を損なわないか（通常はIVは再利用不可）。
- 再同期性とフォールト耐性: パケットロスやビット欠損が発生したときの取り扱い。
- 性能: ハードウェア／ソフトウェア双方での効率性、並列実行性。
- 解析耐性: 既知・選択平文攻撃、代数攻撃、TMTOなどへの耐性。
実装と運用上の注意点
設計上安全でも、実装や運用の誤りで破綻する事例が多くあります。主要な注意点を挙げます。
- nonce/IVは決して使い回さない（特に同期型）。固定長IVでも、必ず鍵とIVの組合せが一意になる運用を行う。
- 認証を併用する: ストリーム暗号単体は改ざん検知が無いため、認証コード（MAC）やAEAD（例: ChaCha20-Poly1305）を必ず併用する。
- 再鍵化ポリシー: 長時間同一鍵を使い続けない。大量データを暗号化する場合は定期的に再鍵化する。
- 初期出力の捨て方（drop-n）: 一部設計では初期出力に偏りがあるため、初期数バイトを捨てる手法が使われるが、根本的対策にはならないことがある。
- 定数時間実装とサイドチャネル対策: 特に組み込みやスマホでの実装では注意。
現代の動向と実務的推奨
近年は以下の傾向が顕著です。
- 既知の古い設計（RC4など）は非推奨化され、TLSやブラウザ、OSは使用を禁止している（RFC 7465）。
- AEAD方式の普及: 暗号化と完全性保護を同時に満たすChaCha20-Poly1305やAES-GCMが実務での主流。
- ハイブリッドな選択: 軽量デバイスではChaCha系がAESを上回ることもあり、環境に応じた選択が行われる。
実務的な推奨は次の通りです。
- 標準化かつ広く解析されたアルゴリズムを使う（ChaCha20-Poly1305、AES-GCM 等）。
- ストリーム暗号を使う場合でも認証を必須にする。単純なXOR暗号の直接利用は避ける。
- nonce/IV管理を厳密に行い、再利用が絶対に起きない運用を設計する。
- 実装のセキュリティ（サイドチャネルや正しいライブラリ利用）を徹底する。
まとめ
ストリーム暗号は高速・低レイテンシという利点から今も重要な役割を果たしていますが、設計や運用の不備が致命的な脆弱性を生むことが知られています。過去の事例（RC4やWEP、GSMのA5/1など）は、暗号アルゴリズム選定とnonce管理、認証の重要性を示しています。現代ではChaCha20-Poly1305のようなAEAD構成が実用的かつ安全な選択肢として推奨されており、ストリーム暗号を扱う際は「よく解析された標準」「厳密なnonce政策」「認証の併用」「安全な実装」を守ることが必須です。
参考文献
- RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols
- RFC 7465 — Prohibiting RC4 Cipher Suites
- Fluhrer, Mantin, and Shamir — Weaknesses in the Key Scheduling Algorithm of RC4 (2001)
- eSTREAM project — eCRYPT Stream Cipher Project
- Stream cipher — Wikipedia（概説）
- NIST Special Publication 800-38A（ブロック暗号運用に関する資料、参考）
- Handbook of Applied Cryptography（Menezes et al.）
投稿者プロフィール
