EncFS

**EncFS** 是一個基於 FUSE 的加密檔案系統，為自由軟體。通過它可以將任意目錄作為儲存空間來透明地加密並儲存檔案。 

掛載一個 EncFS 檔案系統涉及到兩個目錄：源目錄和掛載點。掛載點中的每個檔案都是加密儲存在源目錄中的一個與之對應的檔案。掛載點中的檔案呈現未加密的樣子，對應源目錄中已加密的檔案。源目錄中會加密檔名。

檔案通過卷金鑰加密，卷金鑰可以儲存在加密的源目錄之內或之外。有一個密碼機制用於解密該金鑰。

## 常見用途

* 在 Linux 中，作為 eCryptfs 的替代方案加密 home 資料夾。
* 用來加密儲存到雲端儲存（Dropbox、Google Drive、OneDrive 等）的檔案和資料夾。
* 為抽取式磁碟中的資料夾進行可攜式加密。
* 作為一個跨平台的資料夾加密機制。
* 可增加雙重身分驗證（2FA）來提高儲存安全性。例如，可以將 EncFS 用來加密資料的卷金鑰儲存在加密資料之外（如隨身碟、網路掛載點、光碟或雲端儲存中），同時要求提供密碼來解密這個卷金鑰。

## 優勢

與其他磁碟加密軟體相比，EncFS 因在主機上單獨儲存每個被加密的檔案而具有一些優勢。

### 跨平台

EncFS 可在多個平台上使用，而 eCryptfs 與 Linux 核心繫結

### Bitrot 檢測

EncFS 在底層檔案系統之上實現了資料腐爛（bitrot）檢測

### 可延伸儲存

EncFS 不存在占用固定大小的「卷」—— 加密的目錄占用的空間隨著掛載點中的檔案增加而增加，也隨著檔案被刪除而縮小。

### 適用於檔案伺服器

EncFS 的加密目錄可以位於普通的檔案伺服器上（通過 NFS、SSHFS 等），並且可以使用普通的檔案系統工具（例如 Rsync）高效地進行鏡像和備份。

### 跨物理裝置

掛載點中的某些目錄可能存在於其他的物理裝置上。

### 更快的備份

檔案同步、雲端儲存等備份軟體可以只備份源目錄中已變更的檔案。

### 抗損壞

資料損壞發生時，更不易波及多個檔案。損壞也更可控，可能通過檔案系統級別的維護工具來修復某些資料損壞。磁碟加密系統遭遇資料異常損壞時可能遭遇更多意外情況。

### 最佳化

因為加密的檔案仍基於底層檔案系統來儲存，某些作業系統最佳化機制仍然奏效，例如傳遞 Trim 命令來幫助提升固態硬碟的效能。不過 dm-crypt 也支援這一點。

### 隨機檔案存取

支援檔案的隨機存取，無需解密整個被加密的卷。

## 不足

EncFS 也存在一些缺點。

### 相容性

掛載的 EncFS 目錄與容納源目錄的檔案系統享有相同的能力與限制。

### 不支援長檔名

因加密原因，EncFS 產生的加密檔案的檔名會比原始檔名長。因此，EncFS 不能儲存長度接近檔案系統的檔名長度上限的檔名。大多數檔案系統的一般檔名限制為 255 個位元組，這種情況下 EncFS 最多支援 190 個位元組的檔名。 

### 一般性安全隱患

儘管檔名和檔案資料被加密，但任何有權存取源目錄的人都可看到加密的檔案系統內有多少檔案、檔案的權限、檔案的大致大小，以及上次存取和上次修改檔案的時間。

### EncFS 1.7 安全問題

2014 年 2 月進行的付費安全審計中發現了多個潛在的漏洞。給出的結論是：

> EncFS is probably safe as long as the adversary only gets one copy of the ciphertext and nothing more. EncFS is not safe if the adversary has the opportunity to see two or more snapshots of the ciphertext at different times. EncFS attempts to protect files from malicious modification, but there are serious problems with this feature.
> 
> 

