Works like a normal drive
To your computer a mounted container is just another disk. Open files in any app, save changes and drag folders in and out. Unmount it and the drive disappears.
Encrypted virtual disks
An encrypted drive that opens like any other
HushDisk keeps your files inside an encrypted container file. Enter the password and the container appears as a drive in Finder or File Explorer. Data is decrypted only as it is read, and mounting never writes a decrypted copy of the container to disk.
Development builds exist for macOS and Windows, and a Linux desktop app is in development. There is no public release yet.
Archive.vdf
- Family photos
- Tax returns
- Passport scan.pdf
Preview, not the real app
What it does
Everything here works in both editions of the macOS and Windows apps unless a line says otherwise.
Read-only until you choose
New mounts open read-only. You turn on writing yourself, so browsing an archive can't change it.
Changes go through a checked copy
Changing the password, cipher or compression writes a new container and reads all of it back before anything is replaced. Re-encrypting in place keeps the original as a backup until you delete it.
The filesystem you need
Create exFAT, FAT32 and NTFS containers on macOS and Windows, and ext4 and APFS containers on macOS. Size is limited only by the filesystems involved.
Password tools
A generator and a strength meter help with new passwords. Saving a password in the system keychain is optional and set per container.
Unmounts on its own
Give a container an inactivity timeout and it unmounts when nothing has used it. Containers you pick can also mount read-only when you sign in.
Encrypt a USB drive's contents
Capture a removable disk into a new encrypted container. HushDisk only reads the disk. It reads it twice, and the two reads must match before the copy is encrypted and checked.
Old containers still open
Containers made by FreeVDF and older VDF tools open as they are. Opening one never rewrites it; moving to the current format is a separate, checked copy.
How your data is protected
Containers created in the apps use the same format on every system. Older formats stay readable so existing containers keep working.
- Cipher
- AES-256-XTS, the default for new containers. SSE1, IDEA, Blowfish, DES, 3DES, Arcfour and XOR stay selectable for compatibility with old containers. They are much weaker than AES, and DES, Arcfour and XOR give little real protection.
- From password to keys
- PBKDF2-HMAC-SHA-256 with 600,000 iterations and a random 32-byte salt produces a 32-byte seed. HKDF-SHA-256 expands the seed into separate encryption and integrity keys.
- Integrity
- In containers the apps create, every stored record and both checkpoints carry an HMAC-SHA-256 tag. HushDisk checks the tag before decrypting and refuses data that doesn't match.
- Compression
- Optional LZ4 compression, applied chunk by chunk (16 KiB chunks by default).
- Writing
- In containers the apps create, changes are written and flushed to disk, then recorded in one of two alternating checkpoints, which is flushed again. A container whose writable session didn't end cleanly can't be opened for writing until it has been checked.
- What isn't hidden
- Anyone with the file can see its size, its internal layout and how well each chunk compressed. Swapping the whole file for an older copy isn't detected.
- Deleting files
- On macOS, files you delete on a writable mount skip the Trash: Finder asks for confirmation and removes them permanently, so no decrypted copy lands in the Trash outside the container. This is ordinary deletion, not secure erasure.
- Review
- The format and code have not yet had an independent cryptographic review.
macOS, Linux and Windows
One engine and one container format on every system. macOS and Windows have native apps in English, Ukrainian, Spanish and Russian; the Linux desktop app is in development.
macOS: Development builds
- Drives appear in
- Finder, including Locations in the sidebar. Eject works as usual.
- Mounting
- macFUSE with its FSKit backend, installed separately from macfuse.io.
- App
- A library window, a menu bar menu and the
hushdiskcommand. Drives stay mounted after you close the window. - Saved passwords
- macOS Keychain, only when you ask.
- Filesystems
- Create FAT32, exFAT, APFS, ext4 and NTFS. Experimental writes cover exFAT, APFS, ext4 and NTFS when the container is on a local APFS volume. FAT32 is read-only.
Linux: In development
- Today
- Command-line tools that present a container as a decrypted disk image through FUSE and mount it with a loop device. They open every older format; containers in the current format mount read-only.
- Planned app
- A GTK 4 and libadwaita desktop app that mounts containers through the kernel's own filesystem drivers over a local network block device (NBD), with GNOME Files and keyring integration.
- Planned target
- Ubuntu Desktop 24.04 LTS and 26.04 LTS, first on amd64.
Windows: Development builds
- Drives appear in
- File Explorer, with a drive letter and normal eject.
- Mounting
- Each container is served on the computer itself as an iSCSI disk and attached with the iSCSI initiator built into Windows. No extra driver is installed.
- App
- A library window, a notification area menu and the
hushdiskcommand. - Saved passwords
- Windows Credential Manager, only when you ask.
- Filesystems
- Create exFAT, FAT32 and NTFS, read and written by Windows' own drivers. Experimental writes need the container on a local NTFS or ReFS drive.
Basic and Pro
Both editions open the same containers. Everything Basic does, Pro does too.
| Feature | Basic | Pro |
|---|---|---|
| Everything on this page | Included | Included |
| Hidden volumes | Not included | Planned |
| Secure file deletion | Not included | Planned |
| Where to get it | Direct download for macOS and Windows, and for Linux once its app is released | Mac App Store and Microsoft Store, and a .deb package for Linux once its app is released |
Hidden volumes: Planned
A second, separately encrypted volume inside an ordinary container, opened with its own password. The aim is that a container looks the same whether or not it holds a hidden volume.
The format is still being designed.
Secure file deletion: Planned
A Secure Delete command that erases the keys protecting the selected files, so their contents can no longer be decrypted from the container, even by someone who knows its password. It erases keys because overwriting a file can't reliably reach old copies on SSDs and flash memory.
The guarantee will cover only a qualified container profile and key provider. Copies outside the container, such as exports, previews, swap and backups, aren't covered. The design is in progress.
Neither planned feature is in current builds.
Download
Basic is a direct download. Pro comes from the Mac App Store and the Microsoft Store. On Linux, both editions will be .deb packages once the desktop app is released.
No public release yet.
Packages and store links will be listed here, with SHA-256 checksums for direct downloads, when the first release is published.
System requirements
| System | Requires | Tested on |
|---|---|---|
| macOS | macOS 15.4 or later, and macFUSE 5.4 or later with its FSKit modules enabled | macOS 26.5 on Apple silicon |
| Linux | Desktop app in development, planned for Ubuntu Desktop 24.04 LTS and 26.04 LTS on amd64 | Not released |
| Windows | Windows 11 (build 22000 or later) on x64 | Windows 11 (x64) |
Recent changes
Builds from the project changelog, newest first.
These are development builds. None has been published as a release yet.
0.1.1, build 29
WindowsAdded
- Windows 11 app: Win32 library window, notification-area menu and the
hushdiskcommand line with the macOS commands, options and messages. - Mounting through the inbox Microsoft iSCSI Initiator and a loopback target per container, coordinated by a per-user session service and a LocalSystem broker. Mounts are read-only by default; opt-in writes use the Windows NTFS, exFAT and FAT drivers.
- Creation of exFAT, FAT32 and NTFS containers, credentials check, export, password-change and conversion copies, same-path replacement with journal recovery, and read-only imaging of removable disks.
- Credential Manager storage, mounting after sign-in, inactivity unmount, and unmount at sign-out or shutdown.
- MSI installer with service registration, PATH, Start menu entry and
.vdffile association.
Compatibility
- The Windows app takes its version from the macOS app. The MSI version is major.minor.build, so a later build upgrades an earlier one; packaging refuses a build without its section here.
- Requires Windows 11 (build 22000 or later). Writes need a local NTFS or ReFS drive and a container with one hard link. An unfinished write session is marked beside the container, as on macOS, and by an
org.hushdisk.write-sessionstream on the container in place of the macOS extended attribute. - Second-account isolation, power-loss and sleep qualification, accessibility and signed distribution are not done yet.
- Windows 11 app: Win32 library window, notification-area menu and the
0.1.1, build 28
macOSAdded
- Repository changelog, documentation links and contributor/agent rules for updating it with every repository change.
Performance
- Common engine, Basic and Pro: authenticate staged compressed-container metadata once at transaction publication instead of after each small change. Disk-page authentication, file formats and mounted durability barriers stay unchanged.
0.1.1, build 27
macOSFixed
- Prepared jobs wipe their credential frame on early cancellation, launch failure and missing-executable admission, as well as after pipe delivery.
- A final replacement flush failure after durable journal removal no longer requests recovery through a missing journal. The verified replacement and original backup remain retained.
0.1.1, build 26
macOSChanged
- New outputs derive a 32-byte PBKDF2 seed and expand storage keys through HKDF-SHA-256. Salted trailers use revision 3; block containers use checkpoint revision 4. Older formats keep their original derivation and compatibility.
- Credential frames are prepared before long operations, owned by a single-use job and wiped after delivery. Mount protocol 8 sends credentials separately from public JSON metadata.
- Same-path replacement reports progress through its remaining hash passes and permits cancellation until commit preparation. Encrypted transaction buffers no longer receive unnecessary wipes; plaintext buffers still do.
Fixed
- Imaging reports specific busy-device, permission, timeout, source-change and verification errors.
- Replacement adds recovery guidance only after journal publication, including a failed durability barrier.
- Current usage and error messages appear in all four language catalogs, with checks for message producers and locale/plural parity.
Build
- Shared core source manifest, verified dependency downloads and worker source archives replace repeated build definitions. NTFS enables warnings as errors.
- Mount checks share bounded protocol/subprocess helpers and reuse compiled Finder probes.
Compatibility
- New-format copies require build 26 or later. Keep the original when migrating; opening an older container does not rewrite its format.
- Protocol 8 requires an updated session service. The client checks preparation before sending credentials and gives upgrade guidance for older services.
- Immutable Keychain framework data and SwiftUI strings have no complete RAM-erasure guarantee. The verification report records the checks and remaining limits.
0.1.1, build 25
macOS- Retained failed write-completion evidence after marker deletion so coordinator recovery still sees the failure.
- Fixed filename truncation for malformed UTF-8 input.
0.1.1, build 24
macOS- Applied the final app signature and macFUSE entitlement to the exFAT worker.
- Flushed inode-flag removal before deleting the write-recovery marker, with retry support after a failed cleanup.
- Shared the exact-read helper between ordinary protocol requests and replay checks.
0.1.1, build 23
macOSFixed
- Encrypted sector-zero handling, long runtime/socket paths, Unicode temporary and backup names, canonical-path uniqueness and replacement recovery after device identities change.
- Session cleanup retains recovery evidence and distinguishes admission failures from failed write completion.
- exFAT metadata cleanup at full-disk and filename limits, ext4 inode allocation and error handling, and APFS directory handles.
- Mounts remain successful when optional Keychain or login-state persistence fails. Storage errors retain their cause, and service replies are bounded.
- Creation and password changes share exact UTF-8 validation. Recovery actions, system-key checks and operation phases use common admission rules.
Security
- exFAT diagnostics omit guest names and avoid unified logging. Copied passwords request concealed/transient clipboard handling, stay on the current host and expire after 60 seconds if the clipboard is unchanged.
- Key-bearing objects use separate mapped allocations. Runtime directories use the account's private temporary directory; macFUSE loading checks protected paths and signatures.
- Writable admission checks ownership, permissions and hard links. Failure markers survive container renames. Unknown ciphers fail instead of returning plaintext.
Performance
- Reused AES schedules, fewer flushes for private copy outputs, bulk export reads, bounded ext4/NTFS write batching and an ext4 block cache reduce repeated work. Mounted writes retain their durability barriers.
- Replacement skips redundant fresh-operation hashes. Library rendering avoids repeated path queries, and background cleanup no longer sleep-polls worker exits on every refresh.
0.1.1, build 22
macOS- Fixed exFAT renames at the filename limit and Unicode backup naming during same-path replacement.
- Kept session recovery records until the session directory was removed.
- Accepted the same exact UTF-8 passwords for creation and password changes.
- Shared worker marker cleanup across exFAT, ext4 and NTFS.
0.1.1, build 21
macOS- Fixed exFAT metadata queries when an AppleDouble sidecar name would exceed the filename limit. Missing sidecars report absent metadata; failed metadata writes preserve the payload.
- Documented intentional permanent deletion on writable mounts. Finder asks for immediate deletion; removed items do not enter the host's Trash. Ordinary deletion does not guarantee secure erasure.
- Recorded Pro plans for hidden volumes and secure file deletion. Both features remain pending.
0.1.1, build 20
macOS- Added Basic/Pro selection to app and package builders. Existing features stay in both editions; new features need an explicit edition choice.
- Added compiled edition reporting and package/CLI metadata consistency checks. Both editions share the installed path, upgrade identifiers and user data.
0.1.1, build 19
macOS- Restricted installer CLI/worker checks to the installed bundle so private test processes do not block upgrades. Open GUI copies and unfinished recovery still block installation. Refusal logs identify blocking processes.
0.1.1, build 18
macOS- Batched exFAT block writes within filesystem operations and skipped redundant v3 syncs after durable checkpoints. Mutations still flush before returning; staging remains bounded and failure markers are retained. Measurements are in the copy speed comparison.
0.1.1, build 17
macOS- Removed a folder's recognized metadata sidecar during deletion, allowing Finder replacements to reuse the folder name.
- Recorded native, unencrypted, AES and compressed copy comparisons.
0.1.1, build 16
macOS- HushDisk branding, a native macOS app, menu bar, CLI and per-user session service, with compatibility identifiers retained for existing installations.
- Creation of FAT32, exFAT, APFS, ext4 and NTFS containers, AES-256-XTS selected by default, salted authenticated block storage and optional LZ4 compression.
- Read-only mounting and opt-in development writes for admitted exFAT, APFS, ext4 and NTFS combinations. FAT32 remains read-only.
- Password generation/strength estimates, optional Keychain storage, idle unmount, mounting after sign-in and four interface languages.
- Verified password/conversion copies, same-path replacement with an original backup, and read-only removable-device imaging.
- Local macOS package creation, dependency/upgrade checks and build numbering.
- exFAT filename translation for Photos library copies, contiguous cluster I/O and bounded compression transactions.
- OS-specific source trees around a common C engine, existing Linux CLI tools and detailed Ubuntu/Windows plans. Old Windows artifacts were removed.
Questions
Does HushDisk ever write my data to disk decrypted?
Mounting doesn't. Data is decrypted in memory as it is read, and no decrypted copy of the container is written anywhere. Your operating system can still cache or swap memory, and anything you copy out of the drive is an ordinary unencrypted file.
Two operations do write plaintext on purpose. Exporting a decrypted image writes it to the file you choose, through a private temporary file next to it. Capturing a USB drive keeps a private raw copy of the device on the destination drive until the encrypted container is finished, then removes it. If either operation is cut short by a crash, power loss or a failed cleanup, a temporary file with decrypted data can stay behind; delete it.
Is it safe to write to a mounted container?
Writing is off until you turn it on, and it is still experimental. In containers the apps create, every change is flushed through two checkpoints, and a container whose writable session didn't end cleanly is refused for writing until it has been checked. Power loss and unplugging a disk in the middle of a write haven't been fully tested yet, so keep a separate backup of anything you write.
What happens when I delete a file on a mounted container?
On macOS, Finder asks for confirmation and removes the file permanently. It doesn't go to the Trash, so no decrypted copy ends up outside the container, and it can't be restored from the Trash. This is normal deletion, not secure erasure.
Which cipher should I choose?
AES-256-XTS, the default. The other ciphers are there so that containers made by older software keep working. DES, Arcfour and XOR in particular offer little protection.
Can I open containers made with FreeVDF?
Yes. Older unsalted, AES and salted containers open as they are, and opening one never changes its format. To move a container to the current format, make a converted copy; the original stays untouched.
What if I forget the password?
There is no password recovery. Keep the password somewhere safe, or let HushDisk save it in your system keychain.
What is the difference between Basic and Pro?
Today both editions have the same features. Pro will add hidden volumes and secure file deletion once they are ready; neither is in current builds.
Does HushDisk send anything over the internet?
No. The apps have no telemetry and no update checks. On Windows, each mounted container is served over a connection that never leaves the computer.
Does this website track me?
No. It sets no cookies, uses no analytics and loads nothing from other servers. If you switch between light and dark, that choice is stored only in your browser.
Support
Questions, bug reports and security problems all go to the same address. Include your system, the HushDisk version and build, and what you were doing when the problem appeared.