【実務・中級編】Fiberを用いた暗号処理の並行化とサイドチャネル攻撃への耐性設計 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

Fiberと暗号処理の深層：Argon2id並行化の罠とサイドチャネル耐性設計

PHP 8.1で導入された`Fiber`（ファイバー）は、我々に「協調的マルチタスク（Cooperative Multitasking）」という強力なプリミティブをもたらした。`async/await`のような構文糖衣こそ標準ではないが、イベントループと組み合わせることで、I/Oバウンドなタスクにおけるスループットを劇的に改善できる。

だが、ここで一度立ち止まってエンジニアリングの根底を問いたい。
「CPUバウンド、かつ極めて重い暗号学的ハッシュ計算（例：Argon2id）を、Fiberで並行化すればパフォーマンスが上がるのか？」

ネット上の浅薄な解説記事では「Fiberを使えばノンブロッキングで処理できる」と誤解されがちだが、Zend VMの挙動とCPUの物理的制約を無視した設計は、システムを破滅へと導く。今回は、PHPの内部エンジンにおけるFiberのコンテキストスイッチの限界と、暗号処理における「サイドチャネル攻撃（タイミング攻撃）」の脅威を踏まえ、実務で通用する堅牢な非同期暗号処理アーキテクチャを解説する。

—

1. Zend VMとFiberの内部挙動：なぜCPUバウンド処理で誤ったFiberを使うのか？

まず、PHPの実行モデルを低レイヤから整理する。
PHPのプロセス（PHP-FPMのワーカーなど）は、シングルスレッドで動作する。Zend VMはオペコードを順番に実行し、コールスタック（`zend_execute_data`）を積み上げていく。

Fiberの本質は、「ユーザーランドで管理される独立したコールスタックの切り替え」にすぎない。OSスレッドを増やすわけでもなければ、CPUコアを並列に使うわけでもない（PHPにおける真の並列処理は `ext-parallel` などの領域だ）。

[Main Stack] —> (Fiber::suspend)
|
v
[Fiber Stack] (ここで重いArgon2idを実行)
|
v
(Fiber::resume) —> [Main Stackに戻る]

もし、`Argon2id` のようなCPUキャッシュを大量に消費し、メモリハードなハッシュ計算をひとつのPHPプロセス内の複数Fiberで同時並行（擬似並行）させると何が起きるか？

1. CPUキャッシュの競合（Cache Thrashing）: Argon2idはサイドチャネル耐性とブルートフォース耐性を高めるためにあえて大容量のメモリをランダムアクセスする。複数Fiberがこれを同時に処理すると、L1/L2/L3キャッシュミスが多発し、かえってスループットが低下する。
2. イベントループのブロック: Fiberは「協調的」である。もし、イベントループ自体が単一のプロセス内でノンブロッキングI/Oを捌いている最中に、CPUを強烈に占有する処理をFiber内で実行し続けたらどうなるか？ `Fiber::suspend()` が呼ばれるまでの間、そのプロセスは完全にフリーズし、他のリクエストやイベントがブロックされる。

したがって、PHPでFiberを使って暗号処理を扱う場合の鉄則は、「重い暗号処理そのものをPHPのメインプロセスやイベントループスレッド内でゴリゴリ回さないこと」、あるいは「CPUコアの物理的な限界とコンテキストスイッチのコストを厳密に制御すること」である。

—

2. サイドチャネル攻撃（タイミング攻撃）の脅威とPHPの罠

パスワード検証や暗号学的比較において、最も恐ろしいのは「処理時間の差から秘密情報を暴かれるタイミング攻撃」だ。

例えば、文字列の比較に通常の `===` 演算子や `strcmp()` を使うと、先頭の文字が一致した時点で比較処理が早期リターン（Early Return）するため、一致しているバイト数に応じて処理時間が微妙に変化する。攻撃者はこのミリ秒単位の差を統計的に分析し、ハッシュやトークンを復元する。

