暗号化ディスクは、単にデータを読めなくするための仕組みではない。正しい鍵、正しいヘッダー、正しい形式理解、正しい実装がそろったときにだけ、閉じたデータを再び開ける仕組みである。この性質は、暗号化ディスクを安全にする一方で、長期運用では別の問題を生む。古い媒体が手元に残っていても、それを開くための形式互換性が失われれば、媒体は残っているのに中身へ到達できない。
既稿では、TrueCrypt 旧資産を GNU/Linux で保全すること、LUKS 暗号化媒体を作成手順だけでなく運用手順として扱うこと、保存を未来の時点で意味を取り出せる構造として捉えること、暗号化ディスクを長期運用と退役の問題として扱うことを整理してきた[1][2][3][4]。さらに、具体的な運用手順、自由ソフトウェアだけで扱える暗号化媒体の範囲、LUKS 暗号化ディスクの lifecycle も整理した[5][6][7]。本稿は、その系列の中で、cryptsetup に含まれる TCRYPT / VeraCrypt 互換コードを読む。
中心命題は単純である。cryptsetup の TCRYPT 互換コードは、TrueCrypt を復活させるためのコードではない。過去に作られた暗号化資産へ到達するための互換レイヤーである。古い形式を主系に戻さず、しかし必要なときに開ける経路は残す。この設計は、暗号化ディスクの長期運用において重要なレジリエンスである。
| 観点 | 本稿で扱うこと | 本稿で扱わないこと |
|---|---|---|
| 対象コード | cryptsetup / libcryptsetup に含まれる lib/tcrypt/tcrypt.c の責務と処理構造を扱う。 | TrueCrypt / VeraCrypt アプリケーション全体の再実装や GUI 機能は扱わない。 |
| 運用上の位置づけ | 既存 TCRYPT / VeraCrypt 資産へ到達するための互換経路として位置づける。 | TrueCrypt / VeraCrypt を新規主系として推奨する議論は扱わない。 |
| 技術説明 | ヘッダー読解、KDF 候補、cipher 候補、hidden volume、system encryption、dm-crypt mapping への接続を扱う。 | 暗号アルゴリズムの数学的証明や攻撃評価の詳細には踏み込まない。 |
| 一般化 | 暗号化媒体における形式互換性を、復元可能性と長期運用の問題として扱う。 | 保存媒体一般の全分野や、文書フォーマット一般の保存論までは広げない。 |
なお、本稿で扱う cryptsetup upstream の実装、保守主体、ライセンス表記、KDF 候補、cipher 候補は、2026 年 6 月時点で参照した情報に基づく。cryptsetup は継続的に更新されるプロジェクトであり、将来の main ブランチでは実装や表記が変わる可能性がある。そのため、詳細設計の断面を厳密に確認する場合は、本稿の公開日だけでなく、参照した release tag または commit も確認する必要がある。
1. 古い暗号化資産は、古くなっても消えない
TrueCrypt は、かつて暗号化ファイルコンテナーや暗号化デバイスを扱うための実用的な選択肢だった。現在の TrueCrypt 公式サイトは、TrueCrypt の利用を安全でないものとして警告し、BitLocker への移行手順を示す状態になっている[8]。2014 年の終了告知は当時大きく報じられ、TrueCrypt は保守終了した暗号化ソフトウェアとして扱われるようになった[9]。
しかし、保守終了したことと、過去に作られた暗号化資産が消えることは同じではない。過去に TrueCrypt 7.1a で作ったファイルコンテナー、外付け HDD、バックアップ媒体、退役ディスクは、世界中に残っている。個人のバックアップだけでなく、研究機関の古い媒体、企業の保管ディスク、法務・監査・フォレンジック用途の取得イメージにも、古い暗号化形式は残り得る。
暗号化していないファイルであれば、古いアプリケーションがなくても、ファイル形式を解析したり、部分的に復旧したりできる場合がある。暗号化ブロックデバイスでは事情が違う。ヘッダー形式、鍵導出方式、暗号方式、データ offset、sector size が分からなければ、ディスク上の byte 列は閉じたままである。媒体が生きていても、形式を開く実装が失われれば、データは実質的に失われる。
したがって、古い暗号化形式に対する互換コードは、単なる懐古ではない。新規利用を推奨しない形式であっても、過去資産へ到達するための出口として意味を持つ。ここで重要なのは、古い形式を主系に戻すことではない。古い形式を読み取り中心の互換経路へ移し、必要な期間だけ管理し、移行が終わった時点で退役させることである。
2. TCRYPT 互換は LUKS の一部ではなく、cryptsetup の形式ハンドラである
TCRYPT 互換について語るとき、まず用語を補正する必要がある。これは LUKS にマージされた機能ではない。cryptsetup / libcryptsetup に含まれる TCRYPT / VeraCrypt 形式対応コードである。LUKS1 / LUKS2 は cryptsetup が扱う中心的な暗号化メタデータ形式だが、cryptsetup が扱う形式は LUKS だけではない。
cryptsetup プロジェクトは、dm-crypt kernel module に基づくディスク暗号化を扱うための open-source utility であり、plain volumes、LUKS volumes、loop-AES、TrueCrypt including VeraCrypt extension、BitLocker、FileVault2 を supported formats として挙げている[10]。プロジェクトの構成説明でも、lib/tcrypt は TrueCrypt / VeraCrypt format の実装として位置づけられる[11]。
見かけ上は、同じ cryptsetup コマンドで LUKS も TCRYPT も扱えるため、TCRYPT が LUKS の内部機能であるように見えやすい。しかし内部構造としては、LUKS メタデータ処理と TCRYPT メタデータ処理は別の形式ハンドラである。cryptsetup は、Linux の暗号化ブロックデバイスを扱う入口として複数形式を束ねている。
| 対象 | 位置づけ | 本稿での扱い |
|---|---|---|
| LUKS1 / LUKS2 | Linux で広く使われる暗号化メタデータ形式であり、cryptsetup の中心的対象である。 | 本稿では主系運用の比較対象として扱う。 |
| TCRYPT / VeraCrypt | TrueCrypt / VeraCrypt 由来の暗号化形式であり、cryptsetup では別形式として扱われる。 | 本稿の主対象であり、互換コードの設計を読む。 |
| dm-crypt | Linux kernel 側で block device の暗号化 mapping を提供する基盤である。 | TCRYPT 形式から取り出した情報の接続先として扱う。 |
この区別は、運用判断でも重要である。LUKS を主系にすることと、TCRYPT 既存資産を cryptsetup から読めるようにすることは矛盾しない。前者は現在以降の標準形式を決める話であり、後者は過去資産への到達可能性を維持する話である。
3. なぜ、このようなニッチな互換コードが保守されているのか
cryptsetup の man page は、TCRYPT について重要な境界を示している。cryptsetup は TrueCrypt、tcplay、VeraCrypt 暗号化パーティションを Linux kernel API で mapping できる一方で、TCRYPT ヘッダーの生成や変更をサポートせず、device 上の TCRYPT ヘッダーを書き換えない[12]。これは、TCRYPT 対応が新規作成機能ではなく、既存ボリュームを開くための互換機能として設計されていることを示している。
このような互換コードが保守される理由は、暗号化資産の性質にある。暗号化ストレージでは、データ、鍵、形式、実装がそろって初めて復元できる。TrueCrypt が保守終了しても、過去に作られた暗号化媒体は残る。その媒体が必要になる場面は、日常的ではないかもしれない。しかし、必要になったときに代替が効きにくい。
ここでのニッチさは、趣味的な希少性ではない。退役媒体、長期保管媒体、古いバックアップ、調査対象ディスク、研究データのように、普段は目立たないが失われると困る領域のニッチである。暗号化媒体では、形式を読めないことが、データ消失とほぼ同じ意味を持つ。したがって、互換コードは過去資産の救済経路になる。
ただし、互換コードが存在することは、その形式を新規主系として使い続ける理由にはならない。cryptsetup が TCRYPT を open できることと、TrueCrypt / VeraCrypt を標準セットアップに入れ続けることは別である。互換性は、推奨ではない。この切り分けが、本稿全体の基礎である。
4. tcrypt.c は短く見えるが、暗号化処理を全部書いているわけではない
lib/tcrypt/tcrypt.c を見ると、主要機能が意外に短い範囲に収まっているように見える。しかし、そこで暗号化ストレージの全機能を自前実装しているわけではない。tcrypt.c が担っているのは、TCRYPT / VeraCrypt 形式のヘッダーを読み、KDF と cipher の候補を試し、復号済みヘッダーから必要なパラメータを取り出し、cryptsetup の共通層と dm-crypt へ渡すことである。
VeraCrypt の技術説明では、標準 volume header の復号時に、KDF と関連パラメータ、暗号方式、mode などが未知であり、可能な組み合わせを試す必要があると説明されている[13]。cryptsetup の tcrypt.c も同じ問題を実装上の構造として持つ。つまり、ヘッダーが復号されるまで、どの方式で作られた volume なのかは確定しない。
このため、tcrypt.c は KDF 候補テーブルと cipher 候補テーブルを持つ。パスフレーズと keyfile からヘッダー復号鍵を導出し、候補となる cipher chain と mode でヘッダーを復号し、magic と CRC が正しいかを確認する。正しい組み合わせが見つかると、master key、data offset、volume size、sector size などを取り出し、dm-crypt mapping に必要な情報へ変換する。
| 処理 | tcrypt.c の責務 | 委譲先 |
|---|---|---|
| ヘッダー解釈 | TCRYPT / VeraCrypt 固有のヘッダー位置、backup header、hidden volume、system encryption を扱う。 | 形式固有処理なので tcrypt.c が中心となる。 |
| 鍵導出候補 | PBKDF、hash、iteration count、VeraCrypt PIM の候補を選び、ヘッダー復号鍵を導く。 | 実際の crypto backend は cryptsetup 共通層に委譲する。 |
| 暗号方式候補 | AES、Serpent、Twofish などの cipher chain と mode 候補を試す。 | 暗号プリミティブそのものは backend と kernel 側に委譲する。 |
| block device 化 | ヘッダーから取り出した情報を dm-crypt 用のパラメータへ変換する。 | device-mapper table と実際の I/O は dm-crypt が担う。 |
この責務分離により、見た目より少ないコードで広い互換性が実現される。tcrypt.c は TrueCrypt / VeraCrypt 全体を再実装しているのではなく、形式固有の知識を cryptsetup の既存基盤へ接続する adapter である。
5. 保守主体とライセンスを見る
互換コードを長期運用上の根拠として見るなら、機能だけでなく、保守主体とライセンスも確認する必要がある。cryptsetup の SECURITY.md では current maintainer が Milan Broz であると示されている[14]。Milan Brož は Red Hat Research の profile でも full disk encryption や cryptsetup / LUKS などに関わる人物として紹介されている[15]。
tcrypt.c のファイル冒頭には、SPDX-License-Identifier: LGPL-2.1-or-later と、TCRYPT TrueCrypt-compatible and VeraCrypt volume handling という説明がある。著作権表記は 2012-2026 Red Hat, Inc. と 2012-2026 Milan Broz である[16]。つまり、このファイル単位では LGPL-2.1-or-later のコードとして置かれている。
一方で、cryptsetup プロジェクト全体は単一ライセンスではない。README.licensing は、プロジェクト内に GPL-2.0-or-later、LGPL-2.1-or-later、OpenSSL exception 付き LGPL、Apache-2.0、CC-BY-SA-4.0、Public Domain などが混在することを示す[17]。SPDX の LGPL-2.1-or-later は、GNU Lesser General Public License version 2.1 or later を表す識別子である[18]。
| 観点 | 確認できる内容 | 本稿での意味 |
|---|---|---|
| 保守主体 | cryptsetup upstream の current maintainer として Milan Broz が示されている。 | ニッチな互換機能であっても、upstream の管理下にある実装として扱える。 |
| ファイル単位ライセンス | tcrypt.c には LGPL-2.1-or-later の SPDX 表記がある。 | 当該ファイルは libcryptsetup 側のライブラリ実装として見るのが自然である。 |
| プロジェクト全体 | cryptsetup 全体はファイルごとの混在ライセンスで構成される。 | 全体を単一ライセンスだけで単純化せず、ファイル単位の表記を見る必要がある。 |
ここから分かるのは、tcrypt.c が単なる野良互換コードではないということである。古い暗号化形式の到達可能性を支えるコードが、cryptsetup upstream の中で、明示的なライセンス表示を持って保守されている。この事実は、長期運用でその互換経路をどう扱うかを考えるうえで重要である。
6. tcrypt.c の全体像
tcrypt.c の処理は、ヘッダーを読む、候補を試す、正しい組み合わせを見つける、dm-crypt に渡す、という流れで理解できる。cryptsetup の lib/setup.c では、TCRYPT は LUKS、plain、loop-AES、BitLocker、FileVault2 などと並ぶ形式の一つとして扱われる[19]。したがって、tcrypt.c は cryptsetup の中で TCRYPT / VeraCrypt 形式を担当する部品である。
処理の入口では、通常ヘッダー、backup header、hidden volume header、system encryption header のいずれを読むかが決まる。次に、パスフレーズと keyfile から key pool を作り、KDF 候補を順に試す。KDF 候補によりヘッダー復号鍵が導出されると、cipher 候補を順に試し、復号結果に正しい magic があるかを調べる。さらに CRC により、復号結果が偶然それらしく見えただけではないことを検証する。
この処理は、暗号化ヘッダーが持つ根本的な循環を解くためのものである。形式情報を知るにはヘッダーを読む必要がある。しかしヘッダーを読むには、形式情報の候補を先に試す必要がある。tcrypt.c は、この循環を候補探索によって解決する。
| 段階 | 代表的な処理 | 意味 |
|---|---|---|
| ヘッダー読み取り | TCRYPT_read_phdr が flags に応じて通常、hidden、backup、system のヘッダー位置を選ぶ。 | どの場所にあるメタデータを読むかを決める。 |
| 初期化と KDF 探索 | TCRYPT_init_hdr がパスフレーズ、keyfile、PIM、KDF 候補を扱う。 | ヘッダー復号に必要な鍵の候補を作る。 |
| cipher 探索 | TCRYPT_decrypt_hdr が cipher chain と mode の候補を試す。 | 正しい暗号方式でヘッダーが復号できるかを確認する。 |
| ヘッダー検証 | TCRYPT_hdr_from_disk が magic、CRC、size、offset、sector size を確認する。 | 復号結果が妥当な TCRYPT / VeraCrypt ヘッダーかを判断する。 |
| 有効化 | TCRYPT_activate が dm-crypt mapping に必要な情報を構成する。 | 復号済み block device として扱えるようにする。 |
この構造を押さえると、tcrypt.c の読み方が変わる。個々の関数名を追う前に、どの関数が形式情報を読むのか、どの関数が候補を試すのか、どの関数が検証するのか、どの関数が Linux kernel 側へ渡すのかを見るべきである。
7. KDF 候補と cipher 候補は、形式互換性の中心である
TCRYPT / VeraCrypt 互換の難しさは、単一の暗号方式に対応すれば終わる点にはない。TrueCrypt と VeraCrypt では、時代、設定、system encryption か通常 volume か、PIM があるかどうかによって、KDF、hash、iteration count、cipher chain、mode が変わる。VeraCrypt の header key derivation 説明では、header key が encrypted volume header の暗号化領域を復号するために使われ、その領域に master key などが含まれると説明されている[20]。
VeraCrypt では PIM、すなわち Personal Iterations Multiplier により、password、PIM、Key Derivation Function の組み合わせで iteration count を調整できる[21]。これは安全性と open / boot 時間の調整に関係する。tcrypt.c が VeraCrypt mode と PIM の扱いを持つのは、VeraCrypt 由来の volume を開くために、この分岐を無視できないからである。
cipher 側も同じである。VeraCrypt の技術情報は、Encryption Scheme、Modes of Operation、Header Key Derivation、Keyfiles、PIM、Volume Format Specification を体系的に説明している[22]。tcrypt.c の cipher 候補テーブルには、AES、Serpent、Twofish、Camellia、Kuznyechik と、それらの chained cipher、XTS、LRW、CBC 系 legacy mode が並ぶ。互換コードは、現在よく使う方式だけでなく、過去に作られた volume の分岐を記憶する場所でもある。
| 分類 | 例 | 互換コードで必要になる理由 |
|---|---|---|
| KDF / hash | PBKDF2 と RIPEMD160、SHA512、Whirlpool、SHA256、BLAKE2s-256、Streebog512 などの組み合わせがある。 | ヘッダー復号鍵を作る方式が volume ごとに異なるため、候補として試す必要がある。 |
| iteration count | TrueCrypt 系の固定回数、VeraCrypt 系の大きな回数、PIM による調整がある。 | 同じパスフレーズでも iteration count が違えば、導出されるヘッダー復号鍵は一致しない。 |
| cipher chain | AES 単体、Serpent、Twofish、Serpent-Twofish-AES などの chained cipher がある。 | データ暗号化方式と master key layout が異なるため、dm-crypt に渡す形式も変わる。 |
| mode | XTS、LRW、CBC 系 legacy mode がある。 | ヘッダー復号として認識できても、kernel 側が mapping として扱えるかは別問題になる。 |
ここで重要なのは、互換コードが過去の仕様分岐を背負うということである。形式の寿命が長くなるほど、過去に許容された方式が増える。現在の標準だけを残せば実装は簡単になるが、過去の volume は開けなくなる。互換性とは、過去の分岐をどこまで記憶するかという設計である。
8. 通常ヘッダー、hidden volume、system encryption、backup header の違い
TCRYPT / VeraCrypt 互換では、ヘッダーを読むという処理も単純ではない。VeraCrypt Volume Format Specification は、標準 volume header、hidden volume header、embedded backup header、system encryption における layout の違いを説明している[23]。この違いは、tcrypt.c のヘッダー読み取り位置選択に直接反映される。
通常 volume では、先頭付近の標準ヘッダーを読む。hidden volume では、外側 volume の中に隠された別の header があり、その位置を読む必要がある。backup header は volume 末尾側にあり、通常ヘッダーが失われたときの復旧経路になる。system encryption では、対象が partition であっても、ヘッダーが base device 側にある場合がある。
この複雑さは、TCRYPT / VeraCrypt が単なるファイルコンテナー形式ではないことに由来する。hidden volume、system encryption、backup header といった機能は、暗号化データの使い方と保全方法に関わる。そのため、互換コードは暗号方式だけでなく、メタデータ配置の互換性も持たなければならない。
| ヘッダー種別 | 役割 | 実装上の意味 |
|---|---|---|
| 通常ヘッダー | 標準 volume を開くための主ヘッダーである。 | 通常 open の最初の読み取り位置になる。 |
| hidden volume header | 外側 volume の中に置かれた隠し volume を開くためのヘッダーである。 | hidden 指定時に別 offset を読む必要がある。 |
| backup header | 主ヘッダー破損時に復旧経路となる埋め込み backup header である。 | backup 指定時には通常とは異なる位置を読む。 |
| system encryption header | system partition encryption に関係するヘッダーである。 | partition ではなく base device 側を見る必要がある場合がある。 |
この章から一般化できるのは、互換性とは暗号方式だけではないということだ。暗号化ストレージの互換性には、ヘッダー位置、backup の扱い、隠し領域、system encryption の layout まで含まれる。形式互換性とは、暗号パラメータ互換であると同時に、レイアウト互換でもある。
9. 詳細設計書：TCRYPT / VeraCrypt 互換処理
ここからは、tcrypt.c の処理を詳細設計書として整理する。目的は、コードの逐語解説ではなく、責務、データ構造、処理フロー、境界条件、依存関係を読める形にすることである。対象コードは lib/tcrypt/tcrypt.c を中心とし、cryptsetup / libcryptsetup の TCRYPT / VeraCrypt 形式ハンドラとして読む。
9.1 目的
本設計は、cryptsetup における TCRYPT / VeraCrypt 互換処理の構造を整理するものである。
対象コードは lib/tcrypt/tcrypt.c を中心とする。ここでいう TCRYPT 互換処理とは、TrueCrypt / VeraCrypt 形式の既存ボリュームを読み取り、パスフレーズおよび keyfile からヘッダー復号に必要な鍵を導出し、ヘッダー内の情報を検証したうえで、Linux の dm-crypt mapping として有効化する処理を指す。
本実装の目的は、TrueCrypt / VeraCrypt アプリケーションを再実装することではない。既存の TCRYPT / VeraCrypt ボリュームから必要な暗号パラメータと master key を取り出し、cryptsetup / libcryptsetup の既存基盤に接続することである。
9.2 適用範囲
本設計の対象範囲は次の通りである。
| 対象範囲 | 内容 |
|---|---|
| TCRYPT / VeraCrypt ヘッダーの読み取り | 通常ヘッダー、backup header、hidden volume header、system encryption header を読み取る。 |
| ヘッダー位置選択 | 通常ヘッダー、backup header、hidden volume header、system encryption header の位置を flags に応じて選ぶ。 |
| 鍵導出 | パスフレーズおよび keyfile からヘッダー復号鍵を導出する。 |
| KDF / hash / iteration count 候補管理 | TrueCrypt 系と VeraCrypt 系の候補を管理し、必要に応じて PIM を反映する。 |
| cipher chain / mode 候補管理 | 単一 cipher と chained cipher、XTS、LRW、CBC 系 legacy mode を候補として扱う。 |
| ヘッダー復号試行 | KDF 候補と cipher 候補を組み合わせ、復号結果を検証する。 |
| ヘッダー値検証 | magic、CRC、version、volume size、offset、sector size などを確認する。 |
| cryptsetup パラメータ設定 | 復号済みヘッダー情報から cipher spec、mode、key size などを設定する。 |
| dm-crypt mapping 構成 | master key、offset、size、cipher spec を使って dm-crypt mapping に接続する。 |
| 補助操作 | TCRYPT volume の activate、deactivate、dump、offset 取得処理を扱う。 |
対象外は次の通りである。
| 対象外 | 理由 |
|---|---|
| TrueCrypt / VeraCrypt 形式の新規作成 | 本実装は既存 volume を開くための互換処理であり、形式作成を目的にしない。 |
| TCRYPT ヘッダーの更新・書き換え | cryptsetup の TCRYPT 対応は on-device header の変更を対象にしない。 |
| パスフレーズ変更 | ヘッダー再暗号化や key material の更新を扱わない。 |
| ヘッダー再暗号化 | 既存ヘッダーを復号して読むことに集中し、書き戻しは行わない。 |
| VeraCrypt GUI 互換機能 | GUI やユーザー操作の再現ではなく、block device としての activation を目的にする。 |
| ファイルシステム処理 | 開いた block device 上の ext4、FAT、NTFS などは別層の責務である。 |
| 実際の block I/O 復号処理そのもの | 実データの透過的復号は dm-crypt と kernel 側に委譲される。 |
実際の暗号アルゴリズム処理、device-mapper 操作、メモリ安全処理、ログ出力、device 抽象化は cryptsetup の共通基盤および Linux kernel 側の dm-crypt に委譲する。
9.3 全体構成
TCRYPT 互換処理は、概念的には三層で構成される。
| 層 | 担当 | 説明 |
|---|---|---|
| TCRYPT 形式解釈層 | tcrypt.c | TCRYPT / VeraCrypt 固有のヘッダー位置、KDF 候補、cipher chain、legacy mode、hidden volume、system encryption などを解釈する。 |
| libcryptsetup 共通層 | cryptsetup 内部 API | device 抽象化、volume key 管理、ログ、エラー処理、安全なメモリ操作、activation API などを提供する。 |
| crypto backend / Linux kernel dm-crypt 層 | crypto backend と kernel | 実際の暗号プリミティブ、cipher mode、device-mapper table、block device としての I/O を担当する。 |
したがって、tcrypt.c の中心責務は、TCRYPT 形式を dm-crypt で扱えるパラメータへ変換することである。
9.4 主要データ構造
KDF 候補テーブルは、TCRYPT / VeraCrypt ヘッダー復号に使用する KDF 候補を定義する静的テーブルである。各要素は、legacy mode かどうか、VeraCrypt mode かどうか、KDF 名、hash 名、標準 iteration count、VeraCrypt PIM 用の定数、VeraCrypt PIM 用の乗数を持つ。このテーブルにより、実装は、ユーザーが明示した方式だけを使うのではなく、候補を順に試し、正しいヘッダー magic と CRC が得られる組み合わせを探す動作を実現する。
TrueCrypt 系では PBKDF2 と RIPEMD160 / SHA512 / Whirlpool / SHA1 などが候補になる。VeraCrypt 系では、より大きな iteration count や PIM による調整、SHA256、BLAKE2s、Streebog などの候補が含まれる。
単一 cipher 定義は、cipher chain 内の一つの暗号アルゴリズムを表す。主な要素は、cipher 名、key size、IV size、key offset、IV offset または tweak key offset、追加 key 領域サイズである。TCRYPT では、ヘッダー内の key material から各 cipher に必要な鍵領域を切り出す必要がある。key offset、IV offset、追加 key 領域サイズは、その切り出し位置を定義する。
cipher chain 定義は、TCRYPT / VeraCrypt で使用される cipher chain と mode の組み合わせを表す。主な要素は、legacy mode かどうか、chain count、chain 全体の key size、cryptsetup 上の cipher 名、mode 名、最大 3 要素の cipher 配列である。この構造により、単一 AES-XTS だけでなく、Twofish-AES、Serpent-Twofish-AES、AES-Twofish-Serpent などの chained cipher を表現する。
mode としては、主に XTS、LRW、CBC 系 legacy mode が扱われる。ただし、すべての mode が activation 可能とは限らない。ヘッダー復号には必要でも、kernel dm-crypt が対応しない legacy mode は activation 時に拒否される。
9.5 主要関数設計
TCRYPT_read_phdr は、TCRYPT 物理ヘッダーを device から読み取り、復号初期化処理へ渡す入口である。この関数は、指定された flags に応じてヘッダー読み取り位置を切り替える。主な分岐は、system encryption header、hidden volume header、hidden volume backup header、hidden volume old offset、normal backup header、normal header である。
system encryption の場合、対象 device が partition であれば base device を取得し、partition の外側にある system header を読む。これは TCRYPT system encryption ではヘッダー位置が通常の partition 内部とは異なるためである。読み取りに成功した場合、TCRYPT_init_hdr を呼び出してヘッダー復号と検証を行う。失敗した場合はヘッダー領域をゼロクリアし、エラーを返す。
TCRYPT_init_hdr は、暗号化された TCRYPT ヘッダーを復号し、正しい KDF / cipher / mode の組み合わせを探索する中心処理である。この関数の入力は、読み取られた暗号化ヘッダー、パスフレーズ、keyfile、flags、PIM などである。
| 順序 | TCRYPT_init_hdr の処理 |
|---|---|
| 1 | パスフレーズ領域とヘッダー復号鍵領域を安全メモリとして確保する。 |
| 2 | パスフレーズを初期 key pool へ配置する。 |
| 3 | keyfile が指定されている場合、keyfile pool 処理を行う。 |
| 4 | KDF 候補テーブルを順に走査する。 |
| 5 | flags に合わない legacy / VeraCrypt 候補を除外する。 |
| 6 | PIM が指定されている場合は VeraCrypt の規則に基づいて iteration count を調整する。 |
| 7 | PBKDF によりヘッダー復号鍵を導出する。 |
| 8 | TCRYPT_decrypt_hdr により cipher 候補を試す。 |
| 9 | magic と CRC が正しい組み合わせを見つけた場合、TCRYPT_hdr_from_disk によりヘッダー値を CPU endian へ変換し、params を設定する。 |
| 10 | 一時鍵、パスフレーズ、key material を安全に消去して終了する。 |
この関数は、TCRYPT 形式の、どの KDF / cipher で作られたかがヘッダー復号前には分からないという性質を、候補探索により吸収する。
TCRYPT_pool_keyfile は、TCRYPT / VeraCrypt keyfile を key pool に混合する処理である。keyfile を最大長まで読み取り、読み取った byte stream に対して CRC32 を更新しながら key pool へ加算する。複数 keyfile がある場合も、同じ pool に順次混合される。この処理の目的は、keyfile の内容を直接暗号鍵として使うのではなく、パスフレーズと同じ key derivation 入力領域に混ぜ込むことである。読み取り後の keyfile buffer と CRC 値は安全に消去される。
TCRYPT_decrypt_hdr は、導出済みヘッダー復号鍵を使って、cipher 候補を順に試す処理である。この関数は cipher 候補を走査する。ユーザーが cipher を指定している場合は、その cipher 名に合わない候補を除外する。legacy mode が許可されていない場合は legacy 候補を除外する。
各 cipher 候補について、暗号化ヘッダーを作業用領域にコピーし、mode に応じて復号処理を行う。cbci 系 mode の場合は TCRYPT_decrypt_cbci を使う。それ以外の場合は、chain の後ろから前へ TCRYPT_decrypt_hdr_one を適用する。復号後、ヘッダー内の magic を確認する。TrueCrypt 形式の magic が検出されれば成功とする。VeraCrypt mode が有効な場合は、VeraCrypt 形式の magic も成功条件とする。復号に失敗した候補は破棄され、次の候補へ進む。
TCRYPT_decrypt_hdr_one は、単一 cipher によるヘッダー復号を担当する。mode 名から backend に渡す mode 部分を切り出し、必要に応じて IV を構成する。CBC 系では whitening を除去し、LRW 系では IV を調整する。その後、backend 用の key を構成し、cryptsetup の cipher backend を使ってヘッダー領域を復号する。XTS、LRW、CBC では key material の配置が異なるため、key copy 処理が mode ごとの差異を吸収する。
TCRYPT_decrypt_cbci は、CBC 系の chained cipher 復号を担当する。backend が TCRYPT 固有の outer CBC 処理を直接提供しないため、この関数は ECB cipher を複数初期化し、block ごとに chain の逆順で復号し、IV と XOR することで CBC 復号を実装する。この処理は、TCRYPT legacy mode 互換のために必要である。通常の XTS 系 activation とは異なり、TCRYPT 固有のヘッダー復号処理に近い位置づけである。
TCRYPT_hdr_from_disk は、復号済みヘッダーを検証し、disk endian から CPU endian へ変換し、cryptsetup 用 params を設定する処理である。主な検証は、ヘッダー本体 CRC32、key 領域 CRC32、version、sector size、volume size、hidden volume size、master key offset、master key size である。CRC が不一致の場合は不正ヘッダーとして扱う。変換後、crypt_params_tcrypt に hash 名、key size、cipher 名、mode 名を設定する。これにより、後続の activation 処理がヘッダーから得られた暗号方式を利用できるようになる。
TCRYPT_activate は、復号済み TCRYPT ヘッダーをもとに dm-crypt mapping を作成する処理である。この関数は、まずヘッダーが復号済みであることを確認する。ヘッダーが読み込まれていない状態では activation を拒否する。次に sector size を検証する。sector size が cryptsetup の想定 sector 単位と整合しない場合は activation 不可とする。さらに、kernel が対応しない legacy mode は拒否する。特に tcrypt 系 legacy mode は、ヘッダー復号として扱えても、kernel mapping としては有効化できない場合がある。
| volume 種別 | TCRYPT_activate での size 決定 |
|---|---|
| system encryption | 対象 device 全体を扱う。 |
| hidden volume | hidden volume size を使う。 |
| 通常 volume | volume size を使う。 |
その後、data offset、IV offset、cipher spec、volume key を構成し、device-mapper 用の active device 情報を組み立てる。最終的には、libcryptsetup の activation 経路を通じて dm-crypt mapping を作成する。これにより、TCRYPT / VeraCrypt volume は Linux 上で通常の block device として扱えるようになる。
TCRYPT_deactivate は、作成済み mapping を解除する処理である。この処理自体は TCRYPT 固有の複雑なロジックを持たず、cryptsetup の共通 deactivate 処理に委譲する。
TCRYPT モジュールは、復号済みヘッダーから data offset、IV offset、volume key、volume key size、header dump 情報を取得する補助関数を持つ。これらは、tcryptDump 相当の情報表示や、activation 時の device-mapper table 構成に利用される。
9.6 処理フロー
通常の TCRYPT open 処理は、次の順序で進む。
| 順序 | 通常 open 処理 |
|---|---|
| 1 | 呼び出し元が CRYPT_TCRYPT 形式として cryptsetup を初期化する。 |
| 2 | ユーザーがパスフレーズ、keyfile、flags、PIM などを指定する。 |
| 3 | TCRYPT_read_phdr が device から該当ヘッダーを読む。 |
| 4 | TCRYPT_init_hdr が KDF 候補を試す。 |
| 5 | 各 KDF 候補について、ヘッダー復号鍵を導出する。 |
| 6 | TCRYPT_decrypt_hdr が cipher 候補を試す。 |
| 7 | magic と CRC が正しい候補を採用する。 |
| 8 | TCRYPT_hdr_from_disk が params を確定する。 |
| 9 | TCRYPT_activate が dm-crypt mapping を構成する。 |
| 10 | mapping 成功後、利用者は復号済み block device としてアクセスする。 |
hidden volume の場合、ヘッダー読み取り位置が通常 volume と異なる。CRYPT_TCRYPT_HIDDEN_HEADER が指定されると、TCRYPT_read_phdr は hidden volume header offset を読む。通常の hidden header で失敗した場合、旧 offset も試す。backup header が指定されている場合は hidden backup header offset を読む。復号後の activation では、device size として hidden volume size を使う。
system encryption の場合、ヘッダーは partition 内ではなく、base device 側の固定位置に存在しうる。そのため、対象が partition であれば base device path を取得し、base device から system header offset を読む。activation 時には、system encryption 特有の offset 処理が必要になる。ヘッダーが partition 外にあるため、data device と metadata device の関係を通常 volume と同じようには扱えない。
backup header が指定された場合、通常ヘッダー位置ではなく backup header offset を読む。これは通常 volume と hidden volume の両方に存在する。通常 backup header と hidden backup header は flags によって区別される。
9.7 エラー処理設計
本実装では、device open 失敗、header read 失敗、KDF 不一致、cipher 不一致、magic 不一致、CRC 不一致、unsupported sector size、unsupported legacy mode、kernel feature 不足、memory allocation 失敗、keyfile open / read 失敗を区別する。
復号候補探索中の失敗は、ただちに最終失敗とはしない。KDF / cipher 候補が複数あるため、一つの候補で失敗しても次の候補へ進む。一方、device open、memory allocation、keyfile read、activation 不可条件などは、処理継続が意味を持たないため、エラーとして返す。ヘッダー復号に失敗した場合、読み取ったヘッダー領域はゼロクリアされる。
9.8 セキュリティ設計
本実装は、次の観点でセキュリティ上の配慮を持つ。
| 観点 | 設計上の配慮 |
|---|---|
| 一時情報の消去 | 一時鍵、パスフレーズ、keyfile buffer、IV、backend key などは、処理後に安全消去される。 |
| 復号成功判定 | ヘッダー復号の成功判定は magic だけに依存せず、CRC 検証により復号結果の整合性を確認する。 |
| 候補制限 | TCRYPT / VeraCrypt の仕様上必要な KDF / cipher 候補を試すが、flags によって legacy mode や VeraCrypt mode を制限できる。 |
| activation 制限 | kernel が対応しない mode は activation 時に拒否し、安全に block device として公開できない構成を排除する。 |
| mapping 前検証 | device-mapper mapping を作成する前に sector size、volume size、offset、cipher spec を確認する。 |
ただし、本実装は TCRYPT / VeraCrypt 形式そのものの安全性を改善するものではない。既存形式を読み取る互換実装であり、暗号設計上の評価は元形式に依存する。
9.9 互換性設計
本実装は、TrueCrypt と VeraCrypt の差異を、magic の違い、KDF / hash / iteration count の違い、VeraCrypt PIM の扱い、keyfile pool length の違い、cipher / mode 候補の違い、legacy mode の扱い、hidden volume header offset の違い、system encryption header offset の違いで吸収する。
TrueCrypt 由来の legacy mode については、ヘッダー復号のために実装されているものがある。一方で、kernel dm-crypt が対応できない mode については activation できない。したがって、本実装の互換性は、ヘッダーを認識できることと、実際に mapping として有効化できることを分けて考える必要がある。
9.10 責務分離
tcrypt.c が持つべき責務は、TCRYPT / VeraCrypt 固有仕様の吸収、ヘッダー位置決定、KDF 候補選択、keyfile pool 処理、ヘッダー復号、ヘッダー検証、params 構築、activation に必要な TCRYPT 固有パラメータの算出である。
tcrypt.c が持つべきでない責務は、汎用 device 操作の再実装、汎用暗号アルゴリズムの再実装、dm-crypt table 操作の直接実装、LUKS メタデータ処理、ファイルシステム処理、TCRYPT 形式の作成・更新処理である。この分離により、TCRYPT 固有の互換処理を小さな範囲に閉じ込めつつ、実際の暗号処理と device 管理は既存基盤へ委譲できる。
9.11 制約事項
本実装には制約がある。TCRYPT / VeraCrypt volume の新規作成は扱わない。ヘッダー更新、パスフレーズ変更、keyfile 変更は扱わない。ヘッダー復号できても、kernel が mode をサポートしなければ activation できない。legacy mode は flags により明示的に許可されない限り候補から除外される。VeraCrypt mode も flags により明示的に扱われる。hidden volume は通常 volume と異なる header offset と volume size を持つため、通常 volume と同一視できない。system encryption は metadata device と data device の関係が通常 volume と異なる。
9.12 保守上の注意点
KDF 候補や cipher 候補を追加・変更する場合は、対応する cryptographic backend が存在すること、kernel dm-crypt が activation に必要な mode をサポートすること、ヘッダー復号だけで必要な処理か activation まで必要な処理かを区別すること、legacy mode を通常候補に混ぜないこと、VeraCrypt PIM の iteration count 計算を壊さないこと、key offset / IV offset / chain key size の整合性を崩さないこと、CRC 検証を迂回しないこと、一時鍵と buffer の安全消去を維持することを確認する必要がある。
特に chained cipher の key layout は、単純な key size の合算ではなく、mode ごとの offset と extra key 領域を含む。ここを誤ると、ヘッダー復号に失敗するだけでなく、誤った mapping を作る危険がある。
9.13 設計上の要点
本実装の本質は、TCRYPT / VeraCrypt を Linux 上で新しい主形式として扱うことではない。本質は、既存の TCRYPT / VeraCrypt volume から、dm-crypt に必要な情報を復元することである。
| 要点 | 説明 |
|---|---|
| 形式固有の知識 | TCRYPT / VeraCrypt 固有の知識は tcrypt.c に集約する。 |
| 暗号アルゴリズム | 暗号アルゴリズム自体は backend に委譲する。 |
| block device 化 | block device 化は dm-crypt に委譲する。 |
| 候補制限 | ユーザーが指定しない限り、legacy mode や VeraCrypt mode を不用意に広げない。 |
| 読み取り互換 | 読み取り互換を中心に置き、形式作成やヘッダー更新には踏み込まない。 |
この設計により、比較的少ないコード量で、TCRYPT / VeraCrypt 既存資産を cryptsetup の標準操作体系に接続している。
10. dm-crypt へ渡すということ
tcrypt.c の設計を理解するには、dm-crypt の位置づけも確認する必要がある。Linux kernel documentation は、dm-crypt を device-mapper target として説明し、kernel crypto API を使って block device の透過的な暗号化を提供するものとしている[24]。device-mapper は、kernel 内で block device を mapping する仕組みであり、dm-crypt はその暗号化 target である[25]。
つまり、tcrypt.c が最終的にやることは、TCRYPT / VeraCrypt volume をユーザーランドだけで復号することではない。ヘッダーから取り出した master key、cipher spec、offset、size を使って、dm-crypt が扱える mapping を作ることである。mapping が作られると、利用者には復号済み block device のように見える。
ここで、ヘッダー復号とデータ復号は分けて考える必要がある。ヘッダー復号は、どの鍵と方式で volume を開くかを知るための処理である。データ復号は、開かれた mapping に対して block I/O が行われるたびに kernel 側で処理される。tcrypt.c は前者を中心に担当し、後者は dm-crypt に委譲する。
dm-integrity のような device-mapper target は、block device の完全性保護を扱う別の層である[26]。本稿の主題は TCRYPT 互換であり、完全性保護そのものではない。しかし、暗号化ディスク運用が機密性だけでなく、形式互換性、完全性、復元確認、退役判断まで含む広い問題へ接続することは、ここからも分かる。
11. このコードがやらないこと
tcrypt.c は TCRYPT / VeraCrypt のすべてを扱うコードではない。これは、機能不足というより、責務を絞った互換コードである。cryptsetup の man page は、TCRYPT header は暗号化されているため有効な passphrase と keyfiles が必要であり、cryptsetup はヘッダー variant を認識する一方で、いくつかの legacy cipher chain には制限があると説明している[12]。また、tcryptDump は認識可能な TCRYPT device の header 情報を dump するための機能として説明される[27]。
ここで重要なのは、認識できること、dump できること、mapping として有効化できること、形式を作成・更新できることが、それぞれ別である点である。tcrypt.c は主に既存 volume を開く方向に設計されている。TCRYPT volume の新規作成、ヘッダー更新、パスフレーズ変更、keyfile 変更、ヘッダー再暗号化、GUI 機能、ファイルシステム処理は対象外である。
| 機能 | tcrypt.c の位置づけ | 運用上の意味 |
|---|---|---|
| 既存 volume を開く | 中心的な対象である。 | 過去資産へ到達するための互換経路になる。 |
| ヘッダー情報を表示する | dump 系の補助機能として扱われる。 | 媒体調査や移行前確認に役立つ。 |
| 新規 volume を作る | 対象外である。 | 新規主系として TCRYPT を増やす設計ではない。 |
| ヘッダーを書き換える | 対象外である。 | 既存ヘッダーを変更せず、読み取り互換へ寄せている。 |
古い形式への対応は、全機能再実装である必要はない。長期運用で必要なのは、読むこと、確認すること、移行すること、必要なら退役することである。tcrypt.c は、そのための最小だが重要な経路を提供している。
12. 読めることと、主系として使うことは違う
TCRYPT / VeraCrypt 互換が存在することは、TrueCrypt / VeraCrypt を新規主系として使い続ける理由にはならない。Debian の古い man page では、cryptsetup が historical loopaes と TrueCrypt compatible volumes をサポートすると説明されている[28]。その後の Debian man page では、loop-AES、TrueCrypt、VeraCrypt、BitLocker compatible volumes に limited support があると説明されている[29]。ここからも、cryptsetup は LUKS だけでなく互換形式を扱ってきたが、それは主系形式として推奨することとは別である。
標準セットアップに TrueCrypt / VeraCrypt の自動導入を残し続けると、新規環境の標準構成が曖昧になる。LUKS2 を主系にするのであれば、通常の Debian setup では LUKS 関連の現行運用に寄せる方がよい。一方で、TrueCrypt / VeraCrypt の個別インストーラーや cryptsetup の TCRYPT 互換機能まで消してしまうと、過去資産への到達経路が弱くなる。
したがって、合理的な分離は、標準構成からは外し、必要時の互換経路として残すことである。これは、古い形式を無条件に残すことでも、即座に捨てることでもない。新規主系、互換バックアップ、読み取り中心アーカイブ、移行対象、退役候補を分けて扱う設計である。
| 分類 | 意味 | TrueCrypt / TCRYPT 旧資産の扱い |
|---|---|---|
| 新規主系 | 今後も標準として増やす構成である。 | 該当しない。LUKS2 など現行主系へ寄せる。 |
| 互換バックアップ | 過去資産へ到達するために残す経路である。 | 該当する。必要時に cryptsetup の TCRYPT 互換で確認する。 |
| 読み取り中心アーカイブ | 内容確認や移行のために保持するが、積極的には更新しない構成である。 | 該当し得る。書き込み運用は慎重に分離する。 |
| 移行対象 | 現行形式へ内容を移す対象である。 | 該当する。LUKS + ext4 などへ段階移行する。 |
| 退役候補 | 移行と確認が終われば廃止できる構成である。 | 該当する。読めることを確認したうえで退役条件を決める。 |
読めることは、使い続けることではない。互換コードがあるから新規利用してよいのではなく、互換コードがあるから過去資産を救済できる。この区別が、古い暗号化形式を安全に扱うための基礎である。
13. 暗号化ディスクの長期運用では、形式互換性もレジリエンスである
バックアップや長期保存では、データを複製するだけでは不十分である。物理媒体管理の既稿では、守るべきものは媒体そのものではなく、必要な時点で意味あるデータ構造を再構成できる可能性であると整理した[30]。暗号化ディスクでは、この復元可能性に形式互換性が強く関わる。
暗号化媒体の復元可能性は、媒体、接続経路、パスフレーズ、keyfile、ヘッダー、対応ソフトウェア、kernel 機能、ファイルシステム、手順書、台帳の組み合わせで決まる。どれか一つが欠けても、復元作業は止まる。特にヘッダーと形式実装は、暗号化 block device の入口そのものである。
cryptsetup / dm-crypt 系の保守は、単に機密性だけを扱うものではない。full disk encryption における data integrity protection の議論も、暗号化ストレージが長期運用、完全性、復元可能性の問題へ接続することを示している[31]。本稿の主題は TCRYPT 互換であり、完全性保護そのものではない。しかし、暗号化ディスクを一回作って終わりの設定ではなく、継続的な運用資産として扱うという点では同じ問題圏にある。
形式互換性は、レジリエンスである。障害時、移行時、退役時、監査時に、過去資産へ到達できるかどうかは、暗号化ディスク運用の継続性を左右する。強い暗号で閉じることだけでは十分ではない。必要なときに、正しい手順で、正しく開けることが必要である。
14. 古い形式を主系に戻さず、到達可能性だけを残す
tcrypt.c の存在は、古い暗号化形式を延命する話ではない。過去資産への到達可能性を保つ設計の話である。TrueCrypt / VeraCrypt を新規標準として増やすのではなく、既に存在する TCRYPT / VeraCrypt volume を、必要なときに cryptsetup から開ける可能性を残す。この位置づけが最も重要である。
技術の退役は、消すことだけではない。主系から外し、互換経路へ移し、読み取り中心にし、必要なら現行形式へ移行し、移行済みであることを確認してから退役する。この段階を踏むことで、古い形式への過剰依存を避けながら、過去資産の喪失も避けられる。
tcrypt.c は、そのような運用判断を支える小さな実装である。コードの中には、KDF 候補、cipher 候補、hidden volume、backup header、system encryption、legacy mode、VeraCrypt PIM、CRC 検証、dm-crypt mapping への接続が詰め込まれている。しかし、その目的は複雑なものを増やすことではない。古い形式を、必要な範囲で、現在の Linux 環境へ接続することである。
暗号化ディスクの長期運用における成熟した判断とは、古いものを無条件に残すことでも、即座に捨てることでもない。役割を変えて管理することである。TrueCrypt / TCRYPT は新規主系ではない。しかし、既存資産へ到達するための互換バックアップ経路としては意味がある。cryptsetup の tcrypt.c は、その地味だが重要な経路を実装している。
参考文献
- id774, TrueCrypt 資産を GNU/Linux で保全する（2026-05-16）. https://blog.id774.net/entry/2026/05/16/4773/
- id774, LUKS 暗号化の手順と運用（2026-05-11）. https://blog.id774.net/entry/2026/05/11/4746/
- id774, 未来の自分に意味を残す（2026-05-12）. https://blog.id774.net/entry/2026/05/12/4750/
- id774, 暗号化ディスクを長期運用するための設計（2026-05-30）. https://blog.id774.net/entry/2026/05/30/4818/
- id774, 暗号化ディスク運用手順を整理する（2026-05-31）. https://blog.id774.net/entry/2026/05/31/4829/
- id774, 自由ソフトウェアだけで暗号化媒体をどこまで扱えるか（2026-06-03）. https://blog.id774.net/entry/2026/06/03/4849/
- id774, A Practical Lifecycle Guide to Operating LUKS Encrypted Disks（2026-06-07）. https://blog.id774.net/entry/2026/06/07/4864/
- TrueCrypt, TrueCrypt. https://truecrypt.sourceforge.net/
- Brian Krebs, True Goodbye: ‘Using TrueCrypt Is Not Secure’（2014-05-29）. https://krebsonsecurity.com/2014/05/true-goodbye-using-truecrypt-is-not-secure/
- cryptsetup project, README.md. https://gitlab.com/cryptsetup/cryptsetup/-/raw/v2.8.6/README.md
- cryptsetup project, CONTRIBUTING.md. https://gitlab.com/cryptsetup/cryptsetup/-/raw/v2.8.6/CONTRIBUTING.md
- cryptsetup project, cryptsetup(8). https://man7.org/linux/man-pages/man8/cryptsetup.8.html
- VeraCrypt, Encryption Scheme. https://veracrypt.io/en/Encryption%20Scheme.html
- cryptsetup project, SECURITY.md. https://gitlab.com/cryptsetup/cryptsetup/-/raw/v2.8.6/SECURITY.md
- Red Hat Research, Milan Brož. https://research.redhat.com/blog/project_member/milan/
- cryptsetup project, lib/tcrypt/tcrypt.c. https://gitlab.com/cryptsetup/cryptsetup/-/raw/v2.8.6/lib/tcrypt/tcrypt.c
- cryptsetup project, README.licensing. https://gitlab.com/cryptsetup/cryptsetup/-/raw/v2.8.6/README.licensing
- SPDX, GNU Lesser General Public License v2.1 or later. https://spdx.org/licenses/LGPL-2.1-or-later.html
- cryptsetup project, lib/setup.c. https://gitlab.com/cryptsetup/cryptsetup/-/raw/v2.8.6/lib/setup.c
- VeraCrypt, Header Key Derivation, Salt, and Iteration Count. https://veracrypt.io/en/Header%20Key%20Derivation.html
- VeraCrypt, Personal Iterations Multiplier (PIM). https://veracrypt.io/en/Personal%20Iterations%20Multiplier%20%28PIM%29.html
- VeraCrypt, Technical Details. https://veracrypt.io/en/Technical%20Details.html
- VeraCrypt, VeraCrypt Volume Format Specification. https://veracrypt.io/en/VeraCrypt%20Volume%20Format%20Specification.html
- The Linux Kernel documentation, dm-crypt. https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html
- The Linux Kernel documentation, Device Mapper. https://docs.kernel.org/admin-guide/device-mapper/index.html
- The Linux Kernel documentation, dm-integrity. https://docs.kernel.org/admin-guide/device-mapper/dm-integrity.html
- cryptsetup project, cryptsetup-tcryptDump(8). https://man7.org/linux/man-pages/man8/cryptsetup-tcryptDump.8.html
- Debian manpages, cryptsetup(8), stretch. https://manpages.debian.org/stretch/cryptsetup-bin/cryptsetup.8.en.html
- Debian manpages, cryptsetup(8), bullseye. https://manpages.debian.org/bullseye/cryptsetup-bin/cryptsetup.8.en.html
- id774, バックアップ・リカバリー戦略における物理媒体管理（2026-05-10）. https://blog.id774.net/entry/2026/05/10/4743/
- Milan Broz, Mikulas Patocka, Vashek Matyas, Practical Cryptographic Data Integrity Protection with Full Disk Encryption Extended Version（2018）. https://arxiv.org/abs/1807.00309