# cppcryptfs is gocryptfs on Windows, with the files encrypted one by one

> cppcryptfs is a C++ implementation of the gocryptfs encrypted overlay filesystem for Windows, built on the Dokany user mode driver. Mounting it gives you a drive letter with plaintext files, while what sits on disk is per file encrypted, with the file names encrypted too if you want them to be, which is what lets a cloud sync service carry the data without being able to read it.

**bailey27/cppcryptfs** — cppcryptfs is an implementation of the gocryptfs encrypted overlay filesystem in C++ for Windows.

- Repository: https://github.com/bailey27/cppcryptfs
- Stars: 989 · Forks: 90
- Language: C++
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/bailey27-cppcryptfs

## Same format, different language and platform

cppcryptfs is an implementation of the gocryptfs filesystem in C++ for Windows, and the compatibility claim is the important one. Filesystems created with one implementation can generally be mounted and synced with the other, so a filesystem encrypted on a Windows machine can generally be mounted by gocryptfs on another machine, and the reverse also holds. The design comes from gocryptfs, the encrypted overlay filesystem written in Go, and the C++ rewrite exists because the virtual filesystem layer is provided by a different mechanism on Windows. That mechanism is Dokany, a driver and library that lets an application present a virtual filesystem in user mode without a kernel driver of its own. The result is encryption that happens on the fly, at rest and in the cloud, applied to file contents and, optionally, to file names as well.

## A drive letter with plaintext, a folder with ciphertext

The model is straightforward once you see the two sides of it. You create an encrypted filesystem in a folder, protected by a password you choose. When you mount it by supplying that password, a new drive letter appears in Windows, and that virtual drive gives an unencrypted view of your files. Encryption and decryption happen on the fly and are transparent to any application reading or writing files on that drive. After you dismount the virtual drive, there is no way to reach the unencrypted data except by mounting again with the password, and shutting the computer down dismounts all cppcryptfs drive letters automatically. That last point matters more than it sounds, because a mounted filesystem is the only state in which the plaintext exists outside the encryption boundary, so the habit of dismounting when you step away from the machine is the one the design asks of you.

## Per file encryption is what makes the cloud case work

The design choice that distinguishes this from a container based encrypted volume is that the encryption is applied per file rather than to a single container file. The consequences are stated plainly in the documentation. You do not have to decide in advance how much encrypted storage you need, because the filesystem grows dynamically and is limited only by the free space on the physical drive where it lives. The storage overhead is described as very minimal, since there is no fixed container to preallocate. And per file encryption syncs very quickly and efficiently with cloud based services, because the sync client sees a set of ordinary files rather than one large blob that changes entirely on every write. That is the point of the whole arrangement. If the folder holding the encrypted files is synced with a cloud service, only the encrypted files, with encrypted file names, are uploaded, so neither the employees of the cloud service nor anyone who breaks into the cloud service can read the contents, and a thief who takes the computer while the filesystem is not mounted finds the same thing.

## The configuration file is the thing a password attack targets

There is a warning at the top of the documentation that anyone putting this in a cloud folder needs to understand. The created `gocryptfs.conf` holds the parameters of the encrypted filesystem, and if an attacker obtains that file, they can throw whatever computing resources they have at a brute force attack on your password. The defence is the password itself, and the knob that makes each guess more expensive is scryptn, which is the work factor parameter and which the documentation says can be increased to slow an attacker down. The developer's own practice is to keep his configuration file in the cloud and rely on a very strong password, which is a reasonable position for a person who chose the password well, and a reckless one for anyone who chose it in a hurry. The distinction to hold on to is that the encrypted files and the configuration file have different threat models, and the configuration file is the one that determines how long a stolen copy of your data resists a password search.

## Reverse mode is the half that has been tested less

The status section is where the project is honest about itself. The developer states that he has been using cppcryptfs in forward, normal, mode for over three years without losing any data, and that at least one other person is using it. Reverse mode has had only limited testing by the developer, and that is a difference in kind rather than degree. In forward mode you create the filesystem in an empty directory and it is the encrypted store. In reverse mode the directory need not be empty, because the arrangement is inverted, and that path is where the interesting cases live, with existing files and with the direction of the overlay reversed. The documentation also states that binary releases are signed by the developer, Bailey Brown Jr, and are on the releases page, which is the mechanism a Windows user would use to check that the executable came from the author, and it closes with the reminder that keeping backups is prudent in case something goes wrong.

