はじめに
sops + age で暗号化したファイルについて、
「もし age ファイルそのものが漏えいしても、NVIDIA H200 のような高性能GPUを複数並べれば突破できるのでは？」
と気になることがあります。
結論から言うと、通常の sops + age 運用、特に age の X25519 受信者方式を前提にすると、age ファイル単体の漏えいから GPU で現実的に突破するのはかなり難しい と考えてよいでしょう。
age でいう 「受信者」 は、その暗号化ファイルを復号できる相手を指します。
理由は単純に「暗号が強いから」だけではありません。
本質は、攻撃者が直面する問題が、GPUで大量に候補を並列試行しやすい種類の問題ではないことにあります。
この記事では、sops と age の仕組みを整理しながら、
「なぜ H200 を複数使っても現実的な突破が難しいのか」を Qiita 向けに整理します。
先に結論
先に要点だけまとめると、次の通りです。
- age は各ファイルを 128-bit の file key で暗号化する
- その file key は age ヘッダ内で 受信者ごとに別々にラップされる
- X25519 受信者方式では、秘密鍵がなければ file key を正しく取り出せない
- 実際の暗号対象のデータは、HKDF-SHA-256で導出した鍵を使って、ChaCha20-Poly1305で暗号化・保護される
- したがって、漏えいした age ファイル単体から「GPUで候補を回す」形に落とし込みにくい
- H200 を複数台並べても、秘密鍵探索や file key 総当たりが現実的な作業になるわけではない
つまり、H200 が速いこと と age ファイルを現実的に突破できること は別問題です。
H200 は確かに強い
まず前提として、H200 自体は非常に強力なGPUです。
H200 は 141GB の HBM3e メモリ、4.8TB/s のメモリ帯域を持ち、さらに FP64 で 34 TFLOPS、Tensor Core FP64 で 67 TFLOPS といった高い計算性能も備えています。LLM や HPC のような、大量並列計算や大規模メモリアクセスが効く用途ではかなり強い構成です。
ただし、ここで重要なのは、H200 が強いのは「GPUに向いた問題」に対してである という点です。
たとえば、
- 大量の行列演算
- ハッシュの大量試行
- パスワード候補の並列探索
- 一定の構造を持つ brute force
のような問題ではGPUの強さが効きます。
逆に、秘密鍵がないとそもそも正しい候補検証に進みにくい設計に対しては、「速いGPUを増やせば突破できる」とはなりません。
age は何で守っているのか
age の仕様では、各ファイルは 128-bit の対称 file key で暗号化されます。
この file key は 16バイトの CSPRNG 出力として生成し、複数ファイルで再利用してはいけない とされています。
そのうえで、age ファイルは大きく2つに分かれます。
-
ヘッダ
- file key を受信者向けにラップして持つ
- 最後に HMAC-SHA-256 ベースの MAC が付く
-
payload
- 実際のデータ
- HKDF-SHA-256 で導出した鍵を使い、ChaCha20-Poly1305 で暗号化される
つまり、攻撃者が age ファイルを手に入れても、まず必要なのは ヘッダに入っているラップ済み file key を正しく取り出すこと です。
payload だけ眺めても、正しい file key がなければ意味のある平文にはなりません。
X25519 受信者方式では、何が必要なのか
ここが一番重要です。
age の X25519 受信者方式では、受信者の秘密鍵は 32バイトの CSPRNG 出力から生成され、そこから対応する公開鍵が作られます。
暗号化時には、送信側が毎回新しい一時鍵を生成し、受信者公開鍵との共有秘密を計算します。さらに、その共有秘密から HKDF-SHA-256 で wrap key を導き、ChaCha20-Poly1305 で file key を保護します。
つまり、攻撃者が age ファイルだけを持っていても、普通は次のどちらかがないと前に進めません。
- age の秘密鍵
- あるいは、その秘密鍵と同等の復号能力
ここが大事です。
この構造では、攻撃者が「候補を大量にGPUで回して file key を試す」より前に、X25519 の秘密鍵が必要な壁に当たります。
ここを「H200を何枚積めば現実的か」という話に落とし込むのはかなり無理があります。
では、GPUで何を総当たりするのか
「GPUで突破する」という話は、通常は 試すべき候補が明確に大量にある ときに意味を持ちます。
たとえば、
- 弱いパスワードの総当たり
- ハッシュ値に対する辞書攻撃
- 候補空間が比較的小さい秘密の探索
のようなケースです。
しかし、age の X25519受信者方式 では、age ファイル単体から攻撃者が得るのは、基本的に次のような情報です。
- ラップ済み file key
- payload の暗号文
- ヘッダ MAC
それだけで 「これをGPUで片っ端から試せばよい」 という単純な形にはなりません。
少なくとも、通常の運用で 秘密鍵を持たない攻撃者 にとっては、GPU向きの総当たり問題に落ちにくい のが本質です。
弱いパスワード総当たりのように、各試行を独立に大量並列化しやすい問題とは性質が異なる、という点が重要です。
たとえ H200 級 GPU を使っても、「1秒にどれだけ試せるのか」は前提次第ですが、かなり甘く見て毎秒 $10^{12}$回、もっと保守的に毎秒 $10^9$ 回の試行ができると仮定しても、128-bit の総当たりには約 $10^{19}$ 年〜$10^{22}$ 年かかります。
H200 級 GPU を使えるとしても、「長く回せば何とかなる」と言えるような規模ではありません。
sops は何をしているのか
sops の文脈でも考え方は同じです。
sops は、ファイル全体を各マスター鍵で直接暗号化するというより、まず データキー を使って内容を暗号化し、そのデータキーを各マスター鍵で保護する構造です。READMEでも、sops はデータキーを各マスター鍵で保護し、必要に応じて key service を通じて encrypt / decrypt するモデルだと説明しています。
また、sops は各 leaf value を AES256_GCM で暗号化し、整合性確認のための情報も持ちます。
つまり、漏えいした sops ファイルから平文に届くには、結局そのデータキーを復号できる鍵が必要 です。age をマスター鍵として使っているなら、その age 側の鍵管理が突破口になります。
言い換えると、sops + age の強度を崩したいなら、GPUで暗号文を殴るというより、鍵管理や運用を崩した方が現実的 です。
「無理筋」に近い理由を整理する
ここまでを Qiita 向けに整理すると、age ファイル単体漏えいからの GPU 突破が無理筋に近い理由は次の通りです。
1. file key 自体が強い
age の file key は 128-bit で、毎回 16バイトの CSPRNG 出力から生成されます。
これ自体、雑な総当たりに向くような世界ではありません。
2. payload は認証付き暗号で守られる
payload は ChaCha20-Poly1305 で暗号化され、鍵は HKDF-SHA-256 で導出されます。
正しい鍵がなければ、正しく復号できたかどうかを都合よく試せる構造ではありません。
3. X25519 受信者方式は秘密鍵なしで試しにくい
X25519 受信者方式では、ラップ済み file key を外すには、基本的に対応する秘密鍵が必要です。
ここは「H200を複数台並べれば何とかなるか」という話に落とし込みにくい壁です。
4. sops も結局はデータキー防御
sops 側も、データキーをどう守るかの構造です。
暗号文だけを持った攻撃者にとって、結局のボトルネックは データキーや file key を復号できる鍵があるかどうか に戻ります。
量子計算機なら突破できるのか
ここで気になるのが、「では量子計算機なら age ファイルを突破できるのか？」という点です。
結論から言うと、長期的には age の X25519 受信者方式は量子耐性があるとは言えません。
理由は、age の受信者方式が公開鍵暗号として X25519 に依存しているためです。公開鍵暗号は、将来的に十分大規模な量子計算機が実現した場合、現在の前提のままでは安全と言い切れません。NIST も、量子計算機は将来的に現在広く使われている公開鍵暗号を破る可能性があるとして、ポスト量子暗号への移行を進めています。
一方で、ここで重要なのは 「何が弱くなり、何がすぐに無意味になるわけではないのか」 を分けて考えることです。
age の構成を大まかに見ると、
- 受信者に file key を届ける部分
→ X25519 を使う公開鍵暗号の領域 - 実際の payload を暗号化する部分
→ ChaCha20-Poly1305 や HKDF-SHA-256 を使う共通鍵暗号・鍵導出の領域
に分かれています。age の仕様でも、X25519・HKDF-SHA-256・ChaCha20-Poly1305・HMAC-SHA-256 が使われています。
このうち、量子時代に特に問題になりやすいのは、X25519 に依存する受信者部分 です。
つまり、将来的に「暗号学的に意味のある規模の量子計算機」が実現した場合、age ファイル単体の漏えいに対しても、今日より厳しい前提で見なければならなくなる 可能性があります。NIST はそのために、量子計算機を持つ攻撃者に対しても安全と考えられる ML-KEM などの標準化を進めています。
ただし、ここで誤解しやすいのは、「量子計算機がある = すぐ age が現実的に突破される」ではない という点です。
現時点で公開されている量子計算機は、少なくとも一般に想定される実務環境で現代暗号を破れる段階には達していません。少なくとも、現在の公開情報ベースでは、現代の主要公開鍵暗号を実用的に破れるような量子計算機はまだ存在していない、という理解が妥当です。
さらに、age の payload 側で使われる共通鍵暗号については、量子計算機があるとしても「即ゼロになる」わけではありません。一般に、量子計算は共通鍵暗号やハッシュに対しても影響を与えますが、公開鍵暗号のように構造ごと崩れる話とは性質が違います。つまり、量子時代の age を考えるときは、まず X25519 受信者方式の将来リスクを意識する のが筋です。
そのため、この記事の結論は次のように整理できます。
- 今この瞬間に、H200 を何台並べても age ファイル突破が現実的になるわけではない
- ただし、将来的な大規模量子計算機の時代まで見据えるなら、X25519 受信者方式は長期保存向けに無条件で安心とは言えない
- 長期保管が前提の重要情報では、将来的に ポスト量子暗号ベースの仕組み への移行を視野に入れるべき
つまり、GPU 時代の脅威と、量子時代の脅威は分けて考える必要がある ということです。
今回の記事で扱っている「H200 を複数並べても無理筋」という話は、あくまで現在の現実的な GPU ベース攻撃に対する整理であり、量子耐性そのものを保証する話ではない、という位置づけになります。
また、長期保存が前提の秘密情報では、今は解読できなくても暗号文だけを保存しておき、将来の量子計算機で復号を狙う という考え方にも注意が必要です。
いわゆる Store Now, Decrypt Later のリスクを考えると、「現在のGPUでは無理筋」という話と、「長期保存にどこまで安心できるか」は分けて考える必要があります。
ただし、絶対安全ではない
ここは重要です。
この記事で言いたいのは 「H200複数台での age ファイル単体突破は現実的でない」 であって、「sops + age は絶対安全」 ではありません。
実際に危ないのは次のようなケースです。
- 秘密鍵そのものが漏れた
- 復号済みの端末が侵害された
- age のパスフレーズモードを使っていて、そのパスフレーズが弱い
- sops の運用で鍵管理が甘い
- 秘密を置いた端末や CI が侵害された
特に、age には X25519 受信者方式だけでなく、scrypt を使うパスフレーズ型 もあります。
こちらは「パスフレーズの強さ」が前面に出るので、弱いパスフレーズなら話が変わります。今回の話は、あくまで sops + age の X25519 受信者方式 を中心にしています。
結局、どこを守るべきか
技術的に見ると、sops + age で本当に重要なのは、暗号文の見た目そのものより 秘密鍵の保管と運用 です。
- age秘密鍵をどこに置くか
- 復号できる端末をどう守るか
- CI/CD にどう渡すか
- バックアップや同期先に秘密鍵が混ざっていないか
- 端末侵害時にどう切り離すか
ここを誤ると、H200 を何台並べるか以前に、運用面から破綻する可能性があります。
逆に言えば、鍵管理が適切で、漏れたのが暗号化済み age ファイルだけ なら、そこから GPU で現実的に突破するのはかなり厳しい、というのがポイントです。
まとめ
sops + age の暗号強度を「H200を複数並べたら突破できるのか」という観点で見ると、結論はかなり明快です。
通常の sops + age、特に age の X25519 受信者方式を前提にすると、age ファイル単体の漏えいから GPU で現実的に突破するのはかなり難しいと考えられます。
理由は、H200 が弱いからではありません。
攻撃者が直面する問題が、GPUで大量試行しやすい形に落ちにくい からです。
age は 128-bit file key、X25519、HKDF-SHA-256、ChaCha20-Poly1305、HMAC-SHA-256 で構成されており、sops も結局はデータキーとマスター鍵の管理の問題に帰着します。
だからこそ、sops + age を使うときに本当に気をつけるべきなのは、
- 暗号化ファイルそのものより
- 秘密鍵の保管
- 復号端末の保護
- 運用の分離
です。
GPU性能の話を気にするのは大事ですが、実際の防御では
「何を暗号で守れていて、どこから先は運用の問題になるのか」
を切り分ける方が、ずっと重要だと思います。
関連記事