Security goals

VORTEX-256 targets IND-CCA2 security as a KEM:

Property	Meaning
Confidentiality	Ciphertexts reveal nothing about the shared secret
Integrity	Tampered ciphertexts produce wrong secrets (implicit rejection)
Forward secrecy (per session)	Each encapsulation uses fresh randomness

Threat model

In scope (defended against)

Threat	Mitigation
Passive eavesdropping	Lattice hardness (RotMLWE) — ciphertext reveals nothing about shared secret
Ciphertext tampering	FO transform + implicit rejection — wrong secret returned, no error leak
Chosen-ciphertext attacks	IND-CCA2 via FO — decapsulation safe even with attacker-crafted inputs
Quantum computers	Lattice assumption — no known polynomial-time quantum algorithm for RotMLWE

Out of scope (your responsibility)

Threat	What you must do
Private key compromise	Protect sk at rest (PEM mode 0600, HSM, KMS)
Side-channel attacks	Use native C backend; avoid pure Python in timing-sensitive paths
Implementation bugs	Keep dependencies updated; run test suite; report vulnerabilities
Algorithm breakthrough	Monitor cryptanalysis; plan algorithm agility
Shared secret misuse	Derive application keys with a proper KDF (HKDF, etc.) — don't use raw 32 B directly

Cryptographic assumptions

Primary: RotMLWE

Breaking VORTEX requires solving the Rotational Module Learning With Errors problem: given (a₀, b₀), (a₁, b₁), …, (a_{K-1}, b_{K-1}) where aᵢ = σⁱ(a) and bᵢ = aᵢ·s + eᵢ, recover the secret s.

Case	Known relationship
K = 1	Reduces to standard RLWE
K > 1	Open research question — correlated instances share structure

Secondary: Random oracle model

The FO transform and KDF are analyzed in the random oracle model, assuming SHA-3 and SHAKE behave as ideal hash functions.

Security properties by operation

Operation	Security level	Notes
generate_keypair()	IND-CPA secure public key	Secret s and rejection token z never exposed
encapsulate(pk)	IND-CCA2 shared secret	Fresh randomness per call; deterministic given same coins
decapsulate(ct, sk)	Implicit rejection	Never leaks validity via return value or exception (pure Python path)
PEM encoding	Encoding only — no additional security	Private key files set to mode 0600

Key material handling

Do

✓  Store private keys encrypted at rest
✓  Use PEM with restrictive file permissions (automatic with write_pem_file)
✓  Rotate keys on compromise or schedule
✓  Derive application keys: HKDF(shared_secret, salt, info)
✓  Zero sensitive buffers after use (C library does this for stack copies)
✓  Use native backend in production-facing code paths

Don't

✗  Log public keys, private keys, ciphertexts, or shared secrets
✗  Commit .pem or .key files to version control
✗  Use the raw 32-byte shared secret directly as an AES key without derivation
✗  Assume IND-CCA2 extends to your application protocol without analysis
✗  Deploy in production without independent security review

Research preview limitations

VORTEX-256 has not been standardised by NIST and has not received the years of public cryptanalysis that ML-KEM (FIPS 203) has.

Concern	Status
Novel assumption (RotMLWE)	Published for community review
Parameter selection	Based on ML-KEM analogues; not independently optimised
Side-channel resistance	Best-effort in C; pure Python is not constant-time
Formal security proof	FO reduction to RotMLWE; RotMLWE-to-RLWE reduction open for K>1
Post-quantum security level	Estimated ~128-bit quantum (same ring as Kyber-512)

Reporting vulnerabilities

If you discover a security issue:

1. Do not open a public GitHub issue
2. Email hello@bajpailabs.com with:
   • Description of the vulnerability
   • Steps to reproduce
   • Impact assessment
   • Suggested fix (if any)
3. Allow 90 days for remediation before public disclosure

We follow coordinated disclosure practices.

Compliance guidance

Requirement	VORTEX-256 status
FIPS 140 validated	❌ Not validated
NIST-approved (FIPS 203)	❌ Different algorithm
Export control (EAR)	Consult legal counsel — open-source crypto software
GDPR / data protection	KEM itself is agnostic; your key management must comply

For regulated environments requiring NIST-approved algorithms, use ML-KEM (Kyber) instead.

Security checklist for integrators

□  Threat model documented for your use case
□  Private keys stored securely (encrypted, access-controlled)
□  Shared secret derived with HKDF before use as session key
□  Ciphertext length validated (768 bytes) before decapsulation
□  No secret material in logs, metrics, or error messages
□  Native backend used in timing-sensitive deployments
□  Key rotation policy defined
□  Independent security review completed (for production)