AONT（All-Or-Nothing Transform）とは？仕組み・秘密分散との違い・派生方式とTypeScript実装

AONT（All-Or-Nothing Transform、オール・オア・ナッシング変換）は、暗号の分野で使われる秘密鍵を使わない可逆な前処理です。変換後のブロックが1つでも未知になると、元データの各ブロックの復元が計算量的に困難になります。1997年にRSA暗号の共同発明者であるRonald L. Rivestが発表しました。この記事はRivestの原論文、AONT-RSとCAONT-RSの原論文、IBMの公式資料を原文で確認し、TypeScriptの実装をNode.js v26.5.0で実行した結果を載せています。

まとめ：AONTは鍵を持たない全数しきい値の前処理、欠損に耐える分散はAONT-RSから

• AONTは暗号ではありません。秘密鍵を使わないので、全ブロックが揃えば誰でも元データに戻せます。
• 第一の動機は、40ビット鍵という輸出規制下でも総当たり攻撃を割に合わなくすることでした。攻撃者のコストは暗号文のブロック数倍になり、正規の送受信者は約3倍で済みます。
• 「RSAを強くするために考案された」という説明は因果が逆です。原論文はパッケージ変換を、RSA用の前処理OAEP（1994年）の特殊ケースと位置づけています。
• 分散保管の設計（誤り訂正を挟む、検査用の冗長ブロックを付ける、秘密分散とみなす）は、1997年の原論文の第5節にすでに書かれています。2011年のAONT-RSはこれを製品として仕上げた形です。
• AONT-RSはShamirの秘密分散と違って安全性が計算量的です。その代わり、総保管量が n 倍から約 n ÷ k 倍に下がります。
• 短いデータへの未対策のAONT-RS適用は避けてください。2016年の指摘はAONT-RSで小さい暗号文を分散する場合の2つの漏えい経路を対象としています。重複排除と両立させるCAONT-RSは、推測しやすいデータに辞書攻撃が通ります。

AONTの定義：秘密鍵を使わない可逆変換

原論文が示す3条件と、乱数化が必須になる理由

Rivestは原論文「All-Or-Nothing Encryption and the Package Transform」（FSE 1997）で、メッセージ列 m₁, …, m_s を疑似メッセージ列 m’₁, …, m’_s’ に写す変換 f が次の3条件を満たすとき、AONTと呼んでいます。

• 可逆であること（疑似メッセージ列から元のメッセージ列を得られる）
• 変換とその逆変換がどちらも多項式時間で計算できること
• 疑似メッセージのブロックが1つでも未知なら、どのメッセージブロックについても関数値の計算が計算量的に実行困難であること

3番目が「オール・オア・ナッシング」の本体です。原論文は「AONTは乱数化されていなければならない」とも注意しています。決定的な変換だと、既知平文攻撃で疑似メッセージが分かってしまうためです。Rivestのパッケージ変換では、この乱数化を毎回ランダムな鍵を選ぶことで実現します。

暗号化との違い：全ブロック取得者による鍵なし復元

原論文の表現は明快です。「the all-or-nothing transformation is not itself “encryption,” since it makes no use of any secret key information（AONTはそれ自体が暗号化ではない。秘密鍵の情報をまったく使わないからだ）」。AONTは誰でも実行でき、誰でも逆変換できる公開の変換です。秘匿を担うのは後段の暗号化、または全ブロックを1か所に集めさせない分散のほうです。

鍵をどこに置くかの話であれば、それはHashiCorp Vaultのようなシークレット管理の領域で、AONTの守備範囲とは別物です。

Rivestが1997年に示した動機とOAEPとの関係

原論文の書き出しは総当たり攻撃の話です。「Our primary motivation is to devise means to make brute-force search more difficult, by appropriately pre-processing a message before encrypting it（我々の第一の動機は、暗号化前にメッセージを適切に前処理することで総当たり探索を困難にする手段を考案することだ）」。背景には、56ビットのDES鍵がすでに心もとないという1996年の指摘と、輸出規制で40ビット鍵に縛られる状況がありました。

AONTを前処理に挟むと、攻撃者は鍵候補ごとに暗号文全体を復号しないと当たり判定ができません。原論文の例は8メガバイトのメッセージを40ビットDES鍵で送るケースで、攻撃の作業量は通常のCBCモードの約100万倍（約2²⁰倍）になります。原論文いわく「40ビット鍵ではなく60ビット鍵を破らされている感覚」です。正規の利用者が払う代償は全体で約3倍にとどまります。攻撃者と正規利用者でコストの増え方が非対称になる。これがAONTの設計思想です。

