Release signing & verification

OpaqueVault binaries on releases.opaquevault.com are signed with minisign using an Ed25519 key. This page documents the trust model, the key, and the manual verification path.

Why this matters

Every curl -fsSL get.opaquevault.com | sh install puts a binary on your $PATH. If an attacker can make you install a malicious binary that pretends to be ov, they own:

• Your master password (typed into a fake prompt)
• Your KEK (derived from the master password)
• Every secret in your vault

We take that seriously, so the install path has two independent verification steps:

1. SHA-256 checksum of the tarball, validated against ov_<version>_checksums.txt published in R2 alongside the binary
2. Ed25519 signature on ov_<version>_checksums.txt itself, validated against a public key embedded in the install script (NOT downloaded from R2)

Both must pass. The signature step defends against the case where an attacker compromises the R2 bucket and rewrites both the binary and the checksums file to match — they would also need to compromise the Cloudflare Worker that serves the install script (a separate trust root) to forge against the embedded key.

The public key

untrusted comment: minisign public key F89BAB08772C1C0B
RWQLHCx3CKub+D3Wnc1zX/YBVr1fJD5SrK08d2xp4XoTQipbFET8V0fU

Available at:

• https://opaquevault.com/.well-known/ov-release.pub (this site)
• workers/get/ov-release.pub in the public repo
• Embedded as RELEASE_PUBLIC_KEY in workers/get/worker.js

All three sources must agree. If you ever see them disagree, stop installing and report at [email protected].

Key ID: F89BAB08772C1C0B Algorithm: Ed25519 (see “Why Ed25519, not ML-DSA?” below) Generated: 2026-05-02

Verifying a release manually

Install minisign locally:

brew install minisign            # macOS
sudo apt install minisign        # Debian/Ubuntu
scoop install minisign           # Windows

Then download the artifact, the checksums file, and the signature:

VERSION=v0.9.5
VERSION_NO_V=${VERSION#v}

curl -fsSL -O https://opaquevault.com/.well-known/ov-release.pub
curl -fsSL -O https://releases.opaquevault.com/${VERSION}/ov_${VERSION_NO_V}_checksums.txt
curl -fsSL -O https://releases.opaquevault.com/${VERSION}/ov_${VERSION_NO_V}_checksums.txt.minisig
curl -fsSL -O https://releases.opaquevault.com/${VERSION}/ov_darwin_arm64.tar.gz

Verify the signature on the checksums file:

minisign -V -p ov-release.pub -m ov_${VERSION_NO_V}_checksums.txt

Expected output:

Signature and comment signature verified
Trusted comment: ...

Then verify the tarball matches the signed checksums:

shasum -a 256 -c ov_${VERSION_NO_V}_checksums.txt --ignore-missing

Expected:

ov_darwin_arm64.tar.gz: OK

Both checks must pass.

Forcing verification on curl | sh

The install script falls back to SHA-256-only verification if minisign is not installed (so the one-liner Just Works for users who haven’t set up minisign yet). For production / CI install paths, set OV_REQUIRE_SIGNATURE=1 to fail-closed instead:

OV_REQUIRE_SIGNATURE=1 curl -fsSL https://get.opaquevault.com | sh

This refuses to proceed if minisign is not on $PATH, and refuses to proceed if the signature does not verify.

Why Ed25519, not ML-DSA?

OpaqueVault’s transport encryption uses a hybrid post-quantum scheme (X25519 + ML-KEM-768) because of the harvest-now-decrypt-later threat: an attacker can capture today’s ciphertext, store it, and decrypt it once a cryptographically relevant quantum computer exists.

Code signing has no such exposure. A signature forged in 2032 does not retroactively compromise installs from 2026 — only contemporaneous installs can be attacked, and we will have rotated to a PQC scheme well before contemporaneous CRQC attacks are feasible. NIST’s CNSA 2.0 timeline puts signature migration in the 2033–2035 window for this reason.

The mainstream code-signing ecosystem (Sigstore, Apple notarization, package managers) is currently mid-migration to ML-DSA. Sigstore’s tracking issue (sigstore/fulcio#2191) is open as of 2026-Q2; cosign does not yet ship ML-DSA support. Shipping Ed25519 today aligns with the entire ecosystem.

We will migrate this signing key to ML-DSA (or a hybrid Ed25519 + ML-DSA scheme) when stable Sigstore tooling ships ML-DSA support. The migration is graceful: we publish a new public key, update the embedded constant in worker.js, and start signing new releases with both keys for a transition period.

Reporting issues

If you find a release where:

• The minisign signature on checksums.txt does not verify against the public key on this page, OR
• The public key on this page differs from workers/get/ov-release.pub in git, OR
• The public key embedded in worker.js differs from either of the above

…stop installing immediately and email [email protected] with the version number and which check failed. See /.well-known/security.txt for our full disclosure policy.