---
robots: noindex, nofollow
---

# Ed25519, ZIP‑215 & FROST: A Practical Interop Guide for Protocol Developers

**Audience:** protocol engineers and systems developers (not cryptographers)

**Goal:** explain why Ed25519 verification sometimes disagrees across implementations, how ZIP‑215 fixes this, why libraries like `ed25519‑zebra` (Rust) and `ed25519‑consensus` (Rust/Go) matter, and how to build threshold tooling (Trusted‑Dealer key shares, DKG, and FROST signing) that remains compatible with legacy tools like [OpenSSH](https://anongit.mindrot.org/openssh.git) and projects like [Open Integrity](https://github.com/OpenIntegrityProject/core).

---

## 1) The problem in one page

Ed25519 is ubiquitous, but its *verification* rules were left underspecified in RFC 8032. Different libraries made different, perfectly "reasonable" choices around edge cases (canonical encodings of points, which group equation to check, how equality is compared, etc.). The result:

* Two implementations may disagree on whether a particular signature is valid.
* Even a *single* implementation may give different answers between single‑verify and batch‑verify modes.
* In distributed systems (blockchains, consensus protocols, threshold signing flows), these disagreements can cause forks, DoS bugs, or brittle interop.

**Why you should care:** even if you personally never craft weird signatures, an adversary can. And once there are multiple verifiers in the pipeline (libraries, versions, languages), it becomes a coordination hazard.

> "The result is an extremely wide variation in validation criteria across implemententations. The diagram below plots verification results of a 14 × 14 grid of edge cases, with light squares representing accepted signatures, and dark squares representing rejected ones. As the diagram illustrates, verification results are generally inconsistent not just between implementations, but also between different versions and different modes."<br/>
> - _Henry de Valence in [It's 255:19AM. Do you know what your validation criteria are?](https://github.com/hdevalence/ed25519consensus)_
>
>[](https://github.com/hdevalence/ed25519consensus)

---

## 2) What ZIP‑215 changes

ZIP‑215 defines precise, implementation‑independent validity rules for Ed25519, designed to:

1. **Make single‑verify and batch‑verify agree** by using the cofactor‑multiplied (“batched”) verification equation in *both* modes.
2. **Be backwards‑compatible with existing signatures** produced by honest signers (so you don’t break deployed data).
3. **Allow non‑canonical encodings of points** on input while still requiring canonical `s` (prevents trivial malleability), so you don’t accidentally reject something another conforming implementation accepts.

The important practical upshot: if you adopt ZIP‑215, you eliminate most edge‑case disagreement *without* changing how honest signatures are generated or validated by mainstream tools.

---

## 3) Pick the right libraries

* **Rust:** `ed25519‑zebra` (ZIP‑215). If you don’t need Zcash legacy rules at all, `ed25519‑consensus` is a slim fork that keeps only the ZIP‑215 semantics.
* **Go:** `ed25519consensus` provides the same ZIP‑215 rules and a batch verifier.

All of these ensure single vs batch agreement and are engineered for consensus‑critical contexts.

> **Note on outputs:** These libraries *produce canonical signatures* indistinguishable from other standard Ed25519 libraries. The broader acceptance under ZIP‑215 is only about what you **accept** on input, not how you **produce** signatures.

---

## 4) Where FROST fits (and why ZIP‑215 helps)

FROST is a two‑round threshold Schnorr signature scheme. In a FROST pipeline, many signatures may be aggregated, and implementations frequently use batch verification for performance. Without precise rules, you could have the classic failure: a signature that passes individual verify but fails in a batch, or vice‑versa, creating brittle or exploitable workflows.

**ZIP‑215 removes this class of problems** by mandating a single verification equation for both modes. Pairing FROST with a ZIP‑215 Ed25519 library keeps your threshold signing flows predictable, testable, and interop‑friendly.

**Zcash’s FROST libraries** ship:

* Trusted‑Dealer key generation (split a secret into `n` shares with threshold `t`).
* Distributed Key Generation (interactive DKG where no single dealer knows the final secret).
* FROST signing across several ciphersuites, including Ed25519.

For protocol developers, this means you can choose the trust model (dealer vs. DKG), wire it up to your transport, and rely on consistent Ed25519 verification semantics.

---

## 5) SSH/OpenSSH compatibility (incl. Open Integrity)

Many developer workflows use **SSH keys** for signing (e.g., `ssh-keygen -Y sign/verify`, Git’s SSH‑sig support). Those tools implement classic Ed25519 rules but, for *honest signatures*, behave identically to ZIP‑215 signers. That is:

* **Signatures you produce** with `ed25519‑zebra`/`ed25519‑consensus` are canonical and verify fine with OpenSSH and similar tools.
* **Signatures you accept** under ZIP‑215 may be a *superset* of what OpenSSH will accept. If you need OpenSSH agreement on the same artifacts, enforce canonical encodings at your API boundary (a simple switch; see §7.4).

This gives you the best of both worlds: safe, consensus‑grade semantics internally; routine compatibility with SSH‑based ecosystems externally. For projects like **Open Integrity**, you can keep using SSH keys and `ssh-keygen -Y` for signatures while adopting FROST for distributed signing behind the scenes.

---

## 6) Reference architecture

**Actors & artifacts**

* *Participants* hold key shares (from Trusted‑Dealer or DKG).
* *Coordinator* (stateless or minimal state) runs the FROST rounds.
* *Signing target* is a message or a deterministic preimage (e.g., the `SSHSIG` blob for file signing).

**Data flow**

1. **Key setup**

* Trusted‑Dealer: generate `(sk, vk)`, split `sk` into shares; distribute securely to participants.
* DKG: participants run the DKG protocol to derive shares and the common group public key `vk` with no single dealer.
2. **Preimage**

* Decide the external format *before* signing. Examples:

* SSH signatures (`SSHSIG`): construct the canonical SSH‑sig preimage (namespace, hash algorithm, file digest…).
* Git/Open Integrity metadata: canonicalize the content to be signed (e.g., commit envelope, provenance record).
3. **FROST signing**

* Round 1: each signer generates a nonce commitment and sends it to the coordinator.
* Round 2: each signer computes a partial signature; the coordinator aggregates into a single Ed25519 signature `sig`.
4. **Verify and export**

* Verify `sig` locally using a ZIP‑215 library.
* Export `sig` in the target ecosystem format:

* For SSH: wrap `sig` into the `SSHSIG` structure; publish alongside artifacts.
* For Git/Open Integrity: attach to the appropriate envelope.

**Operational tips**

* Keep the FROST RPC clean and replay‑safe; include contexts (domain‑separation tags, namespaces, commit IDs) in the preimage.
* Use **ZIP‑215 verifier** everywhere in your distributed system boundary (services, CLIs, CI) to avoid accidental downgrades.

---

## 7) Implementation checklist

### 7.1 Rust crates

* `ed25519‑zebra` (ZIP‑215 Ed25519) or `ed25519‑consensus` (ZIP‑215 only).
* `frost‑core` (traits) + `frost‑ed25519` (ciphersuite).
* `rand_core`, `zeroize`, and your transport/serialization stack (`serde`, `bincode`/`cbor`/`prost`).

### 7.2 FROST key setup options

* **Trusted‑Dealer:** simplest bootstrap; ensure out‑of‑band secure delivery and audit logs.
* **DKG:** no single point of trust; requires reliable interactive rounds and resilient P2P or client‑coordinator messaging.

### 7.3 Batch verification

* Use the library’s batch verification for high‑throughput pipelines. Under ZIP‑215, batch and single verify are guaranteed to agree, so fallback logic is straightforward.

### 7.4 Interop “safe‑mode”

If a signature must verify under strict RFC 8032 tooling (e.g., OpenSSH, some HSMs), enforce:

* Canonical encoding of public keys and `R`.
* Canonical `s < L` (already standard).
* Avoid small‑subgroup public keys (e.g., enforce nonzero torsion checks when generating/accepting keys).

You can expose a `--strict-rfc8032` CLI flag or a library feature that performs these checks *in addition* to ZIP‑215 verification.

### 7.5 SSH‑sig integration

* Build an adapter that constructs the `SSHSIG` preimage (namespace + hash + reserved) and then signs with your ZIP‑215 Ed25519.
* Serialize the result per the SSH signature spec and armor it (`-----BEGIN SSH SIGNATURE----- …`).
* Round‑trip test with `ssh-keygen -Y sign/verify`.

### 7.6 Test vectors & CI

* Include the ZIP‑215 edge‑case vectors in CI (non‑canonical encodings, alternate `R` encodings, low‑order points).
* Add cross‑impl harnesses: verify that your output verifies under OpenSSH and a mainstream RFC8032 verifier (libsodium/`crypto_sign_ed25519_open` or Go’s `crypto/ed25519`).
* Property tests for batch vs single agreement.

---

## 8) Threat model notes

* **ZIP‑215 doesn’t weaken honest signatures.** It just removes ambiguity and lets you batch safely. Attackers can still try to exploit edge cases, but your verifier now has precisely defined behavior.
* **Key management remains the hard part.** Use hardware enclaves or OS keystores for long‑lived shares; rotate and refresh shares (`Share Refresh`) as operational policy.
* **Coordinator DoS:** FROST rounds are interactive; time out and recover cleanly. Consider rate‑limiting and authenticated channels between signers and coordinator.

---

## 9) What to build next

* **A minimal `frost-ssh` CLI**

* `keygen` (dealer or DKG bootstrap), `sign` (producing SSH‑sig), `verify`.
* `--zip215` (default) and `--strict-rfc8032` modes.
* JSON output for CI and scripts.
* **An Open Integrity adapter**

* Plug FROST signing into your inception‑commit flow: derive the `SSHSIG` preimage from the repo state and provenance envelope, sign via FROST, and check with `ssh-keygen -Y verify`.

---

## 10) TL;DR recommendations

1. Use ZIP‑215 Ed25519 everywhere in your protocol and tooling. It removes edge‑case ambiguity and makes batch verification safe.
2. Build FROST functionality on top of Zcash’s `frost‑ed25519` with either Trusted‑Dealer or DKG, depending on your trust model.
3. For external compatibility (OpenSSH, Git), export canonical signatures and the `SSHSIG` envelope—your outputs will verify with legacy tools. If you must accept signatures that *legacy* tools will also verify, add a strict‑mode check at your boundary.

If you follow these patterns, you’ll get robust, consensus‑grade Ed25519 semantics internally and seamless compatibility with existing SSH‑based ecosystems externally.

Links:

- [It's 255:19AM. Do you know what your validation criteria are?](https://hdevalence.ca/blog/2020-10-04-its-25519am/)
- [ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules](https://zips.z.cash/zip-0215)
- [hdevalence/ed25519consensus: Go Ed25519 suitable for use in consensus-critical contexts.](https://github.com/hdevalence/ed25519consensus)
- [ZcashFoundation/ed25519-zebra: Zcash-flavored Ed25519 for use in Zebra.](https://github.com/ZcashFoundation/ed25519-zebra)
- [ed25519_consensus::batch - Rust](https://docs.rs/ed25519-consensus/latest/ed25519_consensus/batch/)
- [@noble/ed25519 - npm](https://www.npmjs.com/package/%40noble/ed25519?utm_source=chatgpt.com)
- [ZcashFoundation/frost: Rust implementation of FROST (Flexible Round-Optimised Schnorr Threshold signatures) by the Zcash Foundation](https://github.com/ZcashFoundation/frost)
- [OpenIntegrityProject/core](https://github.com/OpenIntegrityProject/core)