日本語の解説でよく見る「もともとRSA暗号の強度を上げるために考案された」は、原文と順序が合いません。第5節には確かにRSAが登場し、AONTはRSA暗号の前段でも有用だと書かれています。ただし続けて「パッケージ変換は、BellareとRogawayがoptimal asymmetric encryption（OAEP）の前処理として提案した方式の特殊ケースとみなせる」と述べています。OAEPは1994年に発表されたRSA用の前処理で、先にあるのはOAEPのほうです。OAEPがRSAのパディングとしてどう使われているかはRSA暗号の仕組みとパディングの選び方で解説しています。

パッケージ変換の計算手順と各ブロックの役割

Rivestが具体策として示したのがパッケージ変換（package transform）です。E をブロック暗号、K₀ を公開の固定鍵として、次のように計算します。

1. パッケージ変換用の鍵 K’ をランダムに選ぶ（原論文の例は128ビットのRC5鍵）
2. i = 1..s について m’_i = m_i XOR E(K’, i)
3. h_i = E(K₀, m’_i XOR i) を求め、最終ブロックを m’_s+1 = K’ XOR h₁ XOR … XOR h_s とする

前半はカウンタモードの暗号化と同じ形で、違いは鍵が毎回ランダムに選ばれる点です。その乱数鍵 K’ を、全ブロックから計算した値で隠して最終ブロックに同梱しています。逆変換では、先頭 s ブロックから h_i を計算し直して最終ブロックとXORし、K’ を取り戻してから各ブロックを元に戻します。ブロックが1つでも欠ければ K’ の復元に失敗し、全ブロックが読めなくなります。

K’ は秘密の共有鍵ではなく、疑似メッセージの中で開示される値です。そのため後段の暗号モードの鍵長制限（当時なら40ビット）に縛られない、と原論文は補足しています。

原論文の第5節にあったAONT-RSの原型

第5節（Discussion）は、後の分散ストレージの設計をほぼ先取りしています。原文の要点は次の3つです。

• 誤り伝播：「AONTは誤り伝播の性質がひどい」。暗号文の1ブロックが壊れると、ほぼ全メッセージブロックが壊れます。対策として「AONTと暗号化の間に誤り訂正の段を挟める」と書いています。
• 破損の検出：AONTをかける前に冗長ブロック（全ゼロのブロック、または先行ブロックの和）を付ければ、復号時に検証して破損した暗号文を検出できる、としています。冗長ブロックを当事者だけが知る秘密値で作れば、メッセージ認証にもなります。
• 秘密分散との関係：「パッケージ変換は s’ 個中 s’ 個のしきい値秘密分散とみなせる」。シェアがメッセージより短いので計算量的秘密分散にあたる、とも書いています（この関係を指摘したのはMihir Bellareだと謝辞にあります）。

誤り訂正を挟む、既知の値で破損を検出する、しきい値法として扱う。この3点は、14年後に発表されたAONT-RSの構成要素と重なります。なお「all-or-nothing」という名前はSilvio Micaliの提案だと謝辞に記されています。原論文は結論で「CBCの3倍かかるコストを2倍まで下げられるか」を未解決問題として残しました。

秘密分散との関係：AONT-RSがしきい値法になる仕組み

AONT-RSの構成：canaryの付加・暗号化・組織符号による分散

AONTにReed-Solomon符号を組み合わせて (k, n) しきい値法に仕立てたのがAONT-RSです。CleversafeのJason K. Reschとテネシー大学のJames S. PlankがFAST 2011の論文で発表しました。論文の図3が示す順序は次のとおりです。

1. 既知の固定値を持つ1ワード「canary」をデータ末尾に付ける
2. ランダム鍵 K を選び、canaryを含むデータを暗号化する（c_i = d_i XOR E(K, i+1)。E はAESなど）
3. 暗号化後の s+1 個のコードワードのハッシュ h をSHA-256などで取り、c_s+1 = K XOR h を末尾に付ける
4. このパッケージを組織符号（systematic）のReed-Solomon符号で n 個のスライスに分散し、k 個集まれば復元できるようにする

