CipherLayer
Home / Tools / ECDSA

ECDSA Signer

Sign and verify ECDSA signatures on NIST P-256, P-384, and P-521. Web Crypto produces DER-encoded signatures with RFC 6979 deterministic nonces — both are exposed below the fold.

P-256 / P-384 / P-521 SHA-256 / 384 / 512 RFC 6979 DER output JWK export
RFC 6979 — deterministic nonces. Web Crypto's ECDSA implementation uses deterministic k values derived from the message and private key (RFC 6979). That means signing the same message with the same key always produces the same signature. This eliminates the Sony PS3 attack (reused k → private key leaked). Random k would also work but adds no security.

Inputs

Output

// Output will appear here ECDSA signature = (r, s) where both are integers modulo the curve order n. DER encoding wraps them as an ASN.1 SEQUENCE of two INTEGERs.
Last operation
—
Time
—
Sig size
—

Why this tool, and why this version

ECDSA — the elliptic-curve variant of DSA — gives the same guarantees as RSA signatures with smaller keys and faster operations. A 256-bit ECDSA signature has roughly the security of a 3072-bit RSA signature. A 256-bit EC key verifies a signature in microseconds. This is why TLS 1.3, SSH, and most modern protocols use ECDSA (or its sibling Ed25519) instead of RSA.

What a signature actually is. An ECDSA signature is a pair of integers (r, s), each about as large as the curve order. To verify: given message m, public key Q, compute u1 = H(m)/s mod n, u2 = r/s mod n, then check that (u1 * G + u2 * Q).x == r mod n. The math guarantees that only someone with the private key d (where Q = d * G) could produce a valid (r, s) pair.

What we expose. The signature is shown as both DER (the ASN.1 wire format most protocols use) and raw r||s (useful for blockchain and custom protocols). We also display the public key as both JWK (for browsers and JWT) and uncompressed hex (for raw SEC1). The same signature verification works on either format.

Why deterministic nonces matter. ECDSA security requires a per-signature random k. If two signatures share the same k, the private key is recoverable. The 2010 Sony PS3 code-signing key was leaked exactly this way. RFC 6979 derives k deterministically from the message and private key, eliminating the failure mode without weakening security. Web Crypto always uses RFC 6979, so this tool is safe by default.

Who this is for

Engineers building JWT or token systems

ES256/ES384/ES512 use exactly these curves. Generate a key here, export the JWK, paste into your library. Verify on the receiving side.

Cryptography students learning EC signatures

The math is dense. Watching a signature generate and verify, with the r and s values visible, makes the structure concrete.

Forensics / incident response

You've been handed a signature, a message, and a public key. You need to verify. This tool does that — without trusting any third-party library or sending data anywhere.

Frequently asked questions

Why ECDSA over RSA? ▶
ECDSA produces equivalent security at much smaller key sizes. P-256 (256-bit) ≈ RSA-3072. The signatures are also smaller (64 bytes raw vs 256 bytes for RSA-2048) and faster to compute. ECDSA verification is microseconds; RSA-2048 verification is milliseconds. The trade-off: ECDSA signatures are not deterministic across implementations (they depend on the random k), so reproducing a signature is harder. RFC 6979 fixes this by making k deterministic.
What is RFC 6979? ▶
RFC 6979 standardizes deterministic nonce generation for ECDSA. Instead of picking k randomly for each signature (which can fail if the RNG is bad), k is derived from the private key and the message using HMAC-SHA256. The result is provably as secure as random nonces (within the standard model), and eliminates the catastrophic "reused k" failure. Web Crypto's ECDSA implementation always uses RFC 6979.
Why are r and s separate? ▶
ECDSA's signature is two integers, not one. r is the x-coordinate of a random point on the curve (k * G); s is the response to a challenge derived from the message and r. Both must be in [1, n-1] where n is the curve order. The pair (r, s) is what the verifier checks against the public key. Either r or s being out of range, or zero, makes the signature invalid.
What's the difference between DER and raw r||s? ▶
DER — Distinguished Encoding Rules — wraps r and s in an ASN.1 SEQUENCE: 0x30 LEN 0x02 RLEN r_bytes 0x02 SLEN s_bytes. The lengths add ~6-8 bytes of overhead. Raw r||s is just the fixed-size big-endian r followed by the fixed-size big-endian s. DER is what TLS and most libraries use; raw is common in blockchains and custom protocols. Both encode the same mathematical object.
What if I sign the same message twice? ▶
With RFC 6979 nonces, the signature is identical both times — that's the point of determinism. If you used random nonces (older ECDSA implementations), each signature would be different. Identical signatures don't reveal the private key (that's a separate failure mode) but they do leak that the same key signed the same message — which is fine for most applications.
Why does the verify tab ask for a separate public key? ▶
Signatures need to be verified against the signer's public key, not yours. In TLS, the server sends a certificate containing its public key; the client verifies the handshake signature with that key. Here, you can paste any public key (e.g., from a certificate you extracted) and verify that a specific message was signed by its holder. This is the realistic verification workflow.

Limitations you should know