Do NOT open a public issue. Instead:

1. Email: security@hie-project.org (or the maintainer's email listed in pyproject.toml)
2. Include:
   • Description of the vulnerability
   • Steps to reproduce
   • Impact assessment
   • Suggested fix (if any)
3. You will receive an acknowledgment within 48 hours
4. We aim to provide a fix or mitigation within 14 days

HIE implements multiple layers of cryptographic protection:

• Entropy: Multi-source (hardware RNG + timing jitter + Argon2id-hardened personal seed)
• Permutations: Key-dependent Fisher-Yates shuffle (D! search space vs. D for circular shift)
• Key derivation: Per-component derived keys prevent cross-component leakage

• Known-Plaintext Attack (KPA): Noise injection corrupts recovered key attempts
• Brute-Force: D! = 10,000! ≈ 10^35,659 possible permutations
• Side-Channel: Constant-time operations for security-critical comparisons (best-effort in Python)
• Quantum: Information-theoretic security of Shamir sharing is quantum-resistant

• Encryption: AES-256-GCM for all on-disk data
• Key Derivation: PBKDF2 (480k iterations) for passphrase → AES key
• Integrity: Multi-level monitoring (statistical, fingerprint, cross-component)
• Memory: Best-effort secure wiping of key material

HIE is designed to protect against:

• ✅ Passive observers (encrypted storage)
• ✅ Known-plaintext attackers (noise injection)
• ✅ Brute-force permutation search (D! search space)
• ✅ Component-level compromise (derived keys)
• ⚠️ Side-channel attacks (best-effort in Python — use C extension or HSM for production)
• ⚠️ Memory forensics (best-effort wiping — use HSM for production)
• ❌ Physical access to running process memory (out of scope — use HSM)

We follow responsible disclosure practices. If you discover a vulnerability:

1. Do not disclose publicly until a fix is available
2. Do not exploit the vulnerability beyond proof-of-concept
3. We will credit you in the release notes (unless you prefer anonymity)