## The test suite is a forked Windows filesystem test

The compatibility with Windows is argued with a test suite rather than an assertion. cppcryptfs passes 506 out of 506 tests in winfstest when it is run as administrator, and 500 out of 506 without administrator privileges. The winfstest suite is a fork of the version used by the Dokany project, and the Dokany team added further tests of their own. The tests that fail without administrator rights are the ones that operate on DACLs, discretionary access control lists, and the documentation says cppcryptfs must be run as administrator for those operations to work, while noting that running without administrator privileges does not appear to affect normal usage. There is also a specific note that on Windows 10 version 1909, build 18363.1016, the full 506 pass without needing administrator rights at all, which reads like a change in how that operating system version handles the relevant operations.

## Building it and the one command you should run on Windows

The build requirements are named: Visual Studio 2022 Community Edition, perl, nasm and git, all free, plus OpenSSL as a static build, RapidJSON for parsing the configuration file, and Dokany. For Dokany the documentation suggests the binary distribution, with the instruction to select the install development files option in the installer. Detailed build instructions live in INSTALL.md, and the project is described as currently up to date with Dokany 2.3.1.1000. At runtime the tool does not require administrator privileges, though without them it cannot acquire the SE_SECURITY_NAME privilege that the Windows API functions SetFileSecurity and GetFileSecurity need, and the documentation says it seems to work without it, so administrator is the thing to try if you hit a problem. One operating system setting is recommended, encrypting the pagefile so that sensitive data does not end up on disk in the clear:

```bash
fsutil behavior set EncryptPagingFile 1
```

That command is run in a command prompt as administrator. Creating a filesystem is a matter of picking the Create tab, choosing or creating the root directory, which must be empty in forward mode, and strongly recommended to sit on NTFS, then entering a password twice, with a limit of 255 characters and one unicode character excluded from use.

## Conclusion

cppcryptfs suits a Windows user who wants encrypted storage that a cloud sync service can carry without being able to read, and who wants the same filesystem format to be mountable by gocryptfs on another machine. It is a poor fit if you need a volume that is encrypted as a whole rather than file by file, since the design is explicitly per file, and it is a poor fit if you need reverse mode to be as trustworthy as forward mode, because the developer says that half has had only limited testing. Before you put real data in it, check three things: the strength of your password, since the configuration file in your cloud folder is what a brute force attempt targets and scryptn is the knob that slows it, the version you install, with v1.4.5.0 published on 2026-10-18 and the last push on 2026-10-19, and the licence, because the repository's licence field is recorded as a custom licence that GitHub cannot classify even though the README badge says MIT.

## FAQ

### Can cppcryptfs open a filesystem created by gocryptfs?

Yes. cppcryptfs is compatible with gocryptfs, and filesystems created with one can generally be mounted and synced with the other, so the same encrypted folder can generally be used with either implementation.

### Is it safe to keep the gocryptfs.conf file in cloud storage?

Only with a strong password, according to the documentation. If an attacker obtains the configuration file, they can throw resources at a brute force attack on the password, and increasing scryptn slows them down. The developer keeps his own configuration file in the cloud and relies on a very strong password.

### Does cppcryptfs need administrator privileges to run?

No. Without administrator rights it cannot acquire the SE_SECURITY_NAME privilege needed by SetFileSecurity and GetFileSecurity, but the documentation says it seems to work without it. Running as administrator is worth trying if you hit problems, and the DACL related tests only pass with administrator rights.

### How well tested is cppcryptfs?

It passes 506 out of 506 tests in winfstest when run as administrator and 500 out of 506 without administrator privileges, and the suite is a fork of the one used by the Dokany project. The developer states that forward mode has been in daily use for over three years without data loss, while reverse mode has had only limited testing.

### How are file names handled in cppcryptfs?

You can choose to encrypt file names with AES256-EME or leave them as plain text. When encrypted names are used, the long file names option allows names of up to 255 characters, and that option has no effect on plain text names, which are already limited to 255 characters.

## Sources

- [bailey27/cppcryptfs on GitHub](https://github.com/bailey27/cppcryptfs)
- [Issues](https://github.com/bailey27/cppcryptfs/issues)
- [README](https://github.com/bailey27/cppcryptfs/blob/master/README.md)
- [Releases](https://github.com/bailey27/cppcryptfs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bailey27-cppcryptfs