耐量子暗号で日記を守る ― 暗号化日記ツール開発はじめました

耐量子暗号を使って日記エントリを暗号化するCLIツールの開発を始めた。仮称 pq-diary。名前はそのうち変えるかもしれない。なぜこのツールを作ろうと思ったのか、どんな技術スタックで作っているのかをまとめる。

なお、この記事では暗号技術の専門用語がいくつか出てくるので、先に簡単に整理しておく。

耐量子暗号 (Post-Quantum Cryptography / PQC) ― 将来の量子コンピュータでも解読が困難とされる暗号技術の総称。現在広く使われている暗号 (RSA など) は量子コンピュータによって破られる可能性があるため、それに代わる新しい暗号方式として研究・標準化が進んでいる
NIST ― アメリカ国立標準技術研究所。暗号アルゴリズムの国際的な標準化を行っている機関で、2024年8月に耐量子暗号の最初の標準規格 (FIPS 203 / 204 / 205) を正式に発行した
FIPS ― NIST が発行する連邦情報処理標準。政府機関だけでなく、民間でも広く暗号技術の基準として参照されている

開発の動機

既存ツールのセキュリティ意識の低さ

世の中には日記・ジャーナリングツールが多数あるが、セキュリティに真剣に向き合っているものは驚くほど少ない。多くのツールは日記データを平文で保存するか、あっても申し訳程度の暗号化しか施していない。日記には極めて個人的な情報が含まれるのに、その保護が軽視されている現状に不満があった。

AIエージェント時代のファイル侵害リスク

決定的だったのは Claude Code のようなAIコーディングエージェントの登場だ。これらのツールはPC上のファイルに広くアクセスしながら作業する。非常に便利だが、裏を返せばローカルファイルへの侵害経路が格段に広がったことを意味する。

悪意のあるプロンプトインジェクションや、意図しないファイル読み取りによって、平文の日記が流出するシナリオは現実味を帯びている。「平文で日記を書く」という行為自体に抵抗を感じるようになった。

もちろんエージェント側にも対策はある。Claude Code にはサンドボックスモードがあり、ファイルアクセスやネットワーク通信を制限できる。しかしそれは使えるツールや機能に制約が掛かるというトレードオフと引き換えだ。エージェントの利便性を最大限に活かしつつセキュリティも確保するには、エージェント側の制限だけに頼るのではなく、機密情報そのものを暗号化して保護するというアプローチも必要になる。攻撃面が広がった時代には、守る側も多層的に構える必要がある。

Harvest Now, Decrypt Later への備え

さらに Harvest Now, Decrypt Later (HNDL) という攻撃シナリオもある。

現時点では解読できない暗号データを収集・保存しておく
将来、量子コンピュータが実用化された段階で復号する

正直なところ、HNDL攻撃の標的になるほどの機密情報を個人で抱えている人はほとんどいないだろう。しかし演算能力は日増しに向上しており、今日の「十分な暗号強度」が10年後も通用する保証はない。それなのに、そもそも暗号化という手段すら取り入れていないツールが大半であるという現状は問題だと感じた。どうせ暗号化するなら、将来にわたって破られにくい暗号を選びたい。これが耐量子暗号を採用した理由だ。

pq-diary の概要

pq-diary は Rust で書かれた CLI ツールで、以下の暗号アルゴリズムを組み合わせて使っている。

項目	内容	役割
対称暗号	AES-256-GCM	日記データ本体の暗号化・復号。現在最も広く使われている暗号方式のひとつ
鍵導出	Argon2id	パスワードから暗号鍵を生成する。総当たり攻撃に強い
PQC鍵交換	ML-KEM-768 (FIPS 203)	量子耐性のある鍵交換。暗号化された通信路を確立するために使う
PQC署名	ML-DSA-65 (FIPS 204)	量子耐性のある電子署名。データが改ざんされていないことを検証する
メッセージ認証	HMAC-SHA256	データの完全性を確認するためのチェックサム

ざっくり言うと、AES-256-GCM でデータを暗号化し、ML-KEM-768 で鍵のやり取りを保護し、ML-DSA-65 でデータの改ざんを検知する。暗号化・鍵交換・署名のすべてで量子耐性のあるアルゴリズムを使う設計だ。

アーキテクチャ

プロジェクトは Cargo workspace によるモノレポ構成で、2つのクレートに分かれている。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


pq-diary/
├── core/   # pq-diary-core (library)
│   └── src/
│       ├── crypto/       # 暗号プリミティブ群
│       │   ├── secure_mem.rs   # SecureBuffer, MasterKey
│       │   ├── kdf.rs          # Argon2id
│       │   ├── aead.rs         # AES-256-GCM
│       │   ├── kem.rs          # ML-KEM-768
│       │   ├── dsa.rs          # ML-DSA-65
│       │   └── hmac_util.rs    # HMAC-SHA256
│       ├── vault/        # Vault I/O・設定
│       ├── entry.rs      # エントリCRUD
│       ├── error.rs      # エラー型
│       └── lib.rs
└── cli/    # pq-diary (binary)
    └── src/
        └── main.rs       # CLIインターフェース