復元に使うスライスのビットが変化すると、高い確率で再計算したハッシュと復元鍵 K が変わり、canaryの不一致として破損を検出できます。論文自身はcanaryの出典をウイルス対策の文献に置いていますが、発想はRivestが第5節で書いた冗長ブロックと同じです。論文はAONTを (s+1, s+1) のしきい値法とみなせると説明しており、ここもRivestの記述と一致します。

Shamir法との比較：保管量は n 倍から約 n ÷ k 倍へ

式は論文のTable 1のままで、w_A はAONTのワード長、つまり鍵を隠す最終ブロック1ワード分の上乗せです。実装ではcanaryと分割用のパディングも加わりますが、b が大きければ誤差なので、実質は n ÷ k 倍です。1GBのファイルを3-of-6で置くなら、Shamir法は6GB、AONT-RSは約2GBになります。速度もほぼ変わりません。論文の実測（2011年）では、アーカイブストレージPOTSHARDSと同じ3-of-5構成で、AONT-RSが65.4MB/s、Shamir法が64.4MB/sでした。

IBM Cloud Object StorageのSecureSlice

CleversafeはIBMが2015年11月に買収を完了し、製品はIBM Cloud Object Storage（COS）へ引き継がれました。IBMのRedpaper REDP-5537は、COSのSecureSliceについて「uses an all-or-nothing-transform (AONT) to encrypt the data」と書いています。手順は整合性チェック値の付加、乱数鍵の生成、暗号化、ハッシュ計算、ハッシュと鍵のXOR、結果の付加の6段階で、AONT-RSの論文と同じ流れです。ソフトウェア3.14.6でAES-GCM-256が追加され、以後の新規vaultの既定になっています。なお同資料はAONTを「a type of encryption」と呼んでおり、鍵付きの暗号化まで含めてAONTと呼ぶ製品側の用法は、Rivestの定義とは異なります。

派生方式：OAEP型AONT・t-AONT・CAONT-RS

OAEP型と線形AONT：安全性の根拠が違う2系統

Rivestの後、AONTの構成は2つの方向に分かれました。Victor BoykoはCRYPTO ’99の論文で、OAEPがランダムオラクルモデルの下でAONTになることを示しました。同じ頃D. R. Stinsonは、暗号学的な仮定を置かない線形のAONTをDesigns, Codes and Cryptography誌（2001年）に発表しています。

Stinsonの系統はその後、組合せ論の研究対象になりました。IACR ePrint 2017/177が扱う (t, s, v)-AONT は、「s − t 個の出力だけでは、どの t 個の入力も完全に未確定」という強い条件で定義されます。2021年には、出力側と入力側の t を別々に設定する非対称AONTも提案されました（ePrint 2021/726）。本記事で詳しく扱う実装方式はRivest型とOAEP型です。後述するNoC向け研究では、準群に基づく別方式のAONTが使われています。

CAONT-RS：重複排除の仕組みと辞書攻撃のリスク

香港中文大学のMingqiang Li、Chuan Qin、Patrick P. C. LeeはUSENIX ATC 2015のCDStoreで、AONT-RSを2点変えたCAONT-RSを提案しました。1つはRivest型AONTをOAEP型AONTに置き換えたことです。小さなワードを何度も暗号化するRivest型より、大きな定数ブロックを1回暗号化するOAEP型のほうが速いためです。もう1つは、乱数鍵を秘密データのハッシュに置き換えたことです。同じ内容のデータは同じシェアになり、クラウド側で重複排除が効きます。論文は既存の秘密分散を使う構成と比べて70%のコスト削減を報告しています。

代償もはっきり書かれています。鍵がデータから決まるため、クラウド内の攻撃者は重複排除の状態を見て、候補を総当たりする辞書攻撃をかけられます。論文は「秘密が大きなメッセージ空間から選ばれていること」を前提にし、緩和策として鍵サーバーが発行する鍵への置き換えを挙げています。定型の帳票や設定ファイルのように中身を推測しやすいデータを、CAONT-RS型で重複排除してはいけません。

応用研究の現在地：通信の盗聴対策とチップ内ネットワーク

Rivest自身が1998年の「Chaffing and Winnowing」でAONTを使っています。1メガビットのメッセージをパッケージ変換し、1024ビットのブロックごとにMACを付けて送り、第三者が偽のブロック（chaff）を混ぜます。全ブロックを正確に選び出さないと復元できないので、chaffは本物より少なくて済みます。

