開発者ツール・UUID ジェネレーター
crypto.getRandomValues が 16 のランダムなバイトを v4 UUID に変換する方法
· 仕組み
uuid 暗号化 ブラウザAPI
バージョン 4 の UUID は、6 ビットが上書きされた、暗号的に安全なジェネレーターからの 16 bytes です。この投稿では、Web Crypto 呼び出しからよく知られた 36 文字の文字列までのバイトをたどります。
サーバーが応答する前に必要な ID — オフラインファーストフォーム、オプティミスティック UI、バッチインポートでクライアント側の生成が行われる理由
オフライン フォームでは、サーバーが応答する前に識別子が必要になる場合があり、楽観的な UI では複数のオブジェクトが一度に作成される場合があります。 UUIDv4 は、中央カウンターなしで独立して生成されるように設計されています。これは、ユーザー ID の証明や、認証の代わりに安全に使用できる秘密ではありません。データベースに作成時間で並べ替える値が必要な場合、ランダムな v4 ID は順序付けされません。これは、ランダム性を弱める理由ではなく、別のスキーマの決定です。
crypto.getRandomValues が実際に行うこと — JavaScript の数式からではなく、オペレーティング システムのエントロピー ソースから型付き配列を埋める
crypto.getRandomValues は、ブラウザ プラットフォームの暗号的に安全なランダム ジェネレーターからの 16 bytes を Uint8Array に書き込みます。 Date.now() または Math.random() から値を導出するわけではありません。オペレーティング システムとブラウザーは基礎となるエントロピー ソースを実装するため、JavaScript コードは乱数式自体を実装するのではなく、バイトを受け取ります。 ToolAcre は、安全なソースが存在しない場合、識別子の生成を拒否します。
バイト 6 とバイト 8 の上書き — バージョン ニブルが 4 になり、バリアント ビットが 10xx になる仕組みと、なぜ 6 ビットだけが失われるのか
RFC 9562 では、バージョン ニブルとバリアント フィールドについて説明しています。 16 個のランダム バイトから始めて、バイト 6 の上位 4 ビットをバイナリ 0100 (バージョン 4) に設定し、バイト 8 の上位 2 ビットを 10 (標準バリアント) に設定します。実装では (byte6 & 0x0f) | を使用します。 0x40 と (byte8 & 0x3f) | 0x80。 6 ビットが上書きされ、UUIDv4 スキームでは 122 のランダム ビットが残ります。これらの定数ビットによって、残りのバイトのランダム性が低下することはありません。
バイトから 8-4-4-4-12 — 標準で定義されている 16 進エンコード、小文字出力、およびハイフンの配置
各バイトを、必要に応じて先頭にゼロを付けた 2 つの 16 進文字としてエンコードします。 4、6、8 および 10 bytes の後にダッシュを挿入すると、おなじみの 8-4-4-4-12 の 16 進文字グループが生成されます。有効な v4 文字列の 3 番目のグループの先頭には 4 があり、4 番目のグループの先頭には 8、9、a、または b のいずれかが含まれます。書式設定によってエントロピーは追加されません。基礎となる 128 ビット値を、UUID テキスト形式を期待するツールと相互運用できるようにするだけです。
動作した例 - マスキングとフォーマットを通じて最終的な UUID 文字列までトレースされた 16 バイトのバッファ
例示的なバイト 00 11 22 33 44 55 F6 77 38 99 AA BB CC DD EE FF をトレースします。バイト 6 で F6 をマスキングすると 46 が生成されます。バイト 8 で 38 をマスキングすると B8 が生成されます。小文字の 16 進形式とダッシュを適用すると、結果は 00112233-4455-4677-b899-aabbccddeeff になります。これは意図的に固定された教育例であり、運用環境で再利用するための識別子ではありません。実際のオブジェクトごとに新しいものを生成し、バージョンとバリアントの位置を自分で比較します。
crypto.randomUUID() を 1 回の呼び出しでショートカットできる - 新しいメソッドの機能と使用できない場所
安全なオリジンでは、crypto.randomUUID() は 1 回の呼び出しで v4 の生成とフォーマットを実行します。 ToolAcre は、利用可能な場合はこれを使用し、それ以外の場合は、上記の明示的なビット操作を使用して getRandomValues にフォールバックします。ブラウザの可用性はコンテキストによって異なります。randomUUID は安全なコンテキストに制限されていますが、getRandomValues は HTTP LAN ページにまだ存在している可能性があります。どちらのブランチも、ボタンを見かけ上機能し続けるためだけに Math.random にフォールバックするわけではありません。
これでカバーされないもの — 時間ベース (v1、v7) および名前ベース (v3、v5) バージョン。ランダム バイトとは異なる入力が必要です。
このメカニズムでは、時間ベースの v1 または v7 識別子、名前ベースの v3/v5 識別子、または実験的な v8 レイアウトについては説明しません。ランダム UUID は、数学的に衝突が絶対に不可能ではなく、健全なランダム性により衝突確率が非常に低くなります。機密性、有効期間、認可を個別に考慮せずに、v4 UUID を単独でアクセス制御チェックまたはパスワード リセット トークンとして使用しないでください。
要点: 安全なランダム性がすべての仕事です。ToolAcre UUID ジェネレーターは同じブラウザー CSPRNG から描画するため、コピーしたものがコードで生成されるものになります。
安全なランダム性が仕事です。 ToolAcre UUID ジェネレーターはブラウザーの CSPRNG を使用し、バージョンとバリアント ビットを強制し、コピーされた値の整形式チェックを提供します。生成された結果をバイト レイアウトの例と比較し、アプリケーションが実際に割り当てたロールにのみ新しい一意の出力を使用します。