暗号技術の基礎

暗号技術は、機密性、完全性、ピア認証、否認防止などのセキュリティ目標に数学的 プリミティブを適用します。エンコーディング、鍵管理、乱数、状態、攻撃者の能力も 結果を決めるため、安全なプリミティブだけでプロトコルが安全になるわけではありません。

ビット、XOR、剰余算術 #

暗号仕様は正確なサイズのビット列とバイト列を扱います。排他的論理和は 2 を法とする 加算です。

XOR は結合的、交換的、自己逆元であるため、 (message XOR mask) XOR mask = message. これらの恒等式でストリーム暗号がキーストリームを適用・除去する方法を説明できます。 ただし安全性を意味しません。マスクを再利用すると平文間の関係が露呈します。

剰余算術は整数を合同類にまとめます。a ≡ b (mod n) は n が a - b を割り切る ことを意味します。加算と乗算はそれらの類の中にとどまります。整数 a が法 n に おける乗法逆元を持つのは gcd(a, n) = 1 の場合に限られ、拡張ユークリッド互除法で その逆元を求められます。

素数を法とすると、すべての非零要素が可逆な有限体が生成されます。その他の公開鍵 システムは、楕円曲線群を含む慎重に選択された有限群で動作します。実装は任意の整数 や点を有効な鍵として扱わず、選択した標準が定義する群、エンコーディング、検証、 部分群の規則を使わなければなりません。

確率とセキュリティパラメーター #

暗号の保証は確率的で、パラメーター化されています。秘密を 2^k 個の可能性から 一様にサンプリングすると、総当たり探索は平均して約 2^(k-1) 回の推測を要します。 理想的な n ビットハッシュは、原像には約 2^n の計算量を必要としますが、誕生日 限界により衝突には 2^(n/2) だけで済みます。

セキュリティパラメーターは、すべてのオブジェクトのビット数ではなく、想定する 計算量を示します。256 ビットの楕円曲線群は約 128 ビットの古典的安全性を目標に できますが、256 ビットハッシュは 256 ビットの原像耐性と 128 ビットの衝突耐性を 目標にします。アルゴリズム固有の攻撃、量子攻撃モデル、実装からの漏洩、弱い乱数 生成、鍵の寿命によって実効強度は低下します。したがってパラメーター選択はプロトコル 標準と現在の鍵管理ガイダンスに従わなければなりません。

Probabilities also govern failure limits. Authentication tags can be forged with some bounded probability, and nonce-based modes cap the number and total size of messages processed under one key. Systems must enforce those usage limits rather than assuming that a large key alone makes unlimited use safe.

ワンタイムパッドとストリーム暗号 #

For equal-length strings, a one-time pad computes:

ciphertext = plaintext XOR pad
plaintext  = ciphertext XOR pad

情報理論的秘匿性が成立するのは、パッドが一様乱数で秘密であり、平文以上の長さで、 全体または一部を決して再利用しない場合だけです。パッドを再利用すると ciphertext1 XOR ciphertext2 = plaintext1 XOR plaintext2, となり、どちらの平文も最初は未知であっても構造が漏れます。パッドを安全に生成、 配布、破棄することは、ほとんどのソフトウェアシステムでは構成を実用的でないものに します。

ストリーム暗号は真の乱数パッドを、短い秘密鍵と nonce から導出した擬似乱数キースト リームに置き換えます。nonce は通常公開されますが、一意性要件は必須です。1 つの ChaCha20-Poly1305 鍵で nonce を再利用すると、ChaCha20 キーストリームが繰り返され、 ワンタイム認証鍵も再利用されます。AES-GCM も nonce 再利用後は強い機密性と認証の 保証を失います。nonce を管理または検証するライブラリ API を使い、モードのメッセージ またはデータ制限に達する前に鍵をローテーションします。

認証付き暗号化と関連データ #

暗号化だけでは変更を検出できません。関連データ付き認証暗号化（AEAD）方式は、暗号文 と認証タグを返し、次を認証します。

