まえがき

linuxにおいてファイルシステム作成後にも利用可能な仮想ファイルシステム形式の暗号化ファイルシステムといえば、EncFSとeCryptFSだ。EncFSのほうが昔からあるが、eCryptFSはUbuntuが（LUKSではなく）使っているので一般化しているのかもしれない。

EncFSもeCryptFSも日本語のドキュメントに乏しい。それどころか、英語でさえあまり見つからない。まして、両者がどう違うのか、という話になると全くだ。そこで、私が色々試してみたところをまとめることにしようと思う。

基本的な暗号化強度と暗号化方式

EncFSがAESとBlowfishをサポートするのに対し、AES, Blowfish, DES3EDE, twofish, cast6, cast5と多彩な形式をサポートするのがeCryptFS。ブロックサイズはEncFSが指定可能で、eCryptFSはブロックサイズは暗号化方式ごとに固定。キーサイズはそれぞれがサイズは異なるものの選択は可能。

暗号化鍵としてはパスフレーズとopensslを両者サポートする。

暗号化の機能

EncFSは「ファイル名の暗号化(block/stream)」「ファイル名のファイルパスに基づく暗号化」「ファイルを暗号化する際にランダムなヘッダバイトを入れることで同一の内容であっても暗号化の結果が同一にならないようにする」といった機能がある。一方、eCryptFSはファイル名を暗号化するかどうかのみ聞かれる。

両方共にplaintext passthroughがオプショナルだが、これが何を意味するかが分からない。

eCrypsFSのほうは結構ややこしく、Ubuntuフォーラムをみるとファイル名暗号の復号化ができずレスキューできないことについて述べられている。それが示されるFNEK Signatureなのだろう。文章をみる限りでは~/.ecryptfsをどこかにバックアップしておけば復号化できるように見えるが、実際のところは分からない。

その他の機能

EncFSは--extpass=programというオプションがある。これはprogramの標準出力をパスワードとみなす、というもの。これを使うとパスフレーズを入力せずにパスフレーズが使えるため、手動で入力するのであればパスフレーズなどよりもはるかに複雑な方法を利用できる。単純にcatであっても、どのファイルをcatしたか、という予測は選択次第ではかなり難しい。たとえばhistoryなどで読まれてしまうというリスクはあるにせよ、通常は分からない。

しかしこの威力は別の暗号化されたボリュームにそのためのスクリプトを書いてしまう、という方法だろう。例えばeCryptFSなりLUKSなりでホームディレクトリを暗号化しておき、ログインスクリプト（例えば.profileや.xinitrc）でマウントする、というようなことも可能。もちろん、その場合はオフライン暗号強度はEncFSの鍵とベースとなる暗号化ファイルシステムの鍵強度のウィーケストリンクとなる。

特徴

ファイル名暗号化した場合、どちらも暗号化後のファイル名が長くなるため、ベースとなるファイルシステムよりもファイル名の長さが制限される。256byteファイル名の場合、EncFSは190byte、eCryptFSは144byteに制限される。

また、EncFSはEncFSディレクトリ直下の.encfs6.xmlが暗号化の定義となっており、それがあるディレクトリがEncFSディレクトリとなる。このファイルと暗号化ファイルをコピーすればバックアップが可能。一方、eCryptFSは暗号化情報をファイル自身に持たせる。そのため、暗号化ファイルのみをコピーすればバックアップが可能。

しかしながら、eCryptFSはこのためにファイルサイズがかなり大きくなる。.encfs6.xmlはそれほど大きくないので不思議だが。7バイトのテキストが12kBほどになる。このため、MHディレクトリのような小さなファイルが大量にあるケースでは容量をかなり圧迫する。

どちらも元のファイルに一対一で対応した暗号化ファイルが作られる。そのため、マウントせずに暗号化ディレクトリをコピーすればバックアップがとれる。

EncFSはマウントしたユーザー以外はrootであってもアクセスできない。かならず利用するユーザーでマウントする必要があり、ユーザーのプライベートなデータ以外を置くことはできない。また、EncFSファイルシステムの中のディレクトリをマウントポイントにすることはできず、EncFSのマウントを入れ子にすることはできない（EncFSファイルシステムの中にEncFSファイルシステムを置くことはできる。マウントされた暗号化ファイルシステムのディレクトリをマウントポイントとしてマウントすることはできない）。

eCryptFSはこのような制限はなく、/や/homeをマウントすることも可能。

AESとBlowfish

一般には暗号化が速いのがTwofishとCAST5、復号化が速いのがBlowfishだと言われている。だが、実際は暗号化するデータのサイズ、バッファサイズ、そして内容にもよるので、一概には言えない。大きなデータに対してはBlowfishよりもAESのほうが高速であると言われている。逆に3DESは非常に強力だが、遅い。AES+Twofish+Serpentよりも遅いというのだから。

SSHのようなストリームの場合はBlowfishが高速だが、ブロック暗号ではそうとも言えない。BlowfishよりもAESのほうが強力であると見られているため、SSHと比べじっくりとりくむことができるディスクデバイスの暗号化はAESのほうがいいかもしれない。一方、メジャーなAESは解読しようとしている人が多いので解読されるリスクが高いという考え方もあるが、多分それは杞憂だろう。

AESの128bitは不十分だと思われる。192bitは速度と安全性のバランスがよく、安全性を確保するには256bitにすべきだろう。128bitは解読が可能であり、192bitは解読される可能性がある（ただし、並のクラスタでは生きてるうちには解読されない。スーパーコンピュータなら解読可能だろうし、計算機の進化や量子コンピュータも敵かもしれないが、それははるか未来のことだろう）。256bitは将来的にも計算量安全性が確保される。

個人的にはBlowfishが好きだが、EncFSならAES、eCryptFSならAESかCAST5が有力な選択肢だろう。LUKSはCAST5をメインとする。MHディレクトリならBlowfishもありかもしれない。