Feature Request: Transparent Folder Decryption with YubiKey & Symlinks

Describe the feature and how it would impact the app

This feature transforms SecureFolderFS from a separate WebDAV drive into a transparent, encrypted folder. Users would work directly in their original folder path (e.g., D:\SecureDocs). The app would automatically prompt for decryption when needed, present files via hidden symlinks, and support YubiKey for passwordless auth. This creates a seamless, "invisible" encryption experience similar to EFS, deeply integrating security into daily workflows.

Requirements

1. Intercept & Prompt: Block direct access to locked folders and redirect users to the app for decryption.
2. Symlink-Based Access: Decrypt files into a hidden vault and present them in the user's folder via symbolic links, hiding the encrypted data.
3. YubiKey (PIV) Auth: Enable unlocking via YubiKey touch/PIN for a passwordless, hardware-backed login.

App Version

0.7.2.0 (WinUI)

[d2dyno1]

Hi! Thank you for taking the time to open a new issue. I can see a couple of requests being asked for there. I'll break them down:

1. I'm not sure how that'd work, as intercepting NTFS requests on three different file systems (Dokany, WinFsp, and WebDav) on Windows alone would be challenging just for having a "ghost" virtual storage directory. Instead, there's already a feature planned (and frankly already implemented in the dev branch) that lets users create shortcut files to specified vaults. These files are openable by SecureFolderFS and present a bare-bones authentication prompt without showing the main application UI. I reckon you could create said shortcut file and put it in a convenient place to quickly unlock your vault.

In the future, I might decide to implement such functionality integrated with the shortcut files (where the app will automatically mount all vaults and only provide the shortcut file within them - opening the file and unlocking the vault would then mount the actual file system). But that's out of scope right now and would require more planning in a separate issue.

2. I'm not sure what's being asked here. As far as I understand, having the vault already describe its contents in the form of symlinks (without authentication) and requiring the login credentials when trying to access a file would be infeasible, because:

• It adds unnecessary complexity to the already complex file system structure,
• would require implementing a custom solution for each file system on each platform,
• symlinks leak plaintext paths,
• authentication would still be required nonetheless, as SecureFolderFS must derive encryption keys for decrypting file names
• there's no integration with the file system on the device, so whenever a file would be opened, it'd have to be decrypted in some temporary location, leaving traces on the disk.

In other words, it's much better to mount the file system as a whole than to imitate it through symlinks.

3. YubiKey authentication is already in the works. You'll be able to unlock your vaults using your key or use it as a second authentication option.

All aforementioned features will come in the upcoming Release Candidate 1 major update.

@user1253-sudo

In fact, I want to automatically set up symbolic links when unlocking the vault. The goal is to create symbolic links for the WebDAV network folder used to read decrypted data. This allows encrypted files to obtain a virtual path when decrypted, instead of exposing the decrypted files via a network drive. This way, some programs that require path-based access can function properly while the vault is running.

[d2dyno1]

I think I understand it now. The symlink would basically be created and point to the root directory (i.e. \\localhost@4949\My Vault), and other apps would interact through that symlink. However, this leaves a few questions:

• Where would this symlink be placed? If the symlink were placed in a user-chosen location (e.g. C:\My Vault or another directory), additional permissions might be required depending on the path.
• Apps and the user would have to know where that symlink resides, and preferably have an option to change its location within the app.

Just to confirm: this would be a single directory-level link pointing to the mounted vault, not per-file symlinks?

Overall, while this is a good idea, and one that I'll certainly investigate more, it's easy to say that it requires more work and won't come in Release Candidate 1. The other features are still planned for the upcoming release. For now, though, please try out Dokany from the Preferences page in Settings, as it is more integrated on the OS level. 🙂

I think I understand it now. The symlink would basically be created and point to the root directory (i.e. \localhost@4949\My Vault), and other apps would interact through that symlink. However, this leaves a few questions:

* Where would this symlink be placed? If the symlink were placed in a user-chosen location (e.g. C:\My Vault or another directory), additional permissions might be required depending on the path.

* Apps and the user would have to know where that symlink resides, and preferably have an option to change its location within the app.

Just to confirm: this would be a single directory-level link pointing to the mounted vault, not per-file symlinks?

Overall, while this is a good idea, and one that I'll certainly investigate more, it's easy to say that it requires more work and won't come in Release Candidate 1. The other features are still planned for the upcoming release. For now, though, please try out Dokany from the Preferences page in Settings, as it is more integrated on the OS level. 🙂

Thank you for your thoughtful response, and I apologize if my initial issue was not clearly articulated. To clarify, I am actually an EFS user — EFS being Microsoft’s built-in file encryption for multi-user environments, often seen as a complement or alternative to BitLocker for file-level protection. I use it as a second layer of security alongside VeraCrypt, which guards against physical theft, while EFS allows me to use a YubiKey for on-demand encryption/decryption. This setup effectively prevents unauthorized access in scenarios such as shared family computers, remote assistance, or temporarily lending my device.

Currently, SecureFolder seems more aligned with tools like Cryptomator, which focus primarily on encrypting cloud-synced folders. What I’m hoping is that SecureFolder could evolve into a local encryption alternative — and upgrade — to EFS.

One possible implementation could work as follows:
When a folder (let’s call it A) is selected for encryption, all files inside are encrypted while preserving their original names and extensions. The entire folder A is then moved to a dedicated vault directory, for example C:\Vaults\A. A symbolic link is placed at A’s original location pointing to this encrypted version. A Windows system service—similar to TrustedInstaller in privilege and isolation, which could be named “SecureFolder Access Service”—would be created to manage access permissions exclusively for folders under C:\Vaults. This service would enforce access control, ensuring that unauthorized attempts to access an encrypted folder trigger a permission prompt, while forced access only yields encrypted data. When the folder is decrypted via SecureFolder, the symbolic link is dynamically redirected to point to the decrypted files through a WebDAV or Dokany mount, with the service facilitating secure access during the decrypted session.

If this approach isn’t feasible or doesn’t align with the project’s direction, feel free to close the issue. Thanks again for your time and consideration.

[d2dyno1]

Thanks for clarifying. I'll keep this open for now, since it's something I'll be sure to revisit in the future.

all files inside are encrypted while preserving their original names

You can choose to have your file names not encrypted in the vault creation screen (just set File name encryption to "No encryption" in the "Advanced" section during vault creation)