crypto/mldsa: new package
要約
概要
crypto/mldsa は、NISTが標準化したポスト量子署名アルゴリズム ML-DSA(FIPS 204)を実装する新しい標準ライブラリパッケージのproposalです。Go 1.26で内部実装として追加された ML-DSA を、Go 1.27でパブリックAPIとして公開することを提案しています。
ステータス変更
active → likely_accept
2026年4月15日のProposal Review Meetingにおいて、ACLementsを含むレビューグループがトップコメントに記載されたAPIを進めることに合意しました。いくつかのドキュメントコメントの更新・明確化(NewPrivateKeyの説明文修正、Verifyの opts nilチェックの明示)を条件として likely accept に移行しました。
技術的背景
現状の問題点
量子コンピュータの発展に伴い、現行のRSAやECDSAなどの公開鍵署名方式は将来的に解読される危険性があります。NISTはこれに対応するポスト量子暗号アルゴリズムを標準化し、その一つがML-DSA(Module-Lattice-Based Digital Signature Standard、旧称 CRYSTALS-Dilithium)です。
Go 1.26ではML-KEMに続きML-DSAの内部実装が追加されましたが、crypto/internal に閉じており、一般の開発者はアクセスできませんでした。標準ライブラリとして公開することで、Go開発者が安全にポスト量子署名を利用できる基盤が必要とされていました。
提案された解決策
新パッケージ crypto/mldsa を追加し、以下の主要なAPIを提供します。
- パラメータセット:
MLDSA44(),MLDSA65(),MLDSA87()の3種類(セキュリティレベルの異なる変種、一般用途にはMLDSA44推奨) - 鍵生成:
GenerateKey(params Parameters)でランダム秘密鍵生成、NewPrivateKey(params, seed)でシードから復元 - 署名:
PrivateKey.Sign()でcrypto.Signerインタフェースを実装、SignDeterministic()で決定論的署名も提供 - 検証: パッケージレベル関数
Verify(pk, message, signature, opts)で署名検証 - PKIX/PKCS#8対応: RFC 9881に従い、
x/crypto/x509の既存関数で ML-DSA 鍵のマーシャリング/アンマーシャリングに対応
さらに、ハードウェアモジュール等での利用に対応するため、cryptoパッケージに新しいハッシュ定数crypto.MLDSAMuを追加します。これは External μ(事前ハッシュ済みメッセージ)を扱うためのセンチネル値です。
これによって何ができるようになるか
量子コンピュータ耐性を持つデジタル署名をGoの標準ライブラリのみで実装できるようになります。TLS証明書署名、ファイル署名、APIトークン署名など、将来の量子脅威に備えたシステムを構築できます。
コード例
// Before: 外部ライブラリ (filippo.io/mldsa 等) を使う必要があった
import "filippo.io/mldsa"
key, _ := mldsa.GenerateKey(mldsa.MLDSA44())
sig, _ := key.Sign(nil, message, nil)
// After: 標準ライブラリで完結
import "crypto/mldsa"
// 鍵生成
key, err := mldsa.GenerateKey(mldsa.MLDSA44())
if err != nil {
log.Fatal(err)
}
// 署名
sig, err := key.Sign(nil, message, nil)
// 検証
err = mldsa.Verify(key.PublicKey(), message, sig, nil)
// シリアライズ(PKCS#8形式で秘密鍵をエクスポート)
import "crypto/x509"
der, _ := x509.MarshalPKCS8PrivateKey(key)
議論のハイライト
Parameters型のポインタ問題:@aclementsの指摘により、*ParametersからParameters値型に変更。シングルトンパターンで返す設計は維持しつつ、*MLDSA44() = MLDSA65()のような誤用を防ぐ設計に修正された。- Semi-expanded 秘密鍵フォーマットの排除: NISTが後付けで規定した「半展開形式」は大きさが大きく読み込みも遅い上に危険なため、Go と BoringSSL はシードのみをサポートする方針を貫いた。OpenSSLがIETF WGへの公開書簡で3種類のフォーマット対応を求めたが、採用されなかった。
- HashML-DSAの非サポート: 外部ハッシュは External μ で代替可能であり、HashML-DSA には対応しない方針。RFC 9881でも同様の判断が示されている。
SignDeterministicメソッドの採用: 決定論的署名はSignのみに関係しVerifyには無関係なため、Optionsフィールドではなく専用メソッドとして提供された。crypto.MLDSAMuセンチネル値: ハードウェア実装をcrypto.Signer経由で扱う際の External μ 識別にcrypto.Hashのiota定数を割り当てる設計。MD5SHA1と同様の前例に沿った判断。