core にすべてのドメインロジックを、cli には薄い I/O ラッパーだけを置く。将来的に UniFFI 経由でモバイル(Swift/Kotlin)やデスクトップ向けの GUI アプリに展開することも視野に入れた設計だ。

セキュリティ設計のポイント

メモリ保護

暗号鍵や平文データがメモリ上に残り続けるのは危険だ。pq-diary では複数のレイヤーで対策している。

SecureBuffer ― Drop 時に自動ゼロ化される Box<[u8]>
ZeroizingKey ― 32バイト鍵専用のゼロ化ラッパー
MasterKey ― すべての鍵素材を束ね、Drop で一括消去
SecretBox ― Debug 出力やログから鍵を隠す

将来的には mlock / VirtualLock によるスワップ防止や、PR_SET_DUMPABLE=0 によるコアダンプ抑制も実装予定。

Vault 設計

日記データは vault.pqd というバイナリファイルに暗号化して保存する。

Vault = Single Source of Truth: vault.pqd が正本、entries/*.md はキャッシュ
Zero-knowledge on disk: エディタの一時ファイルも含め、平文はディスクに書き込まない
メタデータも秘匿: vault.toml には最小限の設定のみ、タイムスタンプ等は含めない

開発手法

pq-diary の開発では Kairo (要件駆動) と TDD を組み合わせたワークフローを採用している。

1
2
3
4
5
6


要件定義 (EARS記法)
  → 技術設計 (データフロー図・インターフェース定義)
    → タスク分割 (1日単位)
      → TDD Red (失敗するテスト作成)
        → TDD Green (最小実装)
          → TDD Refactor (品質改善)

全9スプリントの Phase 1 に分割されていて、各スプリントにはドキュメント化された仕様・設計・タスクがある。

現在のステータス

Sprint 1〜2 の基盤部分がほぼ完了した段階。

コンポーネント	状態
エラー型 (16バリアント)	完了
セキュアメモリ型	完了
CryptoEngine	完了
Argon2id 鍵導出	完了
AES-256-GCM 暗号化	完了
ML-KEM-768 鍵カプセル化	完了
ML-DSA-65 署名	完了
HMAC-SHA256	完了
CLI コマンド構造	完了
Vault I/O	Sprint 3 で実装予定
エントリ CRUD	Sprint 4 で実装予定

暗号プリミティブはすべてテスト済みで、次は Vault のバイナリフォーマット実装に進む。

今後の計画

Phase 1 (Sprint 3〜9) ではコア機能を順次実装していく。Obsidian の利用者が違和感なく移行できるよう、[[wiki]] リンクやインポート機能など、Obsidian と互換性のある形での実装を意識している。

S3: Vault バイナリフォーマット v4 と設定管理
S4: エントリの CRUD 操作と CLI 連携
S5: デイリーノート・テンプレート・[[wiki]] リンク
S6: 正規表現検索・統計・Obsidian インポート
S7: アクセス制御ポリシーと Claude 連携
S8: Git 同期 (匿名著者・タイムスタンプ難読化)
S9: セキュリティ強化と統合テスト

Phase 2 ではバックグラウンドデーモンやXOR分割鍵保管のほか、「デジタル遺産」機能も構想している。

これは、信頼できる複数の人にそれぞれキーフレーズを渡しておき、万が一のことがあった場合に、特定のエントリだけを部分的に開示できる仕組みだ。別に人生に絶望しているとかではないのだが、自分に何かあったとき、見られたくないものは全部消えて、見せたいものだけが残る ― そういう選択肢があってもいいのではないかと思った。日記という極めて私的なデータだからこそ、死後の扱いまで自分でコントロールできるべきだろう。

リポジトリ

開発の進捗は GitHub で追える。

sudolifeagain/pq-diary

量子コンピュータの実用化はまだ先かもしれないが、「今のうちに備えておく」ことに価値がある。進捗があればまた記事にする。

注意事項

pq-diary はあくまで概念実証として公開しているプロジェクトだ。「耐量子暗号を日記ツールに組み込むとどうなるか」という技術的な実験であり、実用的なセキュリティ製品として提供しているわけではない。

開発にはエージェントコーディングを活用しており、NISTの標準規格 (FIPS 203/204) などの各種論文・仕様書を読み込ませたうえで設計・実装を行っているが、AIが生成した暗号ロジックの正しさを完全に保証することはできない。本ソフトウェアの使用によって情報の漏洩やその他の損害が発生したとしても、開発者は責任を負えるものではないので、その点はご了承いただきたい。