パディングの全体像と実務ガイド：CSS・暗号・ハッシュ・アラインメントを網羅解説
エバープレイ編集部はじめに — 「パディング」とは何か
「パディング（padding）」は、IT・コンピュータ分野で広く使われる用語で、文脈により意味が変わります。一般的には「余白」や「埋め草」の意味合いで、データや表示の境界を揃えるために付加されるものを指します。本稿では主に以下の主要な文脈について、原理・用途・注意点・代表的な方式を詳しく解説します。
- ユーザーインターフェース（CSS）のパディング
- 暗号（ブロック暗号・公開鍵）のパディング
- ハッシュ関数におけるパディング（メッセージパディング）
- メモリ構造（構造体のアラインメントとパディング）
1. CSS（ボックスモデル）のパディング
WebやUI設計で最も目にする「パディング」はCSSのbox modelにおける内側の余白です。要素のコンテント（文字や画像）とボーダーの間にあるスペースを指します。主な特徴は以下の通りです。
- プロパティ: padding, padding-top, padding-right, padding-bottom, padding-left。ショートハンドとして「padding: top right bottom left;」が使えます。
- サイズへの影響: box-sizing: content-box（デフォルト）ではpaddingは要素の外寸に加算されます。box-sizing: border-boxではパディングが要素の幅・高さに内包される扱いになります。
- 背景描画: 要素の背景（background-color / background-image）はpadding領域まで描画されます（background-clip により挙動を制御可能）。
- 割合指定: padding を % で指定した場合、その基準は親要素の幅（横幅）です（height ではない点に注意）。
- 負の値は不可: padding は負値を取れません（CSS仕様）。
設計実務では、デザインシステムのスペーシングトークン（例：8px間隔）やレスポンシブ時の相対単位（rem や vw）で一貫性を保つことが重要です。
2. 暗号におけるパディング（対称鍵・公開鍵）
ブロック暗号や公開鍵暗号では、ブロック長や数理的要件の都合でメッセージ長が（アルゴリズムが要求する）決まった単位の倍数にならないことがあります。そこで「パディング」を付加して長さを揃え、安全に復号・検証できるようにします。ここでは代表的な方式と注意点を解説します。
2.1 ブロック暗号のパディング（例: AES-CBC）
- PKCS#7（広く使われる）: ブロック長 n バイトに対し、k バイトのパディングを追加（1 ≤ k ≤ n）。各パディングバイトの値は k。復号時に最後のバイト値を見てパディング長を判定する。PKCS#5 は PKCS#7 のうちブロック長 8 の場合の名称。
- ANSI X9.23: 最後のバイトにパディング長を書き、前のバイトはゼロ（乱数を使う変種もある）。
- ISO/IEC 9797-1 Padding Method 2: 0x80 を先頭に置き、残りを 0x00 で埋める方式（可逆でわかりやすい）。
注意点: 復号時にパディングの検証を別段階で行う実装（例：エラーメッセージや処理時間で違いが出る）をすると「パディングオラクル攻撃（Vaudenay 2002）」により平文が漏洩する危険があります。そのため、現在は「暗号化の順序」や「AEAD（例: AES-GCM）」の利用、または encrypt-then-MAC を推奨します。
2.2 公開鍵暗号のパディング（RSA等）
RSAのような公開鍵暗号では、数論的手続きに対する安全性のため専用のパディング方式が用いられます。固定のフォーマットやランダム性を導入して、同型性やリプレイ、選択暗号文攻撃を抑制します。
- PKCS#1 v1.5: 歴史的に広く使われたが、実装次第で「パディングオラクル」に弱い場合があった（Bleichenbacher攻撃）。
- OAEP（Optimal Asymmetric Encryption Padding）: MGF1 等のマスク生成関数を使い、乱数とハッシュでメッセージをマスクする方式。現代の推奨方式の一つ（PKCS#1 RFC 8017 に記載）。
3. ハッシュ関数におけるパディング（メッセージダイジェスト）
ハッシュ関数（例: SHA-1/256/512）は内部構造（Merkle–Damgård 構造等）がブロック処理を前提にしているため、メッセージを正しく扱うためにパディングを行います。一般的な手順は次の通りです。
- メッセージの末尾に 0x80（1 ビットの 1 と続く 0）を追加
- 必要なだけ 0 を追加してブロック長の直前まで埋める
- 元のメッセージ長（ビット長）を固定長（例：64 ビットまたは128 ビット）で付加する
この方式により、異なる長さのメッセージが衝突するパディングを避け、長さ拡張攻撃の発生を設計上考慮することになります（HMAC はこの問題を回避する設計になっています）。詳細は各ハッシュ仕様（FIPS 180-4 など）を参照してください。
4. メモリおよび構造体のパディング（アラインメント）
低レイヤ（C/C++など）のプログラミングでは「構造体パディング」が問題になります。コンパイラはパフォーマンスとアライメント制約のために構造体メンバー間や末尾にパディングバイトを挿入します。
- 目的: CPU のアラインメント要件に合わせて読み書きを高速化するため
- 結果: sizeof(struct) が各メンバーの合計より大きくなる。ネットワークプロトコルやファイルフォーマットでは明示的なパッキング（#pragma pack 等）やエンコード/デコードルーチンが必要。
- セキュリティ上の注意: パディング領域が未初期化のまま送信・ログ出力されると機密データをリークする可能性があるため、構造体を外部に渡す前はゼロクリア（memset）することが推奨される。
5. 実務上の注意点とよくある落とし穴
パディングは便利ですが、実装や運用におけるミスが大きな問題を招きます。代表的な注意点を挙げます。
- 暗号: パディング検証のエラー情報を詳細に返すとパディングオラクル攻撃を助ける。エラーは一般化し、タイミング差も抑えるべき。
- 互換性: 暗号やハッシュで使用するパディング方式が異なると互換性が取れない。プロトコル仕様で方式を明確化する。
- Web/CSS: padding% が横幅基準である点や box-sizing の違いがレイアウト崩れの原因になる。
- メモリ: 構造体のパディングバイトは必ず初期化する。サニタイザ（Valgrind, ASan）を活用する。
6. よく使われる回避策・推奨実装
- UI: 設計システムと変数（CSSカスタムプロパティ）で一貫したスペーシングを管理する。
- 暗号: AEAD（Authenticated Encryption with Associated Data、例: AES-GCM、ChaCha20-Poly1305）を優先利用し、パディングに起因する脆弱性を避ける。
- 公開鍵: RSA では OAEP を利用、古い PKCS#1 v1.5 は注意して使用する。
- 構造体: 外部インターフェースでは明示的にエンコード/デコードを行い、構造体の生メモリをそのまま送らない。
まとめ
「パディング」は一見単純な「余白」ですが、文脈により役割や重要性が大きく異なります。Webデザインでは見た目とレイアウトの安定を、暗号分野ではセキュリティと互換性を、低レイヤではパフォーマンスと安全性を左右します。用途に応じた正しい方式の選択と実装上の注意（初期化、エラー情報の扱い、仕様の明示）が不可欠です。
参考文献
- MDN Web Docs — padding (MDN)
- W3C — CSS 2.1: The box model
- RFC 8017 — PKCS #1: RSA Cryptography Specifications (OAEP 等を含む)
- RFC 5652 — CMS (PKCS#7)（PKCS#7/PKCS#5 の仕様参照）
- Daniel Bleichenbacher — Chosen Ciphertext Attacks on RSA (Bleichenbacher)
- Serge Vaudenay — Security Flaws Induced by CBC Padding
- POODLE (CVE-2014-3566) と SSLv3 の脆弱性 — CERT/CC
- AlFardan & Paterson — Lucky Thirteen (TLS padding/timing)
- FIPS PUB 180-4 — Secure Hash Standard (SHA)（ハッシュのパディング規定）
- CERT Secure Coding — Initialize objects before use（構造体の初期化に関する注意）
