Go標準の暗号ライブラリメンテナンス戦略

2025-01-18 Gopher's Gathering

Transcript

1. Go標準の暗号ライブラリ メンテナンス戦略 2025-01-18 Gopher's Gathering
2. ⾃⼰紹介 • 名前: uji • 神⼾市在住 • NOT A HOTEL 所属 • Gopher 6年⽣ • KOBE.go, Kyoto.go 運営 https://twitter.com/uji_rb
3. Kyoto.go KOBE.go
4. このセッションのゴール • Goの暗号ライブラリの開発背景や、 メンテナンス戦略を理解する • Goの暗号ライブラリの今後の動きを知り、 リリースノートの crypto パッケージの記述を 楽しめるようになる 暗号ライブラリのアルゴリズムや実装の話はしません
5. Goの暗号ライブラリ Goチームがサポートしている暗号ライブラリは2つ • 標準パッケージ crypto ◦ 他の標準ライブラリと同様、後⽅互換性を担保しながら保守される • golang.org/x/crypto ◦ 実験的な実装や、標準ライブラリへの取り込み候補の アルゴリズムがサポート ◦ 他の依存関係と同じようにインストールおよび更新が可能 どちらもGoで独⾃実装されている
6. なぜGoで独自実装している？ 暗号技術者やプロトコル実装者の界隈では 暗号ライブラリは学習⽬的以外で独⾃実装するべきでない という教えがある 正しい暗号化が難しいことによるセキュリティリスク‧開発コストの増⼤が背景 OSSとなると影響範囲も⼤きくなり、⼀つのミスが甚⼤な被害を⽣む可能性もある 既存で世の中に普及しているライブラリは、専⾨家によって開発され、 ⻑い時間と労⼒をかけることでセキュリティと信頼性を獲得している
7. なぜGoで独自実装している？ 実際、他の⾔語では、 標準ライブラリとしては暗号機能を提供していないのがほとんど OpenSSLのリンクやラッパーの提供のみにとどめたり、 サードパーティ‧エコシステムに任せたり等 ではなぜ、わざわざ独⾃実装をしている？
8. Maintaining the Go Crypto Libraries https://www.infoq.com/presentations/go-crypto-library/
9. 「暗号ライブラリは独自実装するべきでない」について 実装しようとする開発者がいたのは、 提供されたライブラリのAPIが複雑で⼗分に使いやすくなかったため 開発者は、「今⽇は⾃分で暗号の組み合わせを考えたい」と思って 作業を始めるわけではなく、 ドキュメントを⾒ても使い⽅がわからず、Stack Overflowなどで調べて、 「XXXとYYYを組み合わせればうまくいくだろう」と考える ↑実装はセキュアであっても安全とは⾔えない
10. Goのエコシステム全体のセキュリティ維持のために 暗号化ライブラリはその⽬的を達成するためのツールに過ぎない Goチーム側で複雑さを管理することで、 Goの開発者が安全に実装対象のコードに集中できることを⽬指している Goチームにはそれができる優秀なメンバーが揃っている
11. • APIの表⾯上の複雑さ（ユーザーが直接利⽤する部分） ◦ コードコメントから⾃動的に API ドキュメントを⽣成するソリューションの おかげで、 ドキュメント化は⾮常に容易で、⽂化に組み込まれている • APIの表⾯下の複雑さ（内部実装） ◦ Go は可読性を重要視している⾔語 ◦ ⾔語仕様は⼩さく、演算⼦のオーバーロードや例外などがないので 制御フローは常に明確 複雑さの管理に Goは優れている
12. Goが暗号化を実装するのに適した言語だと考えられている • メモリセーフ ◦ バッファオーバーフローなどの脆弱性のリスクがない • バイナリの再現性 ◦ 同じアーキテクチャ、OSをターゲットにしている限り、 バイナリは同⼀になる • 実⽤的なパフォーマンス • 静的解析が⽐較的容易
13. 参考:「Why did Go implement its own SSL library?」に対する Rob Pike氏の回答 「AGL（Adam Langley）のような才能の持ち主がいて、彼がやりたがっていたこと、そしてすべてをGoで実装できたのは 素晴らしいことです。もし暗号化があまりにも難しく、唯⼀の実装しか許されないのであれば、それはGoのライブラリで はなく、暗号化そのものを再考する必要があります。さらに、Goはより安全で、コードがよりクリーンです。そのため、 暗号コードを書くにはCやC++よりも安全な⾔語だと私は主張します。挙げられている問題の多くは、ライブラリの未熟さ によるものであって、実現不可能であることが原因ではありません。 しかし実際には、SSLの作業が⾏われた時点ではcgoが存在していなかったため、Goで実装するのが唯⼀の選択肢だったの です。」 https://groups.google.com/g/golang-nuts/c/0za-R3wVaeQ/m/M8_BiuaZ_2YJ
14. メンテナンスの戦略やポリシー
15. Goの暗号ライブラリが目指していること • セキュアであること • 安全であること ◦ APIの使い⽅によって事故が起きない ◦ ドキュメントで何ができて何ができないか、 どのようなセキュリティが提供され、何が提供されないかが明確に⽰されている • 実⽤的であること ◦ 使⽤するには遅すぎると、役に⽴たないのはもちろん、 独⾃に実装がなされてしまうことで、開発者の管理する複雑さが⽣まれてしまう ◦ パフォーマンスが⼗分であれば、OpenSSL より 20% 低くてもよい • 最先端であること ◦ 従来の実装より良い代替⼿段が登場し、 ⼈々がそれを必要としている場合は早めにサポートを追加する
16. ユニバーサルサポートは目標としていない 基本的に暗号化アルゴリズムの選択については保守的 機能が増えるとそれだけ複雑になる（暗号ライブラリだとその傾向はより顕著） できる限りあらゆる場所で複雑さを管理し、排除することで、 コードの内容に集中できるようにすることが重要 将来的に⼤幅に変更される可能性が低いアルゴリズムや、 すでに幅広いエコシステムで積極的に使⽤されているアルゴリズムのサポートに 集中する（最先端である）ためでもある
17. アセンブリも最⼩限に アセンブリの利⽤ポリシーがWikiに存在 https://go.dev/wiki/AssemblyPolicy 提案issue: https://github.com/golang/go/issues/37168 • アセンブリの使⽤を最⼩限に ◦ アセンブリを 2 倍使⽤して 55% のスピードアップを実現するよりも、 アセンブリを少量使⽤して 50% のスピードアップを実現する⽅がよい • ⼩さくてテスト可能なユニット (25〜75 ⾏)を実装し、 Go テストで個々のユニットをテストできるように • Go コードに、アセンブリが必要な理由 (具体的なパフォーマンス上の利点、 命令へのアクセスなど) をドキュメントとして記載する
18. 今後の展望と最新動向
19. x/crypto の標準パッケージへの移⾏ #65269 golang.org/x/crypto と標準パッケージの境界が曖昧になってきている x/crypto にあり、標準ライブラリにない理由の説明が難しい場合が多く、ユー ザーを常に混乱させている 今後、x/cryptoはパッケージ毎に標準パッケージへの移⾏が検討される sha3やhkdfなどはすでにProposalがapproveされている
20. FIPS 140-3 認証 #69536, #70123 FIPSは、⽶国政府機関のNISTが定めるセキュリティ標準規格 「FIPS 140」は、機密指定はされていないもののセンシティブな情報を扱うため の暗号化アルゴリズムが正しく実装されていることが求められる、というもの これまで⻑くFIPS140-2バージョンが使われてきたが、2019年にFIPS140-3が承認 され、以降が開始 2026年9⽉21⽇までにFIPS140-3認証に完全に移⾏することが決まっている
21. FIPS 140-3 認証 #69536, #70123 現在Go の暗号ライブラリは FIPS 140-3 で検証されておらず、 Goで認証が必要な場合、cgo で認証済みライブラリを呼び出す必要がある （Go + Boring Crypto GOEXPERIMENT=boringcrypto などを使う） 今後ユーザーは GODEBUG でFIPSモードを指定することで FIPS 140-3 に適合した暗号化を利⽤できるようになる
22. ポスト量⼦暗号（耐量⼦計算機暗号）サポート #64537 ポスト量⼦暗号は量⼦コンピュータによる攻撃に対しても 安全性を保つことを⽬的とした暗号アルゴリズムの総称 （量⼦コンピュータ時代の後の暗号技術ということで「ポスト」がつく） 暗号業界全体でポスト量⼦暗号への移⾏が推進されており、 Go セキュリティチームは、できるだけ早くポスト量⼦鍵交換を Go標準で実現することが重要だと考えている
23. ポスト量⼦暗号（耐量⼦計算機暗号）サポート #64537 NIST が 最近標準化した ML-KEM (FIPS 203) は、 業界全体に導⼊されはじめており、 実はGo 1.23 で#67061 の⼀部としてすでに実装されている Go 1.24から、crypto/mlkem として公開パッケージでも ML-KEM がサポートされるようになる
24. ポスト量⼦暗号（耐量⼦計算機暗号）サポート #64537 記事も書きました https://zenn.dev/uji/articles/go-crypto-post-quantum-support
25. まとめ • Goは暗号化を実装するのに適した⾔語だと考えられており、 GoチームはGoで暗号ライブラリを再開発してサポートしている • 暗号化の複雑さをGoチームで管理することで、 Goの開発者が安全に実装対象のコードに集中できることを⽬指している • Goの暗号ライブラリは、セキュアであること、安全であること、 実⽤的であること、最先端であること の実現を⽬指している • 標準のcryptoとx/cryptoの境界が曖昧になっており、 x/crypto 内の実装の標準への移⾏が検討されている • FIPS 140-3 の認証 や、ポスト量⼦暗号への移⾏が始まっており、 今後も継続的に更新が⾏われる
26. 参考文献 • Maintaining the Go Crypto Libraries https://www.infoq.com/presentations/go-crypto-library/ • Filippo Valsorda⽒のブログhttps://words.filippo.io/ • Why did Go implement its own SSL library? https://groups.google.com/g/golang-nuts/c/0za-R3wVaeQ • なぜ WebAssembly ⽣成を Go にしたのか https://voluntas.medium.com/なぜ-webassembly-⽣成を-go-にしたのか-5b5612c86d7b • wolfCrypt組み込み暗号ライブラリ：FIPS認証 https://wolfssl.jp/products/wolfcrypt-fips/