hybrid PQC for encryption

[adam-moss]

Apologies is this is planned but I checked the roadmap and couldn't see anything obvious. Do you have any plans to support hybrid PQC for encryption?

Thanks!

[m3nu]

Not planned, and I think the framing doesn't quite apply here — let me explain why rather than just saying "no".

Hybrid PQC (classical + ML-KEM) addresses asymmetric key establishment. vykar's repository format doesn't perform any. It's symmetric end to end: AES-256-GCM or ChaCha20-Poly1305 for data, a random 64-byte master key from OS entropy wrapped with Argon2id + AES-256-GCM at keys/repokey, and keyed BLAKE2b-256 for chunk IDs. There's no key agreement, KEM, or signature scheme in the format, so there's nothing to hybridize.

The upside is that this is already the quantum-resistant case. Grover's algorithm gives at most a quadratic speedup, leaving 256-bit AEAD keys at a ~128-bit post-quantum level, and it doesn't meaningfully threaten keyed BLAKE2b-256. Backups written today aren't exposed to harvest-now-decrypt-later on the ciphertext. The practical bound is passphrase entropy feeding Argon2id, not algorithm choice.

Asymmetric crypto only shows up in transport — TLS (rustls) for S3/REST, SSH (russh) for SFTP. Those are ephemeral session keys, and breaking a recorded session yields only objects that are already symmetrically encrypted. PQ key exchange there arrives via dependency updates, not a format change.

I've documented this in the architecture guide under Cryptography → Quantum Resistance so it's easier to find.

Where it would become a real design question: if vykar ever grows a write-only client key (back up without the ability to decrypt/restore, age-style recipient key) or signed snapshots for third-party verification. Both need public-key crypto, and hybrid X25519 + ML-KEM-768 is what I'd reach for. Is a write-only client key closer to what you're actually after? That's a reasonable request and I'd keep it open under its own title.