LLM4PQC - Accurate and Efficient Synthesis of PQC Cores by Feedback-Driven LLMs

本論文は、LLM を活用してポスト量子暗号（PQC）の C 参照コードを HLS 対応かつ合成可能なコードへ自動変換し、多段階の検証フローを通じて RTL 生成と検証を行う「LLM4PQC」というフレームワークを提案し、PQC ハードウェア設計における手作業の削減と設計空間探索の加速を実現することを示しています。

要約

この論文は、**「LLM4PQC（エルエルエムフォーピーキューシー）」**という、人工知能（AI）を使った新しい「設計ツール」について紹介しています。

一言で言うと、**「AI に頼んで、複雑な暗号の『設計図』を、自動的にハードウェア（チップ）が作れる形に変えてくれる魔法の翻訳機」**のようなものです。

以下に、専門用語を排除し、身近な例え話を使ってわかりやすく解説します。

---

1. 背景：なぜこんなものが必要なの？

【問題：古い鍵はもう使えない】
今のインターネットのセキュリティ（RSA や ECC という鍵）は、将来登場する「量子コンピュータ」という超強力な計算機が現れると、簡単に壊されてしまいます。
そこで、アメリカの標準化機関（NIST）は、量子コンピュータにも耐えられる新しい「ポスト量子暗号（PQC）」という新しい鍵の仕組みを決めました。

【課題：ソフトウェアとハードウェアの壁】
新しい鍵の仕組みは、すでに「C 言語」というプログラミング言語で書かれた「設計図（参考コード）」として公開されています。
しかし、この設計図は**「人間が読むには完璧だが、機械（ハードウェア）が作るには不向き」**な状態です。

• 例え話：
  • 参考コードは、**「料理のレシピ」**のようなものです。材料の量や手順が詳しく書かれていますが、そのままでは「工場で自動で料理を作る機械」にはかけられません。
  • ハードウェアを作るには、そのレシピを**「工場の機械が理解できるマニュアル」**に書き直す必要があります。
  • 従来のやり方では、この書き直しを熟練の職人が手作業で行う必要があり、非常に時間がかかり、ミスも起きやすかったのです。

2. 解決策：LLM4PQC という「魔法の翻訳機」

この論文では、**「フィードバック型 AI（LLM）」**を使って、この手作業を自動化するシステム「LLM4PQC」を提案しています。

このシステムがどう働くか（4 つのステップ）

1. レシピの選定（抽出）

   • 全体の料理（暗号システム）から、一番時間がかかる「メインの工程（NTT やサンプリングなど）」だけを AI が選び出します。
   • 例え： 大きな宴会の料理から、「一番手間がかかる天ぷら」だけを取り出して、それを機械で大量生産する計画を立てる。

2. 下ごしらえ（前処理）

   • 元のレシピには、機械が嫌がる「動的なメモリの確保」や「複雑な計算」が含まれています。AI がこれらを「機械が理解できる形」に書き換えます。
   • 例え： 料理人が「その場で材料を調達する」ような指示を、「事前に倉庫に用意しておく」ように書き換える。

3. 翻訳と試作（生成と検証）

   • AI が「機械用マニュアル（HLS-C）」を生成します。
   • ここが重要！ AI は一度で完璧に作れません。だから、**「試作→失敗→修正」**を繰り返します。
   • 例え： AI が作ったマニュアルを工場の機械にかけてみる。エラーが出たら、そのエラーメッセージを AI に見せて「ここが間違っていたよ」と教えてあげる。AI はそれを学び、マニュアルを修正して再試行します。これを「フィードバックループ」と呼びます。

4. 完成と検査（合成と検証）

   • 最終的に、実際にチップ（ハードウェア）として作れるコードが完成し、正しく動くか厳しくテストされます。

3. 成果：どれくらいすごいのか？

このシステムを使って、新しい暗号（Kyber, Dilithium, Falcon など）の核心部分をテストしました。

• 手作業との比較：

  • 職人が一から作るよりも、開発時間が大幅に短縮されました。
  • 意外なことに、AI が作った設計図は、**「省スペース（面積が小さい）」**なチップを作るのに非常に優れていました。
  • 例え： AI は「狭いキッチンでも効率的に料理ができる工夫」を自然に見つけ出し、職人が作るよりもコンパクトな機械を作ることができました。

