なんとなくUUIDって聞くと「全部ただのランダムな識別子」みたいに思ってたんだけど、実は違うんだなーって最近知ったんだよね💡
しかも、データベースのなかで使うUUIDと外に出すUUIDをわざわざ変えちゃう仕組みがあるって話を見つけて、ちょっとびっくり😳✨
UUIDv7とUUIDv4って何が違うの？
ざっくり言うと、
- UUIDv7は「タイムスタンプ＋ランダム」の組み合わせで、時間順に並べられるからデータベースの検索に便利
- UUIDv4は完全にランダムなUUIDで、時間の情報は隠れてる感じ
だから普通は、データベースの中でも外でもどっちかを使うんだけど…
そこで登場！UUIDv47のアイデア
この人（作者さん）が考えたのは、データベース内ではちゃんと時系列でソートできるUUIDv7を使いつつ、外には「見た目はUUIDv4」だけど、内部のタイムスタンプは隠したものを出す方法なんだって💭
つまり、「外に見せるUUIDは時間の順番バレないようにマスクしてる」ってこと✨
使ってる魔法みたいなものは「SipHash（シップハッシュ）」という暗号関数を使ってて、
48ビットのタイムスタンプ部分をキー付きのSipHashでXORマスクすることで変身させてるんだって🧠🔧
これのおかげで、時間情報を隠しつつも、元に戻すのは超カンタンってわけ！
セキュリティとかパフォーマンスはどう？
SipHashって速いし秘密鍵がないとタイムスタンプは読み取れないから、
外に出すUUIDからタイミングパターンはバレにくいし、鍵が漏れなきゃ安全らしいよ👍
しかも処理はめちゃ軽いみたいで、実際にAppleのM1チップで計測したら、
encode＋decodeで33ナノ秒くらいしかかからないっていう速さ。秒間3000万回以上の処理がサクッとできる感じ🥺🌸
まとめると…
- データベースには時間順に並べられるUUIDv7をガッチリ使う
- 外には見た目はランダムなUUIDv4をマスクしたものを出すから、時間情報バレない
- SipHashという暗号処理で安全かつ高速に変換できる
- 鍵は1つあればいいし、性能の負担もほぼゼロ
これって、「データベースの効率」と「外部に時間情報をリークしない工夫」のいいとこ取りみたいな感じで、なかなか賢いなあと思ったよ💭✨
なんかUUIDの世界も奥が深いなーって気づいたお話でした🥰💬
はてな
コメント
クリス
これは一対一の関数で、created_atを隠す必要があるかはわからないけど、それにはいい方法だと思います。 UUIDv7をDBに保存してホットパーティションを避けたい時にも使えるけど、単純にUUIDを逆にするだけでもいいかもね。
エイダン
これ好き！ 否定的な意見も多いけど、こういうのは確実に役立つよ。 自分も似たように連番を難読化して8文字の英数字に変換する方法を考えたことがあるから共感できる。
ロバート
最初は半信半疑だったけど、読んでみて結構いいアイデアだと思った。 大規模システムでの実用性はわからないけどね。
グレース
実は大手も似たようなことやってるよ。 Googleみたいに見えるIDは本物じゃなくて外部用の偽IDだったりする。
ハンナ
じゃあミドルウェアでDBから出る全てのキーを変換し直す必要があるってこと？ だったら素直にIDカラム使って、こういうの（https://sqids.org）で難読化したほうが楽かも。
キンバリー
こんな方法より、UUIDv4を別カラムで保存した方がいいのはどんな時？ 作成時間がわかれば鍵を逆算できたりするのかな？
リリー
攻撃者がシステムにuuidv7の新規作成をさせられるなら鍵のほとんどを抜き取るのは簡単で、全部抜くのも可能っぽい。 面白いトリックだけど、性能アップが意味あるかもわからないし、セキュリティ向上も怪しい。
ロバート
すごくいいね。 UUIDv7が見えるとユーザーの取引時間がバレて追跡されるから、銀行取引とかなら他の出来事と紐づけられるリスクがあるよ。
サム
なんでスラッグの方がダメなの？
ベン
UUIDv7を公開するときはどんな点に気をつけるべき？ 批判じゃなくて、使いどころを知りたいんだ。
ノーラン
DBインデックス最適化としては面白いけど、SipHash使ってるのがちょっと怖い。 暗号学的に安全とは言われてないからね。
ミア
このプロトコルはPRFに衝突耐性を求めてなくて、PRFはUUIDv4の下位ビットから作られてXORは高位ビットにだけかかる。 だからSipHashに衝突があっても変換自体は壊れないってのは良い点。
リリー
ただ、SipHashの事前画像耐性（逆算の難しさ）はわからない。 サーバーに特定時間のUUID作らせて推測し、正しい鍵を探せるかもしれない。
グレース
この話題で見つけた一番良い議論はここ（https://crypto.stackexchange.com/questions/17996/is-siphash-cryptographically-secure）だけど、これを見るとこの構成は弱いかもと思う。
クリス
セキュリティ面はわかるけど、自分ならわざわざこれを選ばずにクライアント用には別のユニークIDを作るかな。 鍵管理も面倒だし。
ワット
良いプロジェクトだけど、自分には合わないかな。
リリー
暗号化や鍵付きハッシュで公開IDを作るのは問題がある。 鍵を全サーバーで共有しなきゃいけないし、鍵が漏れたら使ったデータのセキュリティは永久に失われる。 再暗号化もできないしね。
レオ
パフォーマンスはほぼ影響なしと言われてるけど、ベンチマーク比較は見たいね。