PHPには `hash_equals()` というタイミング攻撃耐性を持つ関数が用意されているが、暗号学的ハッシュの生成（ hashing ）そのものにかかる時間は、入力値の長さやストレッチングのパラメータによって変動しうる。特に、複数ユーザーの認証リクエストをFiberで非同期に受け付け、イベントループ上で順次処理していく過程で、メモリの割り当てタイミングやガベージコレクション（GC）の発生タイミングが攻撃者に観測可能な「サイドチャネル」となり得るのだ。

—

3. 実務仕様：Fiberプールと安全な暗号処理コントローラーの実装

ここからは、実務のAPIサーバーやバッチ処理基盤を想定し、「過剰なCPU占有を防ぎつつ、Fiberを用いて複数の暗号化タスクを安全に調停・実行する」ためのリファレンスコードを提示する。

このコードでは、以下の設計要件を満たしている。

同時実行数（Concurrency）の制限: 無制限にFiberを立ち上げず、CPUコア数やメモリに応じたプール制約をかける。
タイミング攻撃への配慮: パスワード検証には `hash_equals` を強制し、定数時間比較を行う。
ノンブロッキングなシミュレーション: イベントループの概念を模したキューイング機構により、I/O待ちとCPUバウンドタスクを安全に分離する。

堅牢な非同期暗号処理マネージャー（Fiberベースの協調的タスク調停）

@author Lead Chief Architect

/
final class AsyncCryptoDispatcher
{
private int $maxConcurrentFibers;
private int $activeFibers = 0;
/ @var array /
private array $taskQueue = [];

public function __construct(int $maxConcurrentFibers = 4)
{
$this->maxConcurrentFibers = $maxConcurrentFibers;
}

Argon2idによるハッシュ生成タスクをキューに登録する

/
public function queueHashPassword(string $password, callable $onSuccess, callable $onError): void
{
$this->taskQueue[] = function () use ($password, $onSuccess, $onError) {
try {
// Argon2idのパラメータはセキュリティ要件とCPU負荷のバランスを厳密に調整
$options = [
‘memory_cost’ => PASSWORD_ARGON2_DEFAULT_MEMORY_COST,
‘time_cost’ => PASSWORD_ARGON2_DEFAULT_TIME_COST,
‘threads’ => 1, // 単一Fiber内ではスレッドを競合させないため1に固定
];

// PHP内部のC実装（ext-sodium /standard hash API）を呼び出し
$hash = password_hash($password, PASSWORD_ARGON2ID, $options);

if ($hash === false) {
throw new RuntimeException(‘Argon2idハッシュの生成に失敗しました。’);
}

$onSuccess($hash);
} catch (\Throwable $e) {
$onError($e);
}
};
}

キューに溜まったタスクをFiberの並行制限を守りながら実行する

/
public function run(): void
{
while (!empty($this->taskQueue) || $this->activeFibers > 0) {
// 同時実行枠に空きがあり、キューにタスクがある間、Fiberを生成して起動
while ($this->activeFibers < $this->maxConcurrentFibers && !empty($this->taskQueue)) {
$task = array_shift($this->taskQueue);

$fiber = new Fiber(function () use ($task) {
// 処理開始前にコンテキストを一度サスペンドしてイベントループに制御を返す（協調的動作の模範）
Fiber::suspend();

// 重い暗号処理の実行
$task();
});

// Fiberを開始
$fiber->start();

// すぐにサスペンド状態から再開（resume）させて処理を進める
if ($fiber->isSuspended()) {
$fiber->resume();
}

$this->activeFibers++;

// 簡易的なライフサイクル管理のためにファイバー終了検知を紐付ける
// 実運用ではここでイベントループ（ReactPHPやAmpなど）のループに組み込む
$this->activeFibers = max(0, $this->activeFibers – 1);
}

// CPUのスパイクを防ぐための微小なインタバル（実際のイベントループではepoll/kqueue等のI/O待ちになる）
usleep(1000);
}
}

サイドチャネル攻撃（タイミング攻撃）を防ぐ安全なパスワード検証
@param string $inputPassword ユーザーから送られた平文パスワード
@param string $storedHash データベースから取得した既存のハッシュ

/
public static class VerifyPasswordSafe
{
public static function verify(string $inputPassword, string $storedHash): bool
{
// password_verify内部でもタイミング攻撃対策は行われているが、
// 事前検証や独自トークンの比較を行う場合は必ず hash_equals を使用すること。
// 早期リターンによる情報漏洩を完全に防ぐ。
$isValid = password_verify($inputPassword, $storedHash);

// ダミーのハッシュ比較を挟むことで、パスワードが存在しない場合の処理時間差を隠蔽する（高度なサイドチャネル対策）
if (!$isValid) {
// 意図的に定数時間かかるダミー処理を実行し、タイミングの差異を均す
password_verify(‘dummy_password_for_timing_mitigation’, $storedHash);
}

return $isValid;
}
}
}

