| Version | Supported | Notes |
|---|---|---|
| 3.2.x | Yes | Current release — redesigned TUI, password strength, bug fixes |
| 3.0.x | Yes | Whole-disk encryption, extended QSV format |
| 2.0.x | Yes | TUI mode, universal format support |
| 1.1.x | Yes | Security hardening, verify command |
| < 1.1.0 | No | Superseded — missing key zeroization and path traversal protection |
If you discover a security vulnerability in QShield, please report it responsibly.
Do not open a public GitHub issue for security vulnerabilities.
Instead, use GitHub Security Advisories or email jbaelaw (via GitHub profile) with:
- A description of the vulnerability
- Steps to reproduce (including QShield version and platform)
- Potential impact assessment (confidentiality, integrity, availability)
- Suggested fix or mitigation (if any)
Response timeline:
- Acknowledgment within 48 hours
- Initial assessment within 72 hours
- Critical vulnerabilities patched and released as soon as possible
- Credit given in release notes (unless reporter requests anonymity)
| Category | Examples |
|---|---|
| Cryptographic flaws | Key leakage, nonce reuse, weak randomness, padding oracle |
| Key material exposure | Failure to zeroize secrets, secrets in swap/core dumps |
| File format attacks | Malformed .qsv files causing crashes, memory corruption, or DoS |
| Path traversal | Tar extraction escaping the output directory |
| Memory safety | Use-after-free, buffer overflows, uninitialized memory reads |
| Side-channel leakage | Timing-dependent key recovery, cache-based attacks |
| Denial of service | Allocation bombs, infinite loops from crafted input |
| Block device safety | Unintended writes to mounted devices, data corruption |
| Category | Reason |
|---|---|
| Weak passwords | User responsibility; QShield warns on passwords < 8 characters |
| Social engineering | Outside software scope |
| Physical access attacks | QShield protects data at rest, not against live system compromise |
| Upstream crate vulnerabilities | Report to respective maintainers (see below) |
| Feature requests | Use GitHub Issues instead |
QShield relies on the following third-party Rust crates. None have been independently audited at the time of writing:
| Crate | Purpose | Maintainer |
|---|---|---|
ml-kem |
ML-KEM-768 (FIPS 203) | RustCrypto |
x25519-dalek |
X25519 Diffie-Hellman | dalek-cryptography |
aes-gcm |
AES-256-GCM authenticated encryption | RustCrypto |
argon2 |
Argon2id password hashing | RustCrypto |
sha3 |
SHA3-256 (used in HKDF) | RustCrypto |
hkdf |
HKDF key derivation | RustCrypto |
zeroize |
Secure memory zeroing | RustCrypto |
Vulnerabilities in upstream crates should be reported to their respective maintainers. If an upstream vulnerability affects QShield specifically, please also notify us so we can assess impact and coordinate disclosure.
| Decision | Rationale |
|---|---|
| Hybrid KEM (ML-KEM + X25519) | Defense-in-depth against both quantum and classical attacks |
| Argon2id (64 MiB, 3 iter, 4 lanes) | Memory-hard KDF resists GPU/ASIC brute-force; id variant provides side-channel resistance |
| Per-chunk nonces (counter + random) | Prevents nonce reuse across chunks while maintaining uniqueness across encryptions |
| Ephemeral KEM keypairs | No long-term private key stored — forward secrecy per encryption |
| Chunk size limit enforcement | Decryption rejects chunks > 1 MiB + 64 B to prevent allocation-based DoS |
| Path traversal validation | All tar entry paths checked for ../, absolute paths, and prefix components before extraction |