Skip to content

Security: theleaks/UbiKeyZipper

Security

SECURITY.md

Security Policy

Reporting Vulnerabilities

If you discover a security vulnerability, please report it responsibly:

  1. Do NOT open a public GitHub issue
  2. Email the maintainer directly or use GitHub's private vulnerability reporting
  3. Include steps to reproduce, impact assessment, and suggested fix if possible

Security Design

Cryptographic Primitives

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

Why PKCS#1 v1.5 Instead of OAEP?

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:

  1. The private key never leaves the YubiKey hardware
  2. An attacker cannot perform chosen-ciphertext oracle queries -- each decryption requires physical touch
  3. The session key is random and single-use, limiting exposure

Memory Security

  • 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

Header Authentication

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.

File Format Validation

  • Maximum 4 key slots per file
  • Maximum 1024 bytes per wrapped key
  • Maximum 100GB ciphertext length
  • Magic bytes and version validated on read

Threat Model

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)

Known Limitations

  1. No streaming encryption: Entire file is loaded into memory. Files larger than available RAM will fail.
  2. No key rotation: Once encrypted, files cannot be re-encrypted with a different key without full decrypt/re-encrypt.
  3. Single algorithm: No algorithm agility -- future format versions may address this.

Dependencies

All cryptographic operations use audited, well-maintained Rust crates from the RustCrypto project. The yubikey crate is maintained by iqlusion (Tony Arcieri).

There aren’t any published security advisories