If you discover a security vulnerability, please report it responsibly:
- Do NOT open a public GitHub issue
- Email the maintainer directly or use GitHub's private vulnerability reporting
- Include steps to reproduce, impact assessment, and suggested fix if possible
| Primitive | Algorithm | Library | Purpose |
|---|---|---|---|
| Symmetric encryption | AES-256-GCM | aes-gcm (RustCrypto) |
File encryption with authentication |
| Key wrapping | RSA-2048 PKCS#1 v1.5 | rsa + YubiKey PIV |
Session key protection |
| Hashing | SHA-256 | sha2 (RustCrypto) |
Certificate fingerprinting |
| Compression | Zstandard | zstd |
Pre-encryption compression |
| RNG | OS CSPRNG | OsRng |
Key and nonce generation |
YubiKey PIV performs raw RSA decryption on-device. The yubikey crate (v0.8) handles PKCS#1 v1.5 unpadding but does not support OAEP unpadding of the raw RSA output. PKCS#1 v1.5 is acceptable in this context because:
- The private key never leaves the YubiKey hardware
- An attacker cannot perform chosen-ciphertext oracle queries -- each decryption requires physical touch
- The session key is random and single-use, limiting exposure
- Session keys:
Zeroizing<Vec<u8>>-- automatically zeroed on drop - PINs: Zeroized immediately after use in both UI and worker thread
- Intermediate data: Tar archives and compressed data explicitly zeroized after processing
The .ubk file header (magic, version, key slots) is included as AES-GCM Additional Authenticated Data (AAD). Any modification to the header will cause decryption to fail with an authentication error.
- Maximum 4 key slots per file
- Maximum 1024 bytes per wrapped key
- Maximum 100GB ciphertext length
- Magic bytes and version validated on read
In scope:
- Protecting files at rest with hardware-bound encryption
- Preventing decryption without physical YubiKey + PIN + touch
- Detecting file tampering via authenticated encryption
Out of scope:
- Protection against malware with root/admin access on the encrypting machine
- Side-channel attacks on the host system
- Physical attacks on the YubiKey hardware itself
- Denial of service (e.g., corrupting .ubk files)
- No streaming encryption: Entire file is loaded into memory. Files larger than available RAM will fail.
- No key rotation: Once encrypted, files cannot be re-encrypted with a different key without full decrypt/re-encrypt.
- Single algorithm: No algorithm agility -- future format versions may address this.
All cryptographic operations use audited, well-maintained Rust crates from the RustCrypto project. The yubikey crate is maintained by iqlusion (Tony Arcieri).