top of page
検索

PQC暗号アルゴリズムを理解する：SLH-DSA 入門

  • 6月7日
  • 読了時間: 6分

“もう一つの署名”が持つ意味


PQC の署名方式を考えるとき、まず中心になるのは ML-DSA です。一方で、実運用を前提にすると、それだけで整理を終えるのはやや危うい見方でもあります。政府、金融、重要インフラのように移行期間が長く、影響範囲も広い領域では、単一の数学的前提に依存しすぎない設計にも意味があります。NIST は ML-DSA に加えて SLH-DSA も標準化しており、署名のPQC移行は「どの方式を主に使うか」だけでなく、「別系統の方式をどう持つか」まで含めて考えるべき段階に入っています。


SLH-DSA の重要性は、単に“別の署名方式がある”という話ではありません。ML-DSA とは異なる基盤を持つ標準方式が用意されていること自体が、長期運用や高価値資産を扱う設計において意味を持ちます。PQC を実務として捉えるなら、SLH-DSA は予備知識ではなく、暗号アジリティを考えるうえで押さえておくべき要素です。


SLH-DSA は何をするアルゴリズムか


SLH-DSA は、NIST が FIPS 205 で定めた stateless hash-based digital signature です。旧称は SPHINCS+。役割そのものは RSA、ECDSA、EdDSA、ML-DSA と同じで、秘密鍵で署名を作り、公開鍵でその署名を検証するための方式です。NIST は FIPS 205 の中で、デジタル署名はデータ改ざんの検出、署名者の認証、そして第三者に対する証拠性に用いられると説明しています。


ただし、SLH-DSA の本質は「署名方式が1つ増えた」ということではありません。ML-DSA が module lattice に基づくのに対し、SLH-DSA はハッシュベース署名です。つまり、両者は同じ「署名」という役割を果たしながら、異なる数学的基盤の上に立っています。この違いは、性能比較より先に意味を持ちます。要するに、別系統の安全性を持つ署名方式を標準として確保しているということです。


なぜ SLH-DSA が安全だと考えられているのか


SLH-DSA が重要なのは、RSA や楕円曲線署名のように素因数分解問題や離散対数問題へ依存していないからです。これらの前提は、大規模量子計算機が実用化した場合、Shor のアルゴリズムによって崩れる懸念があります。一方、SLH-DSA は、名前の通りハッシュ関数の安全性を主たる土台にした署名方式です。したがって、格子ベース署名とも違う前提の上で、量子時代の署名を構成しようとしているわけです。FIPS 205 は、SLH-DSA を stateless hash-based digital signature として定義しており、これは ML-DSA とは異なる安全性の軸を持つことを意味します。


もちろん、これも「絶対安全」を意味するわけではありません。ハッシュベースであることは、方式の安全性前提を単純にする方向へ働きますが、実際の安全性は依然として、鍵管理、署名対象の正規化、検証の厳格さ、実装品質、運用手順に支えられます。つまり、SLH-DSA を選んだから安全になるのではなく、異なる前提の署名方式をどう設計に生かすかが重要です。これは暗号アジリティの議論そのものです。


何にとって代わるのか


SLH-DSA も、役割としては従来の公開鍵署名方式を置き換える候補です。つまり対象は RSA 署名、ECDSA、EdDSA、そして将来的には ML-DSA 単独依存の構成さえ含みます。ここでいう「置き換える」とは、必ずしも全面的に主役になるという意味ではありません。むしろ実務では、主方式とは別系統の署名方式として併用・補完する見方がしっくりきます。FIPS 205 は SLH-DSA を独立した標準署名方式として定義しており、OQS でも ML-DSA と並ぶ NIST standards として扱っています。


ここで大事なのは、SLH-DSA も ML-DSA と同じく、鍵共有の代替ではないという点です。あくまで署名方式です。したがって、TLS で言えば ML-KEM がハンドシェイク中の共有秘密確立を担い、ML-DSA や SLH-DSA は証明書やソフトウェア署名、イメージ検証などの真正性確認を担います。この役割分担をはっきり分けておくことが、PQC を整理するうえで重要です。


なぜ SLH-DSA を知るべきか


SLH-DSA を学ぶ意義は、「ML-DSA がだめだったときの予備」という単純な話ではありません。もちろん、NIST は FIPS 205 を ML-DSA と異なる基盤を持つ標準として整備していますが、実務上はそれ以上に、暗号アジリティの確保という視点が重要です。NIST は ML-DSA と SLH-DSA の2つの署名標準が今後の多くの導入の基盤になるとし、OQS でも両者を NIST standards として並べています。つまり、最初から「署名は複数の系統を見ておくもの」として受け止めるのが自然です。


たとえば次のような場面では、SLH-DSA を理解しておく意味があります。

  • ルートオブトラスト周辺で別系統の署名を持ちたい

  • 長期運用機器で暗号多様性を確保したい

  • 高価値更新系で fallback 的な位置づけを持たせたい

  • 「主方式」と「保険」を分けて設計したい


特に、長寿命システムや高価値資産では、「いま最も使いやすい方式」だけを選ぶよりも、将来の不確実性に備えて別系統の選択肢を保持すること自体に価値があります。金融分野向けの G7 CEG ロードマップも、移行は一社単独ではなく、サプライチェーンや第三者を含む協調的な取り組みになることを強調しています。そうした状況では、単一方式への過度な依存を避ける発想はかなり実務的です。


Python サンプルコード例


OQS は liboqs で SLH-DSA を NIST standard の署名方式として扱っています。Python では oqs.get_enabled_sig_mechanisms() から利用可能な署名方式を確認できます。 (Open Quantum Safe)

import oqs
import hashlib

# ビルドによって有効化されている SLH-DSA 名を選ぶ
slh_candidates = [name for name in oqs.get_enabled_sig_mechanisms() if name.startswith("SLH-DSA")]
if not slh_candidates:
    raise RuntimeError("SLH-DSA is not enabled in this liboqs build")

SIG_ALG = slh_candidates[0]

manifest = b"root-metadata:v1:target=prod:expires=2027-12-31"
digest = hashlib.sha256(manifest).digest()

with oqs.Signature(SIG_ALG) as signer:
    public_key = signer.generate_keypair()
    signature = signer.sign(digest)

with oqs.Signature(SIG_ALG) as verifier:
    ok = verifier.verify(digest, signature, public_key)

print(f"algorithm = {SIG_ALG}")
print(f"signature valid = {ok}")

この書き方にしているのは、SLH-DSA はビルドやラッパーの有効化状況で候補名が変わることがあるためです。


まとめ


SLH-DSA は、PQC を単なる方式比較としてではなく、暗号アジリティを踏まえた設計を考えるうえで重要な位置付けを持つアルゴリズムです。その理由の一つは、冒頭にも述べたようにNIST がこれを FIPS 205 として標準化し、ML-DSA とは異なる基盤を持つ主要な署名方式として明確に位置付けている点にあります。


特に、政府、金融、重要インフラのように移行期間が長期に及ぶ分野では、「どの方式を主軸として採用するか」だけでなく、「異なる前提に立つ別系統の方式をどのように持つか」も重要な論点になります。PQC 移行は、単に一つの推奨方式へ置き換えれば終わる話ではなく、将来の不確実性も見据えて設計していく必要があるからです。


その意味で、SLH-DSA を学ぶ価値は、性能表の比較にとどまりません。一種類の前提に依存しない設計とは何かを考えられるようになること、そして長期運用を前提とした署名基盤の持ち方を整理できるようになることにこそ、大きな意義があります。


参考


bottom of page