標準ライブラリの暗号化パッケージの完全なスイートを搭載して、開発者がセキュアなアプリケーションを構築するのを助ける。 パッケージのコアセットの監査を完了するため、同様にその一部として検証されている。 監査は、遺伝的で支持されていない低重度の単一の発見を生み出した。 ,およびいくつかの情報の発見. 監査報告書の全文を見つけることができます。 . トレイル of Bits FIPS 140-3 モジュール Go+BoringCryptoの統合 ここ 監査の範囲には、鍵交換(ECDHおよびポスト量子 ML-KEM)、デジタル署名(ECDSA、RSA、Ed25519)、暗号化(AES-GCM、AES-CBC、AES-CTR)、ハッシュ(SHA-1, SHA-2,および SHA-3)、鍵引き出し(HKDFおよび PBKDF2)、認証(HMAC)、暗号化ランダムナンバージェネレーターなどの実装が含まれていました。 我々は、Go暗号化パッケージのセキュリティ・トラック・レコード、およびこの監査の結果を誇りに思うが、これは我々がパッケージの正確性の確信を得る多くの方法の1つにすぎない。 優先順位を優先するものとしますが、私たちは、 さまざまなテクニックで、内部パッケージでさえ安全な API を活用し、もちろん、メモリ管理の問題を回避するためにGo言語の特性に頼ることができます。 暗号化の原則 徹底的にテスト 1 低重度の発見 唯一潜在的に利用可能な問題、TOB-GOCL-3は、 , つまり、それは小さな影響を及ぼし、起動するのが困難でした. この問題はGo 1.24 で修正されています。 低重度 トップ > トップ > トップ > トップ > トップ > トップ > トップ > トップ > ( )のメモリ管理に関すること。 デフォルトでは有効で、Google 以外の利用にはサポートされていません。 詳しくは下に legacy Go+BoringCrypto GOEXPERIMENTの検索結果 5 情報発見 残りの発見は、 つまり、彼らは直ちにリスクを引き起こさないが、セキュリティのベストプラクティスに関連するものであることを意味します。 情報 TOB-GOCL-1, TOB-GOCL-2, and TOB-GOCL-6 findings concern possible timing side-channels in various cryptographic operations. Of these three findings, only TOB-GOCL-2 affects operations that were expected to be constant time due to operating on secret values, but it only affects Power ISA targets (GOARCH ppc64 and ppc64le). TOB-GOCL-4 highlights the risk of misuse in an internal API, should it be repurposed beyond its current use case. TOB-GOCL-5 points out a missing check for a limit that is impractical to reach. これらの三つの発見のうち、TOB-GOCL-2 だけが、秘密値で動作するため、常時恒久的な作業に影響を与えます。 サイドチャンネルタイム 結果 TOB-GOCL-1, TOB-GOCL-2, and TOB-GOCL-6 refer to minor timing side-channels. TOB-GOCL-1 and TOB-GOCL-6 are related to functions that we do not use for sensitive values, but could be used for such values in the future, and TOB-GOCL-2 is related to the assembly implementation of P-256 ECDSA on Power ISA. TOB-GOCL-1 and TOB-GOCL-6 are related to functions that we do not use for sensitive values, but could be used for such values in the future, and TOB-GOCL-2 is related to the assembly implementation of P-256 ECDSA on Power ISA. : バイトからフィールド要素への変換は常時ではありません(TOB-GOCL-1) crypto/ecdh,crypto/ecdsa NISTのエリプト曲線の内部実装は、変化する時間で動作する内部および外部の代表の間でフィールド要素を変換する方法を提供した。 この方法のすべての用途は、秘密とみなされない公開の入力(公開のECDH値とECDSAの公開鍵)で動作したため、これはセキュリティ上の問題ではないと判断しました。 将来、この方法を秘密値で偶発的に使用するのを防ぐため、それが問題であるか否かについて考える必要はありません。 いずれにせよ、方法を常時 : P-256 conditional negation is not constant time in Power ISA assembly (TOB-GOCL-2, CVE-2025-22866) crypto/ecdsa Beyond The , Go はまた、いくつかの一般的なアーキテクチャを含むいくつかの追加プラットフォームをサポートしています。さまざまな潜在的な暗号原理の組み立て実装のレビュー中に、Trail of Bits チームは ppc64 および ppc64le アーキテクチャの ECDSA 実装に影響を与えた問題を発見しました。 ファーストクラス Go Platforms P-256 ポイントの条件否定を実行するための条件分割指示の使用により、この関数は、予想どおり、常時ではなく変数時間で動作しました。 既に他の場所で使用しているパターンで、常時正しい結果を選択するために条件付きで選択しました。 Conditional Branching Instruction を変更する ほとんどのユーザーに届くコードを優先するために、特定の ISA をターゲットにするために必要な専門知識のために、私たちは一般にコミュニティの貢献に頼って、ファーストクラス以外のプラットフォームのアセンブリを維持します。 : Scalar.SetCanonicalBytes is not constant time (TOB-GOCL-6) crypto/ed25519 内部の edwards25519 パッケージは、変化する時間で動作するスカラルの内部および外部の表示間を変換する方法を提供しました。 この方法は ed25519.Verify への署名入力にのみ使用され、これらは秘密とみなされていないため、これはセキュリティ上の問題ではないと判断しました。 この方法を将来秘密値で偶発的に使用することを防ぐため、また、人々がこのコードを標準ライブラリの外にフォークし、秘密値で使用している可能性があることを知っているためです。 いずれにせよ、方法を常時 CGOメモリ管理 TOB-GOCL-3 を検索すると、Go+BoringCrypto 統合におけるメモリ管理の問題が発生します。 : custom finalizer may free memory at the start of a C function call using this memory (TOB-GOCL-3) crypto/ecdh レビュー中に、Google で内部使用するための FIPS 140-2 に準拠する暗号化モードを提供する CGO ベースの Go+BoringCrypto 統合について、いくつかの質問がありました。 Trail of Bits チームは 1 つの脆弱性と 1 つの脆弱性を発見しました。 両方とも C ライブラリと相互作用するために必要なマニュアル管理の結果であったため、Go チームはこのコードの Google 外の使用をサポートしていないため、CVE または Go 脆弱性データベースのエントリをこの問題に対して発行しないことを選択しました。 . 非セキュリティ関連バグ Go 1.24 で修正しました。 このような落とし穴は、我々がGo+BoringCrypto統合から離れることを決定した多くの理由の1つです。 従来の純粋なGo暗号化パッケージを使用して、従来のGoメモリモデルに有利な複雑なcgoセマンティクスを避けることができます。 FIPS 140-3 モード 実施の完全性 TOB-GOCL-4 および TOB-GOCL-5 の発見は、2 つの仕様の限定的な実装に関するものである。 そして . NIST SP 800-90A RFC 8018 : CTR_DRBG API は複数の誤用リスクを提示します(TOB-GOCL-4) crypto/internal/fips140/drbg 」の一部として、 私たちが導入する時点で、コンプライアンスのあるランダム性を提供するために、NIST CTR_DRBG(AES-CTRベースの決定的なランダムビット生成器)の実装が必要でした。 FIPS 140-3 モード 私たちの目的のためにNIST SP 800-90A Rev. 1 CTR_DRBGの機能のわずかなサブセットしか必要ないため、私たちは完全な仕様を実装しませんでした、特に、誘導機能とパーソナライズシートを省略しました。 私たちの実装は、私たちが必要とする特定の用例に密接にカバーされているため、実装は公開的に輸出されていないため、これは受け入れられるものであり、実装の複雑さを減らす価値があると判断しました。 これらの制限を詳細に説明します。 ドキュメントに警告を追加 : PBKDF2 は出力長制限を適用しません(TOB-GOCL-5) crypto/pbkdf2 Go 1.24 では、パッケージを移動するプロセスを開始しました。 標準ライブラリに入り、ファーストパーティー、高品質、安定したGo暗号化パッケージが標準ライブラリの外に特定の理由なしに保管された混乱のパターンに終わる。 golang.org/x/クレジット このプロセスの一環として、我々は、 パッケージを標準ライブラリに、crypto/pbkdf2 として入力します。このパッケージをレビューする際に、Trail of Bits チームは、我々が定義した衍生キーのサイズの制限を適用していないことに気付きました。 . golang.org/x/仮想通貨/pbkdf2 RFC 8018 制限は SHA-256を使用すると、制限を超えると137GB以上のキーがかかります。PBKDF2を使用してこの大きさのキーを生成する人はいないと思いますが、特にPBKDF2が各ブロックでイテレーションを実行しているため、正確性のために、私たちは . (2^32 - 1) * <hash length> 現在、標準で定義された限界を適用します。 次は何 この監査の結果は、Goチームが高品質で使いやすい暗号化ライブラリを開発するための努力を検証し、安全で安全なソフトウェアを構築するためにそれらに依存する当社のユーザーに信頼を提供すべきである。 しかし、我々は、我々が提供する暗号図書館を開発し、改善し続けているGoの貢献者たち。 Go 1.24 には、現在 CMVP テスト中の純粋な Go で書かれた FIPS 140-3 モードが含まれており、これにより、現在サポートされていない Go+BoringCrypto 統合を置き換え、すべての Go ユーザーにサポートされている FIPS 140-3 コンプライアンスモードが提供されます。 我々はまた、近代的な量子後暗号化の実装に取り組んでおり、ML-KEM-768とML-KEM-1024の実装をGo 1.24で導入している。 ,および、ハイブリッドX25519MLKEM768キー交換の暗号/tlsパッケージへのサポートを追加。 Crypto/mlkem パッケージ 最後に、高レベルの暗号化 API を導入することを計画しており、選択の障壁を軽減し、基本的な使用事例のための高品質アルゴリズムを使用することを計画しています。私たちは、ユーザーがどれに依存すべきかを決定する必要性を除去するシンプルなパスワードハッシュ API を提供することから始める予定です。 ロランド・シューメーカー&フィリポ・ヴァルソルダ この記事は、CC BY 4.0 DEED ライセンスの下で The Go Blog で利用できます。 GO BLOG GO BLOG 写真:Batyrkhan Shalgimbekov on Unsplash バティルハン・シャルギンベコフ Unsplashについて

Try and Download Go 

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

Goの暗号化パッケージは監査された:結果

About Author

コメント

ラベル

この記事は

Related Stories

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

ユニークなエコシステムを支えるビットコインUTXOのモデル

Telegram: クリプト島と本土を結ぶ橋

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

ユニークなエコシステムを支えるビットコインUTXOのモデル

Telegram: クリプト島と本土を結ぶ橋

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps