Enigma: a simple encrypted filesystem

(WARN: This project has not been validated or verified for security. In fact, current implementation is prone to chosen ciphertext attack. It is strongly not recommended to use this in production.)

Enigma is a simple encrypted filesystem that adds a thin layer of encryption over native filesystem and keeps your most sensitive secrets.

Quickstart for Windows (with WinFSP)

Quickstart for Linux (with FUSE)

Use Enigma as a Windows local drive through WinFSP

Use Enigma as a mount point through FUSE on Linux

Roadmap

• Operation Mode
  • Direct mapping mode
  • POSIX-compatible mode
• Key Specification
  • File (prone to invasion) ¹
  • Vault (with github.com/hashicorp/vault)
  • HTTP request (remote decryption)
• Integration
  • WinFSP (Windows only, with github.com/aegistudio/go-winfsp)
  • FUSE (Linux and Mac only, with github.com/hanwen/go-fuse)
  • HTTP (trivially by Golang's http library)
  • FTP (with github.com/fclairamb/ftpserverlib)
  • NFSv3

Methods of Encryption

Both the file names and data will be encrypted by an AES-256 key in CTR mode, which takes trillions of years for the attackers to crack, owing to the miracles of cryptology.

Encrypting in CTR mode enables the filesystem to random access the stored content, without bloating the file size. Many CPUs support hardware accelerating computation of AES-256 block. This is crucial for implementing a fast, efficient and low overhead file system.

The nonce, which is required by CTR mode to encrypt file names and data, is generated regarding the path relative to root in filesystem. Walking down the path to the final component of file name, we compute the SHA256 hash of its parent's hash concatenating current visited component. The hash of / is the SHA256 digest of the key.

Since all information to calculate the nonce is contained inside the file or directory's path we are going to visit naturally, we don't need to spend any extra space to store the nonce.

Under the same directory, encrypting file names with the same nonce directly is prone to chosen-plaintext attack. To mitigate, we generate a short extra nonce for each file name, which is computed from the cryptological digest. Then the nonce for the file name is computed from the digest of the directory it is in, plus the short extra nonce and the file's length. After being encrypted, the file name is encoded in Base64 as it is usually in invalid ASCII or Unicode.

For resisting birthday attack, the default extra nonce size is 3 bytes, which yields a birthday bound of about Q(H) = 46819.7 files and low possibility bound of about n(H;0.25%) = 2813.6 files ², and is considered providing enough security under most circumstances.

The AES-256 key for encrypting the file system, is randomly generated through a cryptologically secure random process, then encrypted and authenticated by a root key supports AEAD. This extra indirection enables us to check whether proper key is specified, and enables online decryption to protect the root key, without sacrificing the performance.

License

The project is licensed under Apache-2.0. Anyone is free to modify and redistribute the code, however they must swear the oath of keeping users' data and secrets sacred and depicts what they have modified for users' judgement.

Footnotes

1. Storing your key as regular files on the disk directly can be a security issue if your physical machine has been invaded. It's not so risky if the key is transfered over TTY, pipe, socket, etc. ↩

2. Assume native file system supports file name of maximum 128 bytes, there're (128-1) * 6 / 8 - 1 = 94.25 cases of file names' length. The number of outputs for file names' nonces is H = 94.25 * (2^24) = 1581252608.0. ↩