最近の研究では、Weerasena、Randall、Mishraが2026年1月20日にarXiv 2601.13610を公開しました。SoC内のネットワーク（NoC）でパケットごとにAONTをかけ、重ならない複数経路に分けて送ることで、途中のルーターに盗聴されても復元できないようにしています。従来の暗号化と比べてオーバーヘッドを7.3分の1に減らせたと報告しています。2018年のPE-AONT（arXiv 1811.09144）も、一部の断片だけを暗号化して暗号化の量を減らす研究です。

TypeScriptによるパッケージ変換の実装と欠損・改変の検証

node:crypto だけで書くパッケージ変換（検査ブロック付き）

外部ライブラリなしで書けます。ブロック暗号 E にはAES-128を1ブロック単位で使い、K₀ は公開の固定鍵なのでゼロ埋めにしています。Rivestが第5節で書いた方法に従い、変換の前に全ゼロの検査ブロックを1つ足しました。

import { createCipheriv, randomBytes } from "node:crypto";

const BLOCK = 16;
const K0: Buffer = Buffer.alloc(BLOCK, 0x00); // 公開の固定鍵。秘密ではない

const ecb = (key: Buffer, block: Buffer): Buffer => {
  const c = createCipheriv("aes-128-ecb", key, null);
  c.setAutoPadding(false);
  return Buffer.concat([c.update(block), c.final()]);
};
const ctr = (i: number): Buffer => {
  const b = Buffer.alloc(BLOCK);
  b.writeUInt32BE(i, 12);
  return b;
};
const xor = (a: Buffer, b: Buffer): Buffer => {
  const o = Buffer.alloc(BLOCK);
  for (let i = 0; i < BLOCK; i++) o[i] = a[i] ^ b[i];
  return o;
};
const split = (buf: Buffer): Buffer[] => {
  const pad = BLOCK - (buf.length % BLOCK);
  const padded = Buffer.concat([buf, Buffer.alloc(pad, pad)]); // PKCS#7
  const out: Buffer[] = [];
  for (let i = 0; i < padded.length; i += BLOCK) out.push(padded.subarray(i, i + BLOCK));
  return out;
};

export function packageTransform(message: Buffer): Buffer[] {
  const K = randomBytes(BLOCK);                                    // 毎回引き直す
  const blocks = [...split(message), Buffer.alloc(BLOCK, 0x00)];   // 末尾に検査用のゼロブロック
  const pseudo = blocks.map((m, i) => xor(m, ecb(K, ctr(i + 1))));
  const last = pseudo.reduce((acc, mi, i) => xor(acc, ecb(K0, xor(mi, ctr(i + 1)))), K);
  return [...pseudo, last];                                        // 末尾が K を隠したブロック
}

export function recoverBlocks(pseudo: Buffer[]): Buffer[] {
  if (pseudo.length < 3 || pseudo.some((block) => !Buffer.isBuffer(block) || block.length !== BLOCK)) {
    throw new Error("復元失敗: ブロック数または長さが不正");
  }
  const body = pseudo.slice(0, -1);
  const K = body.reduce((acc, mi, i) => xor(acc, ecb(K0, xor(mi, ctr(i + 1)))), pseudo[pseudo.length - 1]);
  return body.map((mi, i) => xor(mi, ecb(K, ctr(i + 1))));
}

export function packageInverse(pseudo: Buffer[]): Buffer {
  const blocks = recoverBlocks(pseudo);
  const check = blocks.pop()!;
  if (!check.equals(Buffer.alloc(BLOCK, 0x00))) throw new Error("復元失敗: 検査ブロックが一致しない");
  const b = Buffer.concat(blocks);
  const n = b[b.length - 1];
  if (n < 1 || n > BLOCK) throw new Error("復元失敗: パディング長が不正");
  if (!b.subarray(b.length - n).equals(Buffer.alloc(n, n))) {
    throw new Error("復元失敗: パディング値が不正");
  }
  return b.subarray(0, b.length - n);
}

ECBモードが出てきますが、平文をECBで暗号化しているのではありません。カウンタ値 i を1ブロックだけ暗号化して鍵ストリームを作る、パッケージ変換の定義どおりの使い方です。

