Security

Sécurité du réseau

Posture

Osage Network runs on the strict end-to-end post-quantum profile (LUX_STRICT_E2E_PQ) by default. Every authentication path — wallet, transaction, validator handshake, bridge, upgrade key — uses NIST-standardised post-quantum primitives only. Classical signatures (secp256k1, ECDSA, BLS without quantum-safe wrapping) are rejected at the protocol level on mainnet.

Standards

• FIPS 204 (ML-DSA) for digital signatures — ML-DSA-65 standard, ML-DSA-87 high-value.
• FIPS 203 (ML-KEM) for key encapsulation — ML-KEM-768 P2P, ML-KEM-1024 validator-to-validator.
• FIPS 205 (SLH-DSA) for recovery primitives.
• FIPS 202 (SHA-3 / SHAKE) throughout; no BLAKE3, no legacy SHA-2.
• SP 800-185 (cSHAKE / KMAC / TupleHash) for domain separation.
• SP 800-90A DRBG for randomness; never Math.random().

Audit

• Independent annual audit. Conducted by a NIST-accredited cryptographic-review firm; report published in the Foundation annual report.
• Formal proofs. Soundness proofs for Pulsar-M finality and the strict-PQ profile are maintained in ~/work/lux/proofs/strict-e2e-pq/ (Lean 4 + TLA+).
• Reproducible builds. Validator binaries are signed and reproducible; SHA3-384 build digests are published with every release.
• Bug bounty. Standing programme for in-scope cryptographic primitives and consensus paths.

Disclosure

Vulnerability disclosures are handled by the Osage Security Response Team. Standing target: acknowledge within 24 hours, triage within 72 hours, public disclosure coordinated with the reporter and any affected downstream operators.

• Email. [email protected]
• PGP. Public key fingerprint published at docs.osage.network/security/pgp
• In-scope. The Osage Network core, the validator binaries, the bridge contracts, the IAM tenant at iam.osage.id, the KMS at kms.osage.id.
• Out-of-scope. Marketing surfaces, third-party block-explorer UIs not operated by Osage, denial-of-service against public RPC endpoints.

Standing controls

• Two-factor on every operator account; hardware keys preferred.
• Quarterly rotation of long-lived credentials.
• Per-org container registries; no cross-org pulls.
• OIDC exchange for ephemeral CI tokens where supported.
• Audit trail for every production change; no deploys from a developer laptop into mainnet.

Engagement

Security disclosures: [email protected]. Validator operations: /validators. Audit and compliance: [email protected].