Ed25519

What it is

Ed25519 is a public-key digital signature scheme. A private key signs data; the corresponding public key verifies that the signature came from the holder of the private key and that the data hasn't been altered. It's an EdDSA variant built on the twisted Edwards curve called edwards25519, designed by Daniel Bernstein and collaborators in 2011 and standardized as RFC 8032.

Three numbers tell you almost everything practical about it:

• Private key: 32 bytes. Small enough to print as 64 hex characters.
• Public key: 32 bytes. Same.
• Signature: 64 bytes. Less than a single line of text.

These sizes are roughly an order of magnitude smaller than RSA at comparable security, which is the main reason Ed25519 has spread so quickly through systems where the credential and the signature have to travel everywhere the request goes.

Properties that matter

A handful of design choices set Ed25519 apart from older signature schemes:

• Deterministic. Signing the same message with the same key always produces the same signature. ECDSA derives a per-signature random number that has caused real-world key leaks when the random source was weak (Sony's PS3, several Bitcoin wallets). Ed25519 derives that value from the key and the message, so a bad RNG can't compromise existing keys.
• Constant-time by design. The reference implementation has no data-dependent branches, so it doesn't leak the key through timing side channels the way naive ECDSA implementations have.
• Fast. A modern CPU signs and verifies thousands of times per second per core, faster than RSA-2048 and competitive with the fastest ECDSA curves.
• No parameter choice. The curve is fixed. There's no equivalent to picking P-256 vs P-384 vs P-521, and no debate over whether the parameters might have been chosen for a hidden weakness.

Where you encounter it

You've likely already used Ed25519 without thinking about it:

• SSH. The default key type in modern OpenSSH (ssh-keygen -t ed25519).
• TLS 1.3. One of the supported signature algorithms for both certificates and the handshake.
• Git. Supported for commit signing alongside RSA and ECDSA.
• Tor, Signal, WireGuard. All use Ed25519 for identity.
• JWT. RFC 8037 added EdDSA as a JWT signing algorithm.
• Modern crypto tools. age, sigstore, Minisign, and similar utilities default to it.

How SikkerKey uses it

Every machine identity in your SikkerKey vault is an Ed25519 keypair. To enroll a machine, you create a one-time bootstrap token in the dashboard and run the install command it gives you. On Linux and macOS that's a curl | sh; on Windows it's a PowerShell one-liner. The script generates the keypair locally on that machine using openssl genpkey -algorithm Ed25519, posts only the public key back to SikkerKey, and writes the private key to a file readable only by that user account.

From then on, the CLI or any SDK on that machine signs each request with the private key. SikkerKey verifies the signature against the public key on file; if it doesn't match, the request is rejected before anything is decrypted. There's no shared API token to leak in logs, copy off a laptop, or replay from another network.

The full request format and replay-protection rules are covered under signed requests.