Crypta is an alpha-stage, security-focused scaffold for zero-trust, end-to-end encrypted communication. It has not been independently audited and must not be treated as production-ready security software.

Do not report vulnerabilities through public GitHub issues, discussions, pull requests, screenshots, or social media.

Please report suspected vulnerabilities privately by contacting the repository maintainer. If GitHub private vulnerability reporting is enabled for this repository, use that channel first. Otherwise, use the maintainer contact listed in the repository profile or open a non-sensitive issue asking for a private security contact without disclosing technical details.

Include as much of the following as possible:

• Affected commit, branch, or release.
• Vulnerable component or endpoint.
• Reproduction steps or proof-of-concept details.
• Expected and actual impact.
• Whether secrets, private keys, tokens, credentials, or real user data may be exposed.
• Logs or screenshots with sensitive information redacted.
• Any suggested remediation.

Keep vulnerability details private until maintainers have confirmed the issue, prepared a fix or mitigation, and coordinated disclosure timing with you. Do not test against systems you do not own or have explicit permission to assess.

Crypta currently provides a prototype foundation for ciphertext envelope handling, WebAuthn/passkey challenge validation and credential persistence, device trust records, prekey storage, key transparency records with verifier-produced checkpoint metadata, audit logging, encrypted attachment metadata grants, and governance/policy logic.

The project does not yet provide a complete, audited secure messenger. Cryptographic changes, authentication changes, storage changes, logging changes, and deployment changes must be reviewed with extra care and documented clearly.

• WebAuthn finish endpoints validate challenge, origin, ceremony type, replay state, and credential membership, but full audited authenticator signature verification still requires complete Yubico ceremony storage and review.
• The Go security verifier is a hardening boundary for production-style verification work, not an independent security audit.
• Mobile secure-key storage is interface-level scaffolding, not complete native iOS/Android implementation.
• Signal-style, PQXDH-style, and MLS-inspired concepts are represented as architecture and provider boundaries, not independently verified cryptographic implementations.
• Server, deployment, and operational controls require hardening before production use.