Updates on MLS on Ruby (and maybe more)

Transcript

1. Updates on MLS on Ruby (and maybe more) Ryo Kajiwara/ 梶原 龍 (sylph01) 2024/8/30 @ RubyKaigi 2025 Followup 1
2. だれ / なに 2
3. 松山に魂を取り残さ れた人向け情報(1) IYOTETSU ショップ秋葉原というアンテナ ショップがある。 キャッシュレス決済限定で、なんとみき ゃんアプリが使える。 冬になると柑橘がけっこう安く買える。 末広町の交差点からちょっと東。 3
4. 松山に魂を取り残さ れた人向け情報(2) IYOTETSU ショップ秋葉原からちょっと南 に行ったところに、えひめ飲料（ポンジ ュース作ってるところ）の東京営業本部 がある。実質愛媛県の飛び地 ほぼみかんジュースのみの自動販売機が ある。 4
5. 松山に魂を取り残さ れた人向け情報(3) 大街道に本店があるコーヒーショップの フライング・スコッツマンは秋葉原にも 店がある。実はここらへんまで愛媛県の 飛び地なのでは？ 分厚いホットケーキが有名。 5
6. 松山に魂を取り残さ れた人向け情報(4) 中目黒に愛媛のメシにフォーカスした居 酒屋の喜口屋がある。 オーガナイザーの打ち上げがここだっ た。県外であまり見かけない愛媛の地酒 を扱っている。オフィシャルパーティー で出した伊予賀儀屋も扱ってた。 6
8. これまでのあらすじ 8
9. Hybrid Public Key Encryption (HPKE; RFC 9180) 2023 年にやってた、RubyConf Taiwan 2023 でしゃべった https:/ /github.com/sylph01/hpke-rb 、 hpke gem としてリリースさ れている Messaging Layer Security などのビルディングブロック 9
10. hpke gem の更新 e083625 HPKE#aead_encrypt , HPKE#aead_decrypt をpublic にした 8558f68 (v0.3.1, 現行) OpenSSL の最低バージョンを設定 OpenSSL 3 系を前提に作っているので 10
11. hpke gem v1.0 化？ 動作実績を積み重ねられたと思うが、HPKE cipher suite のinstantiation の API を迷っている。 hpke = HPKE.new(:x25519, :sha256, :sha256, :aes_128_gcm) KEM のアルゴリズム( 最初の2 つ) は組み合わせが決まるのでRFC 9180 のAlgorithm Identifiers （をラッピングしてる定数）で直接指定 してしまっていいのでは？ そうすると残りもAlgorithm Identifiers で指定したい？ 決めの問題+ やるだけ。2025 中にやる。 11
13. Messaging Layer Security RubyKaigi 2025 のネタ RubyConf Taiwan 2025 でも説明を多少改善した版をしゃべった メッセージングのエンドツーエンド暗号化のためのプロトコル グループ鍵共有の仕組み 13
14. Melos https:/ /github.com/sylph01/melos 14
15. Messaging Layer Security Any% (with Major Skips) できた暁にはちゃんとどっかで日本語解説＋ハンズオンをやりたい。が今日は本編より時間ないので本編より更にRTA します 15
16. 欲しいセキュリティ性質 Forward Secrecy: 「暗号文を今集めておいてあとで解読すればいい や」ができたとして長期鍵に影響が出ないという性質 Post-Compromise Security: 過去に誰かの鍵が侵害されていたとして もグループ鍵が適切に更新されていれば今のメッセージには影響が ないという性質 RFC 9420, Section 16.6 16
17. 欲しいセキュリティ性質 RFC 9420, Section 16.6 17
18. 2 人の場合は簡単 # 両者とも共通の秘密から始めて chain_key[0] = "some common secret" # HMAC は「鍵付きハッシュ」 # n 周期目のメッセージの鍵はn 周期目のchain_key から作る message_key[n] = hmac_sha256(chain_key[n], 0x02) # n+1 周期目のchain key はn 周期目のchain key から # メッセージの鍵とは違うHMAC 鍵を使って作る chain_key[n+1] = hmac_sha256(chain_key[n], 0x01) Double Ratchet algorithm の "symmetric key ratchet" と呼ばれる部分。要するにハッシュをチェーンしてる。 18
19. じゃあ3+ 人の場合は？ 2 人の方法を拡張しようと思うと、 n-node の完全グラフの枝の数は O(n^2) いちいち全員と通信してグループ鍵の合意 してられない！ 19
20. そこでみんな大好き O(n) を O(log n) に変えてくれる データ構造 木(tree) を使います 動画のサムネでここ抜いてるのは天才だと思った 20
21. MLS の構成要素 RFC 9420 にこんな図があるけど正直わかりにくい。説明します 21
22. MLS の構成要素 ユーザーは ratchet_tree と secret_tree における 葉ノード(leaf node) に 割り当てられる。 22
23. 何をしたい？ グループの他のメンバーと、ある世代(epoch) n についての共通の秘密 epoch_secret[n] について合意したい。 23
24. Secret Tree epoch_secret[n] が合意できていれば、グループ全員分の鍵を導出で きる 24
25. Key Schedule epoch_secret[n] と commit_secret から次の epoch_secret[n+1] が作れる。なのでグループメンバーと commit_secret を合意する方法 があればよい。 25
26. TreeKEM その commit_secret を合意する方法。説明するには時間がどう考えて も足りない（本編でも足りなかった） 26
27. 忙しい人のためのTreeKEM commit_secret 自体を全員の公 開鍵に対して暗号化して送っても 動作はするが、メンバー数に対し て O(n) （→右図の偶数node 全部） commit_secret をツリーのcopath node に沿って最低限の数だけ暗号 化することによって暗号化の数が O(log n) で済む（→緑色node ） 27
28. 結局そのあと何をやった？ あんまりやれてない。 終わった 開発用に使ってた不要メソッドの削除 deserialization で用いるバッファをstring 2 つ→StringIO に変更 進行中 グループの状態をクラスにwrapping する クライアントインターフェース 私自身が松山に魂を取り残された哀れな人類だった 28
29. バッファのStringIO 化 以前は Melos::Struct::Base.new_and_rest(buf) がパースした結果と 残りの文字列の2 要素の配列を返す、という形でやっていた。 結果 Melos::Struct::Base.new(buf) は「残りの文字列」を捨てるよ うにしかできなかった。そうすると場所によって new と new_and_rest を呼び分ける必要があった。 あと不必要に大量の String を生成していた。 29
30. バッファのStringIO 化 C 言語でネットワークから得た値をデシリアライズするときはバッファ とポインタの組を使って、ポインタの位置を進めながら読んでいく。そ れのようなことができるのが StringIO 。 string.byteslice(0, n) → stream.read(n) など地道な書き換えを した。これを終えた状態が v0.0.2 。 最初のcommit が https:/ /github.com/sylph01/melos/commit/86f0bbd4a00a3903747f8d1bc9b2c65bd4637660 30
31. 進行中 グループの状態をクラスにwrapping test vector のテストにはグループの状態をベタ書きしているの でそれをまともな形で覆い隠したい 31
32. クライアントインターフェース 鍵ペアの生成 グループにjoin する 0 人→1 人の場合は自身の鍵ペアをtree に登録してepoch 0 を初 期化 n 人→n+1 人 (n>0) のときは KeyPackage を受け取りそこから鍵 を取り出してグループに追加、 Welcome メッセージを作る group ブランチ https:/ /github.com/sylph01/melos/commits/group でやってる 32
33. クライアントインターフェース メッセージを作る FramedContent : application / proposal / commit を送信 者の情報と合わせてラッピングする AuthenticatedContent : FramedContentTBS + FramedContentAuthData を使って FramedContent を署名し たもの PublicMessage : AuthenticatedContent に membership_tag というMAC を付加したもの RFC 9420, Section 6 33
34. クライアントインターフェース 暗号化されたメッセージを作る FramedContent 、 AuthenticatedContent は同じ PrivateMessage : SenderData と PrivateMessageContent が暗号化されたもの。 PrivateMessageContent に AuthenticatedContent が含まれる 34
35. Claude がプルリク送ってきた https:/ /github.com/sylph01/melos/pull/1 「ミスった」ってコメントあるけどまあまあよくできてる というか私の（よくない）コーディングパターンをうまく模倣 できてる 35
36. Ruby にMLS があって明確に嬉しい点 irb がある。 今他に対応している言語はバイナリにコンパイルされる言語ばっかりな ので途中状態で止めることが難しい。新規に開発する上でこれほど強い 機能はないと思う。実装さえあれば。 36
37. 今後どうする IETF 124 (2025/11/1 〜7) までにある程度なんとかしたい メッセージが暗号化して送れて 基本的なメッセージについては他の実装と相互運用できること を確認したい 現実的には年内 37
39. その他 大統一暗号API 多少気持ちがある 先行事例: krypt (cf: RubyKaigi 2013 のトーク) がOpenSSL 非依存 な統一暗号ライブラリを目指そうとしてたらしい。調査する この時代だとCRuby とJRuby の間の統一を目指していたように 見える。私はOpenSSL とwasm (Web Crypto) とPico (Mbed TLS) の bridging を目指している 39
40. その他 OpenSSL gem そのもの OpenSSL に生えてるHPKE のAPI を使う版のHPKE: あんまり優先 度は高くない cipher suite 全体の情報を取るのがしんどく、プロトコルで 使うにはしんどそう Edwards Curve とそうでないEC の間に一貫性のあるAPI が欲しい OpenSSL に生えているわけではないのでOpenSSL gem でや るべきかという話はありそう PicoRuby: TCP server, etc... 40
41. いろいろフィードバックほしい MLS も大統一暗号API もHPKE もPicoRuby のネットワークも 近く出没する予定のイベント Kaigi on Rails (9 月) RubyWorld Conference (11 月) ...? もちろんオンラインでも 41
42. おまけ1: ローカルオーガナイザー業 来年の夏にJANOG が松山に来ます。 RubyKaigi と同じ会場 今年の松江で2500 人くらい（RubyKaigi より多い） 今年の懇親会が800 人くらいで「足りなかった」という声が … まさかの公園リターンズ？？？（来年のJANOG ホストにこんなんやっ たよという話はしてある） 42
43. おまけ2: DJ の出番 RubyMusicMixin 終わったあとも松山でいろいろやっています。 10/18( 土) 20:00 〜26:00 TBA あんまりハードじゃないダンスミュージックの新規イベント 私はProgressive House をシバきます 11/29( 土) 14:00 〜20:00 Rhythmic Rumble! (#R 乱) 音ゲー中心。メインで活動してるイベント 今回はポップンDJ （大嘘）の予定 どちらもnecco さん（Tw: @bar_necco ）にて。配信あります 43