mthiim/dilithium-java - Javaによる耐量子計算機暗号アルゴリズムの実装

 (github.com/mthiim)
1 ポイント 投稿者 GN⁺ 2023-10-24 | 1件のコメント | WhatsAppで共有
  • Dilithium 3.1 をJavaで実装し、プリミティブ演算をJCE providerでラップした実装で、標準化されたJava暗号インターフェースを通じて鍵生成・署名・検証を利用可能
  • RSAとECCがShor's algorithmを用いる量子コンピュータ攻撃に脆弱であるという背景から、NISTが選定したポスト量子デジタル署名方式の一つである Dilithium を実験・学習するための実装
  • CRYSTALSアルゴリズム群に属し、代数格子に基づくDilithiumをC参照実装とドキュメントをもとに実装しており、内部で使用するSHAKE128/256は Bouncy Castle 依存で提供
  • 文書化されたセキュリティレベル 2・3・5 をすべてサポートし、3つのレベルすべてで deterministic signature scheme を使用し、公式パッケージのKATテストに合格
  • JCEの利用フローは DilithiumProvider を登録した後、KeyPairGenerator.getInstance("Dilithium")、Signature.getInstance("Dilithium")、KeyFactory.getInstance("Dilithium") で鍵生成・署名・検証・鍵復元を行う方式
    • セキュリティレベルは DilithiumParameterSpec.LEVEL2、LEVEL3、LEVEL5 または getSpecForSecurityLevel() で指定
    • 公開鍵と秘密鍵は .getEncoded() でバイト表現を取得し、参照実装と互換性のある形式でシリアライズ・デシリアライズ
    • バイト表現には parameter spec がエンコードされないため、鍵復元時には DilithiumPublicKeySpec または DilithiumPrivateKeySpec に parameter spec を明示する必要がある
  • 公式Dilithiumパッケージの known-answer test リクエストファイルを読み込み、レスポンスファイルを生成する KAT.java ユーティリティを提供し、実行引数は <input-request-file> <output-response-file> <level> 形式
  • 現在の実装は Dilithium 3.1 を反映しており、標準化が進行中の FIPS 204 または ML-DSA バージョンとは異なる
  • 数日間で「for fun」として書かれた実装であり、production-grade code ではなく、第三者による脆弱性レビューもなく、いかなる保証やサポートも提供されない
  • Apache 2.0 ライセンスで提供

関連記事

1件のコメント

 
GN⁺ 2023-10-24
Hacker News のコメント

  • 自分のプロジェクトが Hacker News で注目されているのを見るとうれしい。これは論文とリファレンス実装に触発された純粋なおもちゃ実装です
    提供されているテストケースはすべて通りますが、主に楽しみで作ったもので、標準の JCE インターフェースとうまく噛み合って動くかを見るために書きました。質問やフィードバックがあれば気軽にどうぞ

    • 実サービスで使うには何が必要なのか気になります。耐量子暗号向けの Java ライブラリで、本番環境で使えるほど準備が整っているものがあるのかも知りたいです

  • この Dilithium のおもちゃ実装の中核部分は、ほとんどここで見られます: https://github.com/mthiim/dilithium-java/blob/main/src/main/...

  • RSA/ECDSA のような、より確立され広く使われているアルゴリズムの上に耐量子暗号アルゴリズムを重ねて使うのは良い考えなのか気になります
    耐量子暗号はまだ最先端すぎて、使いやすいとは言えません

    • 実際、コミュニティがやっているのはまさにその方式のように見えます
      Cloudflare は最近耐量子暗号を有効化し、X25519+Kyber を使っています [0]。Signal の耐量子暗号も同じ方式です [1]。
      数年前、ある耐量子アルゴリズムが古典コンピュータで破られた出来事から、こうした流れが出てきたのだと思います [2]。
      今や攻撃者は、古典アルゴリズムと耐量子アルゴリズムの両方を破らなければなりません
      [0] https://blog.cloudflare.com/post-quantum-to-origins/
      [1] https://signal.org/blog/pqxdh/
      [2] https://www.quantamagazine.org/post-quantum-cryptography-sch...
    • 私の知る限り、Shor のアルゴリズムはまだ現実味が低いです。妥当な時間内に実行するには、現在可能なものよりはるかに多くの量子ビットが必要だからです
      数百万量子ビットが必要になるはずですが、最先端の装置でも現在は多くて数百個程度です。今後数年、場合によっては数十年は、本番コードで耐量子アルゴリズムを大きく心配することはないと思います
    • 現在おおむね受け入れられているものの、全員が同意しているわけではない標準はハイブリッド暗号です。KEM/DEM で言う「ハイブリッド」とは異なりますが、通常はハイブリッド KEM/DEM 暗号方式と併用されます
      この方式は、平文にアクセスするには古典アルゴリズムと耐量子アルゴリズムの両方を破る必要があることを保証します。暗号化を単純に包むのか、Campagna と Petcher の例のようにハイブリッド KEM コンバイナを使うのかは、より微妙な問題で、私のレベルよりも精緻な判断が必要です
    • 私たちの生きている間に量子コンピュータがより実用化されるなら、現在の秘密が将来そうした解析にさらされてはなりません。量子コンピュータをスケールさせることは、真空管とトランジスタが集積回路へ発展したように単純ではありませんが、専門家による難易度の見積もりは「とてつもなく難しい」から「物理的に不可能なまま残る」まで分かれています
      いずれにせよ、現代標準の暗号鍵を総当たりで破るよりは可能性が高いので、今日ポスト量子セキュリティを優先する根拠はあります。
      ただし、注意が必要なのも確かです。PQ アルゴリズムにサイドチャネルや実装上の脆弱性があれば、むしろはるかに悪くなり得ます。最悪の場合、PQ 実装にリモートコード実行脆弱性があると想像すればよいでしょう。だから慎重に進め、コードを厳格にレビューするのがよいです
    • 耐量子暗号と既存の暗号を併用し、どちらか一方が破られても組み合わせ全体が崩れないように作られた方式には、実質的なリスクはありません
      鍵交換ではかなり簡単なほうで、方式によって出力値を XOR するか連結すればよいです

  • README には Bouncy Castle への依存が言及されていますが、BC にはすでに Java ベースの PQC 署名方式がいくつも入っています。https://doc.primekey.com/bouncycastle/interoperability#Inter... と https://github.com/bcgit/bc-java を参照するとよいです

  • 数日前、Daniel Bernstein が NSA が欠陥のあるポスト量子暗号の実装を広めようとしていると警告していました。リンクは見つけられません

  • 別のポスト量子署名方式である sphincs+ の単一ファイル Java 実装を作成／移植したものがここにあります
    https://github.com/Peergos/sphincsplus

  • 「RSA と ECC の暗号アルゴリズムは、Shor のアルゴリズムを使う量子コンピュータ攻撃に弱いことが昔から知られている。」
    これが事実で、その規模の量子コンピュータが実際に登場したら、Bitcoin にはどんな影響があるのか気になります

    • 問題になる前に移行されるでしょう。仮に実際に起きたとしても、最初に知られた攻撃時点で耐量子暗号を入れてフォークすればよいです

  • 「これは数日間で楽しみとして書いた実装です。本番グレードのコードとして意図されたものではありません。いかなる種類の保証やサポートも提供されません。ただし、ポスト量子アルゴリズムを覗いて実験するには有用かもしれません。自己責任で使用してください。この条件が気に入らない場合は、このソフトウェアを使用すべきではありません」