open source · Apache-2.0 · Apple Silicon

Hardware-level cryptography for macOS. Zero performance loss.

Kuytu is a local encrypted vault built on Apple's own primitives: native APFS, hardware-accelerated AES-256-XTS, and keys sealed inside the Secure Enclave. No macFUSE. No FUSE-T. No kernel extensions. Unlock with Touch ID — if the fingerprint set changes, the hardware makes the slot unusable; Kuytu makes it permanent: the slot record is deleted on first invalidation, and the vault keeps opening with the password and recovery key.

macOS 26+ · Swift · no third-party crypto primitives

kuytu — zsh
$ kuytu create ~/Vaults/main --with touch-id
✓ APFS sparsebundle · AES-256-XTS · hardware accelerated
✓ DEK: 32 bytes from hardware TRNG — never stored in plaintext
✓ sealed 3 slots → vault.keyslots
$ kuytu open ~/Vaults/main
◆ Touch ID verified · biometryCurrentSet intact
✓ mounted /Volumes/main — native APFS · no FUSE · no KEXT
$
APFS sparsebundle· AES-256-XTS· Argon2id· Secure Enclave P-256· AES-256-GCM + AAD· Touch ID

DESIGN PRINCIPLES

Built on Apple's silicon — not on top of it.

Kuytu writes no crypto of its own and touches no plaintext. Block cipher, disk format and integrity are Apple's job. Kuytu's job is key management, recoverability and behavior under attack.

FUSE-free by design

No macFUSE. No FUSE-T. No kernel extensions. The vault is an APFS encrypted sparse bundle — the macOS kernel does the encrypting, with hardware acceleration. Kuytu's code never sees your data.

zero kext · zero userspace fs · zero overhead

Sealed by the Secure Enclave

The Touch ID slot is wrapped by a P-256 key that never leaves the Secure Enclave, gated by biometryCurrentSet. If the fingerprint set changes — even under duress — the slot becomes unusable at the hardware level. That invalidation is reversible, so Kuytu enforces permanence: on the first invalidation the biometric slot record is deleted; the vault keeps opening with the password and recovery key (SECURITY.md ↗).

p-256 · ecies · biometryCurrentSet

Fail-secure, not fail-safe

When in doubt, Kuytu locks instead of leaking. Every key wrap is authenticated AES-256-GCM with bound context, and recovery is a script you can run without trusting Kuytu at all.

aes-256-gcm · aad-bound · recover.sh

UNDER THE HOOD

One data key. Three independent slots.

The Data Encryption Key (DEK) encrypts the vault. It is never stored in plaintext — each slot holds its own wrap of the same DEK, and no slot can unlock another.

Touch ID

SEP P-256
ECIES wrap

Passphrase

Argon2id → KEK
AES-GCM wrap

Recovery

256-bit key
HKDF-SHA256

DEK — 32 BYTES

hardware TRNG · never written in plaintext

APFS sparsebundle · AES-256-XTS

encrypted by the macOS kernel · hardware accelerated

vault.keyslots format v1 (illustrative)
{
  "format": 1,
  "slots": [
    { "id": "touch-id",
      "seal": "SEP P-256 · biometryCurrentSet",
      "wrap": "ECIES-X963-SHA256-AESGCM" },
    { "id": "passphrase",
      "kdf":  "argon2id(m=256MiB, t=3, p=4)",
      "wrap": "AES-256-GCM" },
    { "id": "recovery",
      "kdf":  "HKDF-SHA256",
      "wrap": "AES-256-GCM" }
  ],
  "aad": "vault_id ‖ slot_id ‖ format_version"
}
  • Changing your passphrase rewrites one slot — the disk image is never re-encrypted.
  • AAD binds every wrap to its vault, slot and format version — slots can't be transplanted or downgraded.
  • Recovery key is 256-bit Crockford Base32 — human-transcribable, no ambiguous characters. recover.sh works without Kuytu installed.

HONEST BY DESIGN

What it protects. What it doesn't.

A security tool that won't state its limits is asking for blind trust. Kuytu states them instead.

Protects against

  • Stolen or lost Mac — a locked vault is unreadable
  • Physical access to a powered-off or locked machine
  • Disk removed and mounted in another machine
  • Stolen backups — copies are sealed by the same DEK
  • Stolen vault.keyslots — it holds no plaintext secrets
  • Forced fingerprint enrollment — biometryCurrentSet makes the slot unusable; Kuytu permanently deletes the record

Out of scope — and it says so

  • Malware running while the vault is mounted
  • Keyloggers and screen capture — your passphrase can still be taken
  • Memory attacks on a running machine and cold-boot attacks
  • A recovery key you store somewhere unsafe
  • Anything requiring blind faith — read the full threat model in the README

ENGINEERING NOTES

Decisions, written down.

Every non-obvious choice in Kuytu gets a post-mortem while the reasoning is still fresh.

architecture in the works

Why native APFS instead of FUSE-T

FUSE-T ships as a closed-source binary and fronts an unauthenticated loopback NFS server. For an encryption tool that's a non-starter — here's the full breakdown.

rejected: fuse-t · macfuse · fskit

war story in the works

Base64 at the OS boundary: a hdiutil story

When your only interface to the kernel is a command-line flag, encoding isn't cosmetic. It's the difference between a mounted vault and corrupted key material.

hdiutil · key transport · edge cases

key management in the works

Three slots, one DEK: a fail-secure hierarchy

Why horizontal key slots beat a single master password — and what "fail-secure" actually means when the hardware says no.

kek/dek · aad · secure enclave