• 機密性が維持される平文。
• 目に見えるままだが、気付かれずに変更できない関連データ。
• 方式が要求する nonce とアルゴリズム入力。

プロトコルバージョン、レコードシーケンス番号、テナント識別子、ルーティング フィールドなどのヘッダーは、中間者が読む必要がある場合に関連データにできます。 差異があるとタグ検証に失敗するため、両端はまったく同じ関連データをシリアライズ しなければなりません。

保守された暗号ライブラリを通じて、AES-GCM や ChaCha20-Poly1305 などの標準化された AEAD を使います。受信側は認証されていない平文を公開したり、それに基づいて動作 したりしてはなりません。タグ失敗は認証失敗です。再試行、ログ、エラーレスポンスは 部分的な平文を公開したり、有用な内部失敗状態を区別させたりしてはなりません。暗号文 に付加した鍵なしダイジェストではこの保護を提供できません。

ハッシュ、MAC、鍵導出 #

Related-looking primitives have distinct roles:

通常のハッシュはデータを認証できません。攻撃者がメッセージを置き換えると新しい ダイジェストを計算できるためです。HMAC は標準化された MAC 構成であり、 hash(key || message) に置き換えないでください。HKDF はまず入力鍵素材から固定長の 擬似乱数鍵を抽出し、コンテキスト固有の出力へ展開します。salt と info の入力は パスワードではなく、パスワードハッシュのアカウントごとのランダム salt とは異なる 目的を持ちます。

KDF context labels separate keys by protocol, version, direction, role, and purpose. For example, an encryption key and a MAC key must not be the same bytes merely because both came from one shared secret. Follow the enclosing protocol’s defined labels and encoding because ambiguous concatenation defeats that separation.

Asymmetric Key Establishment and Signatures #

Diffie-Hellman and elliptic-curve Diffie-Hellman let two parties derive a shared secret across an observable channel. Bare Diffie-Hellman does not authenticate either party: an active attacker can negotiate one secret with each endpoint. A complete protocol binds the exchange transcript to certificates, pre-shared keys, or previously authenticated public keys, then derives traffic keys with a KDF.

A key encapsulation mechanism (KEM) produces a shared secret and an encapsulation for a recipient’s public key. Protocols may combine independently secure components during a cryptographic migration, but the combination and its KDF must come from a reviewed protocol specification. Public-key encryption is not interchangeable with key agreement or a KEM.

Digital signatures bind a private signing operation to a message and allow verification with the public key. Algorithms such as Ed25519, ECDSA, and RSA-PSS define message formatting, hashing, randomness or deterministic nonce generation, and verification rules. A signature is not “encryption with the private key,” and signature verification does not make an untrusted public key authentic.

Start with a Threat Model #

Select primitives only after stating the security boundary:

1. Identify protected assets and whether confidentiality, integrity, peer authentication, replay resistance, or forward secrecy is required.
2. Identify attacker capabilities, including observation, active modification, chosen inputs, endpoint compromise, side channels, rollback, and denial of service.
3. Define trust anchors, key ownership, key rotation, compromise recovery, and authenticated metadata.
4. Choose a standardized protocol and maintained implementation whose security properties match those requirements.

TLS can protect data in transit while leaving compromised endpoints, authorization errors, and application-level replay outside its boundary. Signatures can prove that a key authorized a message while saying nothing about whether that key should be trusted. Explicit boundaries prevent one property from being mistaken for another.

OpenSSH randomart illustrates the same distinction. It is a visual rendering of a public-key fingerprint, not an authenticated identity proof. Compare the full fingerprint over a separately authenticated channel.

References #

• NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management
• NIST SP 800-38D: Galois/Counter Mode
• RFC 8439: ChaCha20 and Poly1305 for IETF Protocols
• RFC 5869: HMAC-Based Extract-and-Expand Key Derivation Function
• RFC 7748: Elliptic Curves for Security
• RFC 8032: Edwards-Curve Digital Signature Algorithm