Skip to content

Security: reallyme/crypto

SECURITY.md

Security Policy

reallyme-crypto is cryptographic infrastructure. We take vulnerability reports seriously and appreciate coordinated disclosure.

Reporting a Vulnerability

Do not open a public issue for a security vulnerability.

Report privately through either channel:

  • GitHub private vulnerability reporting: use the "Report a vulnerability" button under this repository's Security tab (SecurityAdvisoriesReport a vulnerability).
  • Email: security@really.me. For end-to-end encrypted disclosure, request our current PGP key in a first, contentless message; we will reply with it before you send details.

Please include, to the extent you can:

  • the affected crate, function, and lane (native, wasm, swift, kotlin, android, or typescript);
  • the commit or version you tested;
  • a minimal reproduction (input bytes, steps, or a failing test);
  • your assessment of impact (e.g. key recovery, forgery, panic/DoS, side-channel).

What to Expect

  • Acknowledgement within 3 business days.
  • Triage and initial assessment within 10 business days, including a severity rating and whether we can reproduce.
  • Coordinated disclosure: we aim to ship a fix and publish an advisory within 90 days of triage, sooner for actively exploited issues. We will agree on a disclosure date with you and credit you unless you prefer to remain anonymous.

We will keep you updated as the fix progresses and will let you know if we need more time or information.

Scope

In scope — vulnerabilities in this repository's code, for example:

  • key recovery, signature forgery, or authentication bypass;
  • incorrect cryptographic output versus the referenced standard (FIPS 203/204, RFC 8032/6979/8785/8439, SEC1, etc.);
  • panics, unbounded allocation, or stack exhaustion reachable from untrusted input (denial of service);
  • timing or other side channels in secret-dependent code paths;
  • secret material that is not zeroized, or that leaks through errors, logs, or the FFI boundary;
  • a platform lane silently substituting a different cryptographic backend than the one selected.

Out of scope:

  • vulnerabilities in dependencies (report those upstream; tell us so we can pin or mitigate);
  • issues that require an already-compromised host, a malicious build toolchain, or physical access;
  • missing hardening that has no concrete exploit (send it as a normal issue or pull request).

Supported Versions

Security fixes are released on the active package line.

Version Status
0.3.x Supported
0.2.x and earlier Unsupported

For source-based consumption, pin a release tag or exact commit and watch GitHub releases and security advisories.

Version install examples describe published releases. Before publication, the corresponding tag is intentionally absent. The Swift package release workflow creates the immutable v<version> GitHub release and tag only after the release commit and XCFramework artifact have passed their verification gates.

Cryptography And Assurance

  • We do not implement cryptographic primitives from scratch; we wrap vetted implementations (RustCrypto, ed25519-dalek, x25519-dalek, ml-kem, ml-dsa, BouncyCastle, Bitcoin Core libsecp256k1 through reallyme/CSecp256k1) and platform crypto (CryptoKit, JCA/JCE) behind a uniform, misuse-resistant API.
  • Cross-implementation conformance vectors pin our Rust output against an independent oracle (@noble/*), including deterministic ML-KEM encapsulation, implicit rejection, and deterministic ML-DSA signatures.
  • Coverage-guided fuzz harnesses exercise the operation protobuf/ProtoJSON, JWK/multikey, RSA DER, and P-256 SEC1/ECDSA DER boundaries. The complete current coverage and gap inventory is in fuzz/README.md; we do not claim that every parser and platform decoder is fuzzed yet.
  • The HPKE Base composition has a machine-checked Tamarin model in formal/ proving plaintext confidentiality against a network adversary.
  • Provider choice is part of the security contract. The generated backend matrix in PROVIDER_POLICY.md records each Swift, Kotlin/JVM, Kotlin/Android, and TypeScript/WASM lane; unsupported lanes must fail with a typed unsupported-algorithm result instead of silently choosing another backend.

See SECURITY_MEMORY_MODEL.md for the secret-memory model and operational controls this codebase is held to.

There aren't any published security advisories