UUID v3/v5 Generator 解説書

RFC 9562 準拠の名前ベース識別子生成と検証の技術詳解

1. ツールの概要

本ツールは、名前ベースの UUID (Universally Unique Identifier) であるバージョン 3 (MD5) およびバージョン 5 (SHA-1) の生成プロセスを可視化し、 標準的なライブラリ実装 (`uuid.js`) とネイティブなアルゴリズム実装の整合性を検証するための技術検証用アプリケーションです。

注意: 本ツールは教育および検証を目的としています。セキュリティ上、名前ベースの UUID を機密性の高い用途に使用する場合は、MD5 (v3) よりも SHA-1 (v5) 以降の使用が推奨されます。

2. 名前ベース UUID の原理

名前ベースの UUID は、ある「名前空間 (Namespace)」内の「名前 (Name)」に対して決定論的なハッシュを適用することで生成されます。 生成式は概念的に以下のように定義されます:

$UUID = \text{SetVersionAndVariant}(\text{Hash}(\text{NamespaceID} || \text{Name}))$
  • NamespaceID: 16バイトのバイナリ表現。
  • ||: バイト列の連結。
  • Hash: v3 の場合は MD5、v5 の場合は SHA-1。
  • SetVersionAndVariant: ハッシュの先頭16バイトを抽出し、RFC 規定のビット操作を行う。

3. バイトオーダーと Base64

RFC 4122 および RFC 9562 において、UUID のバイナリ形式は ネットワークバイトオーダー(ビッグエンディアン) で定義されています。

3.1 ネットワークバイトオーダーの意義

UUID を 128 ビットの単一整数として解釈する場合、最上位バイト (MSB) が最初に格納されます。 本ツールで出力される Base64 エンコーディング結果は、この 16 バイトのバイナリ配列をそのまま btoa() 等で変換したものです。

3.2 エンディアン変換の落とし穴

リトルエンディアン環境(x86 等)のメモリ上で UUID フィールドを構造体として扱う際、一部のシステム(Microsoft GUID 等)では time_low, time_mid 等のフィールドをリトルエンディアンでメモリ保持するため、Base64 化する際にバイト順が入れ替わるミスが発生しがちです。 本ツールでは、常に RFC 準拠のビッグエンディアン順での Base64 出力を提供します。

4. 実装の技術的詳細

4.1 バージョンとバリアントの書き換え

ハッシュ計算後、以下のビット操作が適用されます:

  • Version (4ビット): 7番目のオクテットの上位4ビットを 3 または 5 に固定。
  • Variant (2ビット): 9番目のオクテットの上位2ビットを 10 (バイナリ) に固定。これにより RFC 4122 準拠を示します。

4.2 MD5 (v3) の独自実装について

モダンブラウザの crypto.subtle は MD5 をサポートしていません。 本ツールの「Native モード」では、JavaScript のビット演算(>>>, <<, |)を用いて符号なし 32 ビット演算をシミュレートし、 バイト配列を直接処理する RFC 1321 互換の MD5 ロジックを実装しています。これにより、外部ライブラリと全く同一のハッシュ結果を得ることに成功しています。

5. RFC 9562 テストベクタ

「LOAD RFC VECTOR」機能では、RFC 9562 で定義された最新のテスト用データを使用して動作を検証できます。

Version Namespace (DNS) Name Expected UUID
v3 6ba7b810... www.example.com 5df41881-3aed-3515-88a7-2f4a814cf09e
v5 6ba7b810... www.example.com 2ed6657d-e927-568b-95e1-2665a8aea6a2