最終ブロックのゼロ置換による先頭平文への影響

Node.js v26.5.0 は型注釈付きの .ts をそのまま実行できます。上のコードと同じファイルに次を足して node aont.ts で動かしました。

const msg = Buffer.from("秘密分散の前処理としてAONTを使う");
const pseudo = packageTransform(msg);
console.log(`元データ ${msg.length} バイト -> 疑似メッセージ ${pseudo.length * BLOCK} バイト`);
console.log("復元:", packageInverse(pseudo).toString());

const lost = pseudo.slice(0, -1).concat(Buffer.alloc(BLOCK, 0x00)); // 最終ブロックを潰す
console.log("正常時の先頭ブロック:", recoverBlocks(pseudo)[0].toString("hex"));
console.log("欠損時の先頭ブロック:", recoverBlocks(lost)[0].toString("hex"));

let detected = 0;
for (let t = 0; t < 10000; t++) {
  const p = packageTransform(msg).map((b) => Buffer.from(b));
  p[1 + (t % 3)][t % BLOCK] ^= 0x01; // 2〜4番目のブロックの1ビットを反転
  try { packageInverse(p); } catch { detected++; }
}
console.log(`1ビット改変の検出: ${detected} / 10000`);

出力は「元データ 46 バイト -> 疑似メッセージ 80 バイト」「復元: 秘密分散の前処理としてAONTを使う」です。正常時の先頭ブロックは何度実行しても e7a798e5af86e58886e695a3e381aee5（「秘密分散の」のUTF-8の15バイトと、次の「前」の先頭1バイト）でした。欠損時の先頭ブロックは実行のたびに違う乱数値になります。潰したのは末尾の1ブロックなのに、K’ が復元できず、全ブロックの鍵ストリームが崩れるためです。

検査ブロックの評価：1ビット反転10,000試行で見逃し0件

最後の行は「1ビット改変の検出: 10000 / 10000」でした。比較のため、packageTransform のゼロブロック追加と packageInverse の検査ブロック照合を外し、パディング長（末尾1バイトが1〜16か）の検証だけにした版で、同じ1ビット反転を10,000回ずつ2回試しました。例外を出さずに壊れたデータを返した回数は638回と590回です。壊れた末尾バイトが偶然1〜16に収まる確率は16 ÷ 256 ＝ 6.25%なので、理論どおりの値です。乱数を使うので、回数は実行のたびに変わります。

パディングの検証は完全性の検査になりません。AONTの出力を保管・転送するなら、既知の値の検査ブロックか、AONT-RSのcanaryにあたる仕組みを必ず入れてください。改ざんまで防ぎたい場合は、Rivestが書いたとおり秘密値やMACを使った認証が別に必要です。

既存のライブラリを探すと、Rustのaont クレートが見つかります。ただしdocs.rsの版一覧では最新が2021年7月5日公開の0.1.1で、説明文の冒頭に「This crate is a very early stage of development」とあり、ハッシュにはSHA-1を使っています。この記事のコードは仕組みを確認する学習用です。本番で使うなら、方式の安全性評価と実装レビューを経たうえで、欠損・破損の動作試験に加えて入力検証と認証の設計まで確認してください。

採用判断：AONTが効く場面と、選ぶべきでない条件

短い平文への適用が危険な理由（2016年に指摘された2つの漏えい）

AONT-RSをそのまま小さいデータに適用してはいけません。Liqun Chen、Thalia M. Laing、Keith M. MartinはIACR ePrint 2016/1014（AFRICACRYPT 2017収録）で、小さい暗号文を分散すると情報が漏れる経路が2つあると指摘しました。同論文は対策と安全性証明を示し、誤ったシェアが混じっても復元できるロバスト版へ拡張しています。設定値やパスワード程度の短いデータを分散したいなら、素のAONT-RSを自前で実装せず、Shamir法を選んでください。

AONT-RSの性能：データ量で決まる暗号コストと、k・n で増える分散コスト