> 如果對手只能看到一版被加密的內容，EncFS 可能是安全的。如果對手能看到密文在不同時間的兩版或更多版本，則 EncFS 不安全。EncFS 在嘗試避免檔案免遭惡意修改，但該功能存在嚴重問題。
> 
> 

### EncFS 1.8 安全問題

EncFS 1.8 的公告包括數項基礎設計變更，以回應上次的審計中提出的安全問題。儘管如此，這些安全漏洞仍受到關注。 

## 檔案系統選項

在新建 EncFS 卷時，有數個用來自訂檔案系統的選項，以滿足不同需求。

### 密碼演算法

EncFS 可使用若干種存在於系統中各加密庫內的加解密演算法。Blowfish 和 AES 通常可用。

可以為支援「可變金鑰長度」的密碼演算法選擇金鑰長度（keySize）。

### 塊大小

每個檔案均以塊的形式加密，有選項控制這些塊的大小。每次讀取單個位元組時，必須解密包含它的整個塊。同樣，每次寫入都需要解密對應塊、更改內容並重新加密。

預設的塊大小 1024（位元組）足以滿足大多數用途。

### 檔名編碼

源目錄中的檔名可以儲存為明文、加密塊或流模式加密。塊模式在一定程度上掩蓋了檔名長度，而流模式的檔名會儘可能短，這在某些檔案系統中可能節省一些儲存空間。

### 檔名 IV 鏈

啟用此選項後，加密檔名所用的初始化向量取自檔案的父目錄 —— 這將使兩個同名但位於不同目錄的檔案具有不同的加密後檔名。

如果重新命名目錄，則其中包含的所有檔案和目錄都需要重新加密其檔名，這可能花費不少時間和資源。如果經常重新命名含有大量子專案的目錄，則應該禁用此選項。

### 每個檔案的初始化向量

啟用此選項後，每個檔案都使用一個隨機的 8 位元組初始化向量來加密，該向量儲存在源目錄的加密檔案中。如果禁用此選項，則每個檔案都使用相同的初始化向量來加密，可能使卷金鑰更容易被破解。

啟用此選項可加強檔案系統的安全性，但每個檔案會多占用 8 個位元組。

### 外部 IV 鏈

使檔案資料的初始化向量衍生自檔名的初始化向量鏈。相同資料但不同檔名或目錄的檔案將加密成不同的樣子。

如此，此模式啟用時重新命名檔案需要檔案的隨機初始化向量被檔名初始化向量鏈中的更改抵消，或者重新編碼資料。 EncFS 的作者選擇了前一種方法，因為快得多，尤其是對於大檔案。

### 檔名到 IV 頭部鏈

使編碼依賴於完整的路徑名。因此重新命名或移動檔案將需要重新編碼。不支援硬連結。

### 塊 MAC 頭部

儲存每個加密塊的校驗和，使 EncFS 能檢測到加密檔案的損壞或修改。校驗和 (blockMACBytes) 為 8 個位元組，並可選擇向每個塊添加最多 8 個額外位元組的亂數據 (blockMACRandBytes)，以防止相同未加密資料的兩個塊有相同的校驗和。因為必須在讀取資料（驗證完整性）與寫入資料（更新校驗和）時計算每個塊的校驗和，此選項會帶來大量 CPU 開銷。

## 參見

* 磁碟加密
* 檔案系統級加密
* 加密檔案系統列表
* 加密檔案系統列表
* 檔案系統列表

## 參考資料

## 外部連結

* Encfs manpage （頁面存檔備份，存於網際網路檔案館）
* Safe: another per-file implementation for Windows and Mac OS X, with no kernel mode driver (slower), but fully open source （頁面存檔備份，存於網際網路檔案館）
* Boxcryptor: Proprietary software based on EncFS for Windows, Android, and iOS （頁面存檔備份，存於網際網路檔案館）
* EncFSMP: Implementation that runs on Windows and Mac OS X （頁面存檔備份，存於網際網路檔案館）