• 弱点：

  • 省スペースにする代わりに、**「少し動作が遅い（レイテンシが高い）」**傾向がありました。
  • 例え： 狭いキッチンでコンパクトに作ると、一度に大量の料理を作るスピードは、広いキッチンで並列に作るより少し遅くなる、ということです。

4. まとめ：この研究の意義

この論文は、**「AI がハードウェア設計の壁を乗り越えられる」**ことを示しました。

• これまでの常識： ハードウェア設計は、高度な専門知識を持つ人間しかできない。
• 新しい未来： AI に「試行錯誤（フィードバック）」をさせることで、複雑な暗号チップも、より簡単に、効率的に設計できるようになります。

**「AI は、単にコードを書くだけでなく、失敗から学び、完璧なハードウェアの設計図を完成させる『職人見習い』として活躍できる」**というのが、この研究が伝えたい最大のメッセージです。

---

要約：
量子コンピュータ時代に向けて、新しい暗号のハードウェアを作るのは大変でしたが、**「失敗を繰り返して学習する AI」**を使えば、その作業を自動化し、より小さく効率的なチップを素早く作れるようになりました。これは、セキュリティの未来を加速させる大きな一歩です。

技術概要

LLM4PQC: フィードバック駆動型 LLM による PQC コアの正確かつ効率的な合成に関する技術的サマリー

本論文は、ポスト量子暗号（PQC）のハードウェア実装における課題を解決し、参照 C コードから合成可能なハードウェアアクセラレータを自動生成するための新しいフレームワーク「LLM4PQC」を提案しています。大規模言語モデル（LLM）を活用し、フィードバックループを組み込むことで、従来の手動リファクタリングに依存していたプロセスを自動化・効率化しています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。

---

1. 背景と問題定義

ポスト量子暗号（PQC）の標準化が進む中、そのハードウェア実装の需要は高まっていますが、以下のボトルネックが存在します。

• C コードから HLS への変換の難易度: NIST が公開する PQC 参照実装は、移植性と機能の正しさを優先した C コードであり、ハードウェア合成（High-Level Synthesis: HLS）には直接適用できません。
• 手動リファクタリングの負担: 参照コードを HLS 対応にするには、動的メモリ割り当ての排除、浮動小数点演算の固定小数点化、定数テーブルのコンパイル時初期化など、膨大な手動リファクタリングと反復的なツール駆動の試行錯誤が必要です。
• 複雑なプリミティブ: NTT（数論的変換）、FFT、ガウスサンプリャーなど、PQC のコアとなるアルゴリズムは、数学ライブラリ呼び出しや複雑なデータ構造を含み、HLS ツールが処理できない「合成の障壁（Synthesis Blockers）」を多く含んでいます。
• LLM の限界: 一般的なプログラミングでは LLM が成果を上げていますが、ハードウェア設計（RTL 生成）においては、単なるコード生成ではなく、コンパイルエラーや合成結果からのフィードバックに基づく「エージェント的（agentic）」なアプローチが不可欠です。

2. 提案手法：LLM4PQC フレームワーク

LLM4PQC は、参照 C コードを HLS 対応の C コードに変換し、RTL を生成・検証するまでを自動化する 4 つのフェーズから構成されます。

フェーズ 1: PQC サブルーチンの抽出

• 全体の実装を HLS に変換するのではなく、性能クリティカルなサブルーチン（NTT、サンプリング、FFT など）を LLM を用いて特定・抽出します。
• 抽出された関数に対して、既知の答えテスト（KAT: Known-Answer Tests）を含む検証インフラを自動生成し、C レベルでの機能等価性を確保します。

フェーズ 2: HLS 前処理（Preprocessing）

参照コードが HLS ツールで直接扱えない問題を事前に解消する段階です。

• 静的メモリマッピング: malloc や動的配列を、コンパイル時にサイズが確定する静的配列に変換します。
• 初期化ルートの除去: 実行時に定数テーブル（例：FFT の Twiddle 係数）を計算するルートを排除し、代わりにコンパイル時に定数として展開された配列宣言を生成します。
• これらの変換は LLM に指示を与えて行い、コンパイルエラーや KAT 失敗をフィードバックとして再試行します。

フェーズ 3: HLS-C 生成と設計空間探索（DSE）