AONT-RSの論文の実測（OpenSSL 0.9.8k、ブロック長8KB）では、AES-256が143.30MB/s、SHA-256が160.03MB/s、両者を通すAONT全体で75.60MB/sでした。AONTの処理時間はデータ量だけで決まる一定のコストです。一方、分散の処理時間は k と n が大きくなるほど増え、その増え方はShamir法、Rabin法、AONT-RSの順に大きいと論文は説明しています。そのため1-of-6や2-of-6のように分散が軽い構成ではShamir法がAONT-RS（AES-256とSHA-256の組）より速く、比率1/6以外では k と n が大きくなるとAONT-RSが追い越します。自分の構成でどちらが速いかは、暗号・ハッシュ・符号化・通信の処理時間を分けて測って判断してください。どの数値もAES-NIが普及する前の2011年の測定なので、自環境で取り直す前提です。

AONTを選ぶべきでない条件：単一サイト保管・MPC入力・推測しやすいデータ

第一に、データを単一サイトに置くだけの構成です。全ブロックが同じ場所にあるなら、AONTは何も守りません。鍵管理サービスと暗号化の組み合わせのほうが確実です。

第二に、秘密計算（MPC）の入力共有です。AONT-RSのスライスは暗号文に対しては線形ですが、平文とはAESと乱数鍵で結ばれているので、平文に対する線形性はありません。シェアを足しても平文の和にはならないため、MPCにはShamir法や加法的秘密分散を使います。

第三に、カード番号や個人番号のような定型データを隠したいだけの場合です。番号を代替値に置き換えて業務システムで扱うことが目的なら、トークナイゼーションも候補になります。推測しやすいデータを重複排除したいからといってCAONT-RS型にすると、先に書いた辞書攻撃の条件にそのまま当てはまります。AONTが向くのは、複数サイトへ分散でき、鍵の保管場所を作りたくない大容量データです。

よくある質問

AONTと秘密分散は同じものですか？

同義ではありません。Rivestの原論文は、パッケージ変換を「s’ 個中 s’ 個のしきい値秘密分散とみなせる」と書いており、全ブロックが揃わないと復元できない計算量的な秘密分散にあたります。ただし1ブロックでも失えば復元できません。AONTの出力にReed-Solomon符号などを組み合わせると、k < n の構成で n 個中 k 個のスライスから復元できるようになります。日本語の説明で「AONTは秘密分散法の一つ」とされるのは、多くの場合この組み合わせ（AONT-RS）を指しています。

AONTだけでデータを秘匿できますか？

できません。原論文が「秘密鍵の情報を使わないので暗号化ではない」と明記しているとおり、疑似メッセージが全部揃えば誰でも元データに戻せます。秘匿するには、後段で通常の暗号化を行うか、分散保管して攻撃者が復元に必要なしきい値以上のスライスを集められない状況を作る必要があります。

AONTで変換するとデータサイズはどれくらい増えますか？

鍵を隠したブロック1個とパディングの分です。この記事の実装では検査ブロックも足したので、46バイトの平文が80バイトになりました（パディング込み3ブロック＋検査1＋鍵1）。分散まで含めると、Shamirの秘密分散が b バイトのファイルに nb バイトを要するのに対し、AONT-RSは n(b + w_A) ÷ k で済みます。

AONTで変換したデータは重複排除できますか？

通常のAONTは毎回乱数鍵を引くため、同じファイルでも出力が毎回変わり、重複排除は効きません。鍵をデータのハッシュから作るCAONT-RSなら重複排除できますが、中身を推測しやすいデータには辞書攻撃が通ります。データの種類が大きなメッセージ空間から選ばれていることを確認してから使ってください。

実装で使う暗号アルゴリズムとハッシュは何を選べばよいですか？

AONT-RSの論文はAES-256とSHA-256の組と、RC4-128とMD5の組を比較していますが、後者は2011年時点の選択肢で、いまは使いません。IBM COSも3.14.6以降はAES-GCM-256を既定にしています。AES-256系とSHA-256を基本にし、SHA-1を使う既存実装は避けてください。Rivestのパッケージ変換の側は、E に使うブロック暗号を自由に選べる設計です。

関連記事

• RSA暗号とは？仕組みと鍵長・パディングの選び方をOpenSSLの実装で解説
• HashiCorp Vaultとは？シークレット管理の仕組み・動的シークレット・Kubernetes連携と採用判断を実装者目線で解説
• 決済トークンとは？トークナイゼーションの仕組みと暗号化との違い・実装方式を開発視点で解説
• ゼロ知識証明（ZKP）とは？仕組みとzk-SNARKを実際に動かして解説
• 耐量子暗号とは：ML-KEMの仕組みとOpenSSL・SSHでの確認手順【2026年】