OPAQUE

  import "github.com/bytemare/opaque"

This package implements OPAQUE (RFC 9807), the augmented password-authenticated key exchange (aPAKE) protocol that is secure against pre-computation attacks. It enables a client to authenticate to a server without ever revealing its password to the server.

This implementation is developed and maintained by one of the authors of the RFC. It has not been independently audited, and even though great care about security and performance has been taken, it comes with no warranty.

What is OPAQUE?

OPAQUE is an aPAKE that is secure against pre-computation attacks. OPAQUE provides forward secrecy with respect to password leakage while also hiding the password from the server, even during password registration. OPAQUE allows applications to increase the difficulty of offline dictionary attacks via iterated hashing or other key stretching schemes. OPAQUE is also extensible, allowing clients to safely store and retrieve arbitrary application data on servers using only their password.

References

• The original paper from Jarecki, Krawczyk, and Xu.
• RFC 9807.
• OPAQUE in WhatsApp to enable end-to-end encrypted backups.

Documentation

You can find the documentation and usage examples in the package doc.

Security and Operational Notes

• Use a confidential transport (e.g., TLS 1.3+) to protect client identities on the wire.
• Keep the OPRF global seed single and stable across clients, and derive unique per-client OPRF keys using a stable, unique credential identifier.
• Ensure consistent configuration (groups, hashes, KSF) across registration and subsequent logins.
• The server must always verify KE3 with LoginFinish before using the session secret.
• For unknown users, return a fake record (GetFakeRecord) to reduce user-enumeration signals.
• Rate limiting and replay tracking are application layer responsibilities. OPAQUE authenticates the transcripts, and session management is up to you.
• The server is concurrency-safe for typical use. Avoid a hidden global state in your app layer.
• Store ServerKeyMaterial securely. Treat secrets (e.g., private key and OPRF seed) appropriately.
• Client.ClearState() is a best-effort to clear ephemeral material, but zeroization has language/runtime limits.

Versioning

SemVer is used for versioning. For the versions available, see the tags on the repository.

Release Integrity (SLSA Level 3)

Releases are built with the reusable bytemare/slsa workflow and ship the evidence required for SLSA Level 3 compliance:

• 📦 Artifacts are uploaded to the release page, and include the deterministic source archive plus subjects.sha256, signed SBOM (sbom.cdx.json), GitHub provenance (*.intoto.jsonl), a reproducibility report (verification.json), and a signed Verification Summary Attestation (verification-summary.attestation.json[.bundle]).
• ✍️ All artifacts are signed using Sigstore with transparency via Rekor.
• ✅ Verification (or see the latest docs at bytemare/slsa):

curl -sSL https://raw.githubusercontent.com/bytemare/slsa/main/verify-release.sh -o verify-release.sh
chmod +x verify-release.sh
./verify-release.sh --repo <owner>/<repo> --tag <tag> --mode full --signer-repo bytemare/slsa

Run again with --mode reproduce to build in a container, or --mode vsa to validate just the verification summary.

Contributing

Please read CONTRIBUTING.md for details on the code of conduct, and the process for submitting pull requests.

License

This project is licensed under the MIT License - see the LICENSE file for details.