We take security seriously. If you discover a vulnerability in Chorus, please report it responsibly.

1. Preferred method: Open a GitHub Security Advisory (confidential, visible only to maintainers)
2. Alternative: Email the maintainer via the contact information in the repository

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

1. Acknowledgment within 48 hours
2. Initial assessment within 7 days
3. Regular updates on progress
4. Credit in the fix (unless anonymity is requested)

• We follow Coordinated Disclosure: we will work with you to fix the issue before public disclosure
• Please do not open a public issue for security vulnerabilities
• Please allow us reasonable time to address the issue before disclosing publicly

Chorus is designed with security as a core principle:

• End-to-end encryption — All messages encrypted with ChaCha20-Poly1305 AEAD
• Key exchange — X25519 Diffie-Hellman with forward secrecy
• Identity — Ed25519 signatures for authentication
• Key hygiene — Private keys protected with zeroize
• No central server — P2P architecture eliminates server-side attack surface
• Local-only defaults — mDNS discovery keeps traffic on your network by default

• This is an alpha release — the protocol may evolve with breaking changes
• Relay nodes can observe metadata (message size, timing, sender/receiver identities) but not message contents
• Bootstrap nodes are trusted for peer discovery only

No external security audit has been performed yet. Contributions to our security posture are welcome.

Thank you for helping keep Chorus secure.