• C2HLSC ツールの活用: 前処理されたコードを、LLM と HLS ツール（Catapult）を統合した「C2HLSC」フレームワークに入力します。
• 構造認識型プロンプト: ユーザー定義構造体（struct）は HLS で扱いにくいため、LLM に指示してプリミティブ型へ展開（Unpacking）させます。
• フィードバック駆動型最適化: 合成ツールからのエラーメッセージや PPA（Power, Performance, Area）メトリクスを LLM にフィードバックし、ループのアンロールやパイプライン化などの HLS プラグマを自動的に調整・最適化します。

フェーズ 4: 合成と検証

• 生成された HLS-C コードを ASIC（Design Compiler）および FPGA（Vivado）で合成します。
• C レベルの KAT を用いて自動生成されたテストベンチにより、RTL 出力の機能正しさを検証します。

3. 主要な貢献

1. HLS 準拠のための LLM 駆動型前処理: データ構造の展開、動的メモリ割り当ての排除、定数初期化の除去など、PQC 参照コード特有の HLS 障壁を自動的に解消するパイプラインを確立しました。
2. 構造化されたフィードバック駆動ワークフロー: 単なるコード生成ではなく、コンパイル・シミュレーション・合成の失敗情報を LLM にフィードバックし、コードを反復的に改善する完全自動化されたハードウェア設計ループを提案しました。
3. 実証的なケーススタディ: NIST 標準の PQC アルゴリズム（Kyber, Dilithium, Falcon）およびそのコアプリミティブ（NTT, サンプリャー, FFT）に対する評価を行いました。

4. 実験結果

Kyber、Dilithium、Falcon の 5 つのサブルーチン（Kyber-NTT, Dilithium-NTT, Falcon-NTT, Falcon-Sampler, Falcon-FFT）を対象に、ASIC（Nangate 45nm）および FPGA（Xilinx Artix-7, XCZU7EV）で評価しました。

• 成功率と自動化:
  • ほとんどのベンチマークで 100% の成功率を達成しました（Falcon-Sampler は 40%、Falcon-NTT は 70%）。
  • 手動でのリファクタリングに比べ、設計空間探索（DSE）が大幅に加速されました。
• ハードウェア性能（ASIC）:
  • 面積効率: 生成された設計は、既存の手動最適化された設計と比較して、LUT および FF（フリップフロップ）の使用量が少なく、非常にコンパクトでした。例えば、Kyber-NTT は約 2,957 µm²、Dilithium-NTT は約 6,506 µm² でした。
  • レイテンシ: 面積効率を優先した結果、手動設計に比べレイテンシ（遅延）は高くなる傾向がありました。これは LLM が保守的なループ構造を生成しやすいことに起因します。
• FPGA 比較:
  • 既存の LLM 支援手法（[18]）と比較して、Falcon-Sampler においてレイテンシと FF 使用量の両方で優位性を示しました。
  • 手動設計と比較しても、リソース使用量（LUT/FF）は低く抑えられていますが、動作周波数は低めでした。

5. 意義と考察

• 生産性と品質のトレードオフの解決: LLM4PQC は、PQC ハードウェア開発の「生産性（迅速なプロトタイピング）」と「品質（リソース効率）」のバランスを効果的に取りました。
• 浮動小数点処理の課題: Falcon の FFT やサンプリャーなど、浮動小数点演算が多用される部分は、LLM が HLS のドメイン知識（合成可能な実装への変換）を欠いているため、前処理段階での C レベルの変換が不可欠であることが示されました。
• 今後の展望:
  • LLM の HLS 知識を強化するためのファインチューニングや、検証済み HLS パターンを参照する RAG（Retrieval-Augmented Generation）の導入。
  • 合成前の PPA 予測モデルを用いた高速な設計空間探索。
  • 遅延（レイテンシ）を改善するための、より積極的な並列化やアーキテクチャ調整への LLM の誘導。

結論

LLM4PQC は、複雑な PQC アルゴリズムのハードウェア実装において、手動リファクタリングの負担を軽減し、合成可能な RTL を効率的に生成する強力な枠組みです。フィードバック駆動型のアプローチにより、LLM 単体のコード生成では達成困難な「正しさと合成可能性」を両立させ、ポスト量子暗号のハードウェア普及を加速させる可能性を秘めています。