We take security seriously at YAKMESH™. If you discover a security vulnerability, please report it responsibly.

1. Open a GitHub issue: https://github.com/yakmesh/yakmesh/issues — use the "Security" label if available, or prefix the title with [SECURITY].
2. Email (for sensitive disclosures): security@yakmesh.dev

For sensitive vulnerabilities where public disclosure would be premature, prefer email. For general security concerns, questions, or non-critical findings, a GitHub issue is fine.

• Description of the vulnerability
• Steps to reproduce
• Potential impact
• Suggested fix (if any)

• Acknowledgment: Within 48 hours
• Initial Assessment: Within 7 days
• Resolution Target: Within 30 days (depending on severity)

Security reports are accepted for the latest release only. If you believe you've found a vulnerability in an older version, please verify it against the current release before reporting. Assistance with issues on older versions is available as premium support — contact us at support@yakmesh.dev.

We appreciate responsible disclosure and will:

• Credit you in the security advisory (unless you prefer anonymity)
• Work with you to understand and resolve the issue
• Not take legal action for good-faith security research

YAKMESH implements multiple layers of post-quantum security:

• Post-Quantum Signatures: ML-DSA-65 (NIST FIPS 204)
• Post-Quantum Key Encapsulation: ML-KEM-768 (NIST FIPS 203) via ANNEX E2E sessions
• 144T Ternary Security: Dual-layer cryptographic backbone (NIST + 144T)
• Authenticated Encryption: AES-256-GCM (ANNEX), XChaCha20-Poly1305
• Replay Protection: Phase-epoch based message validation
• Code Integrity: Self-verifying oracle with module sealing
• Entropy: PRAHARI v2 mesh-consensus entropy engine (SHA3 sponge, GPS jitter, mesh timing)

WARNING: The following architectural decisions are FOUNDATIONAL. They MUST NOT be changed without explicit cryptographic review.

Location: identity/node-key.js

The NodeID is a two-part composite:

node-[networkName]-[instanceId]

Security Properties:

1. Codebase Integrity - Network name proves nodes run identical code
2. Instance Uniqueness - Instance ID is deterministically tied to keypair
3. Human Verifiability - Word-based names can be verified verbally
4. Network Segmentation - Different code versions form separate networks

Rejected Simplifications:

Location: oracle/network-identity.js

The indistinguishability obfuscation (iO) system provides:

• Deterministic identity derivation from hashes
• Human-readable, verifiable names
• Phase modulation for replay protection
• One-way derivation (cannot reverse to original hash)

MANDATORY USAGE:

DO NOT:

• Bypass the oracle for "faster" identity generation
• Expose raw hashes in user-facing displays or network messages
• Cache identities without oracle verification
• Accept identities that don't match expected network name
• Display truncated hex hashes (e.g., 7f3a9b2c...) to users

WHY RAW HASH EXPOSURE IS DANGEROUS:

1. Fingerprinting - Track users across sessions
2. Precomputation - Build rainbow tables for known entities
3. Oracle queries - Probe for specific identity existence
4. Correlation - Link identities across different systems

// ❌ WRONG: Exposing raw hash in identifier
const dokoId = `doko-${type}-${hash.slice(0, 16)}`;

// ✅ CORRECT: Use iO obfuscation
const dokoId = `doko-${type}-${deriveNetworkName(hash, 2)}-${deriveNetworkId(hash)}`;
// Result: "doko-trader-qubit-lattice-pq-a7x9"

// ❌ WRONG: Simplified NodeID (NEVER DO THIS)
const nodeId = sha3_256(publicKey);

// ✅ CORRECT: Full iO-based derivation
const nodeId = generateNodeId(publicKey, codebaseHash);
// Result: "node-qubit-lattice-prism-pq-a7x9"

Before merging any identity/crypto changes:

• Does it maintain the two-part NodeID structure?
• Does it preserve codebase hash in identity derivation?
• Does it use ML-DSA-65 (not classical crypto)?
• Does it verify signatures before trusting data?
• Does it respect the iO oracle's role?
• Are all user-facing identifiers using iO obfuscation?
• Are raw hashes only used for internal operations?

• NTP time sources are not suitable for oracle operations (use GPS/PTP/Atomic)

YAKMESH™ is a trademark of PeerQuanta (USPTO Serial No. 99594620)