// ==========================================
// 実行例（Usage）
// ==========================================
$dispatcher = new AsyncCryptoDispatcher(maxConcurrentFibers: 2);

$dispatcher->queueHashPassword(
‘SuperSecretPassword123!’,
onSuccess: static fn(string $hash) => print(“ハッシュ生成成功: {$hash}\n”),
onError: static fn(\Throwable $e) => print(“エラー: {$e->getMessage()}\n”)
);

$dispatcher->queueHashPassword(
‘AnotherSecurePassword456!’,
onSuccess: static fn(string $hash) => print(“ハッシュ生成成功: {$hash}\n”),
onError: static fn(\Throwable $e) => print(“エラー: {$e->getMessage()}\n”)
);

// ディスパッチ実行
$dispatcher->run();

—

4. コードレビューの視点：なぜこの設計が「実務に耐えうる」のか？

上記のコードとアーキテクチャ設計には、プロダクション環境でエンジニアが陥りがちな罠を防ぐための厳格な意図が込められている。コードレビューで指摘されるべきポイントを解説する。

① `threads => 1` の強制

Argon2idのオプションでマルチスレッド（内部のスレッドプール）を有効にすると、PHPの1プロセス内でFiberが勝手にOSスレッドを乱立させ、コンテキストスイッチのオーバーヘッドが爆発する。PHPのFiberは「シングルスレッド上の協調動作」であるため、暗号処理側の内部並列度を1に絞り、タスク単位の並行制御（Fiberプール）と綺麗に直交させることがパフォーマンスチューニングの鉄則である。

② タイミング攻撃への二重の防衛（ダミー処理の活用）

パスワード検証において、ユーザーが存在しない場合（`password_verify` が早期に失敗する場合）と、ユーザーが存在してハッシュ計算まで走った場合では、わずかな時間差が生じる。極めてセキュアな認証基盤では、この「ユーザー存在有無による時間差」すらも攻撃の糸口にされる。リファレンスコードで示したように、失敗時にあえてダミーの `password_verify` を走らせて処理時間を均すアプローチは、金融機関や高度なSaaSのセキュリティ要件において実際に採用される実践的知見である。

③ メモリリークとGC（ガベージコレクション）の制御

Fiber内で巨大な文字列やバイナリデータを扱う際、スコープの抜け方にミスがあるとZend VMの変数テーブル（`HashTable`）やリクエストメモリプールにゴミが残留し、ロングランプロセス（RoadRunnerやFrankenPHPなど）で致命的なメモリリークを引き起こす。タスクが完了したクロージャ内では、不要になった平文パスワードの文字列変数を `unset()` するなどして、メモリ上の生存期間を最小限に抑える配慮が必要だ。

—

5. アーキテクトからの最終提言

Fiberは万能の魔法の杖ではない。それを理解せずにCPUバウンドな暗号処理を闇雲に非同期化すれば、コードの複雑性が増すだけで、恩恵を受けるどころかパフォーマンスを悪化させる。

しかし、「I/O非同期処理のイベントループ」と「適切にプーリングされたCPUタスク（あるいは別ワーカーへのオフロード）」を美しく組み合わせた設計を行えば、PHPはモダンで堅牢な高スループット・高セキュリティーなAPIバックエンドへと変貌する。

フレームワークが隠蔽したブラックボックスの向こう側、Zend VMのメモリ空間とCPUの挙動に思いを馳せながらコードを書くこと。それこそが、真に信頼されるシニアエンジニアの矜持である。