Home / Security & Crypto Tools / ECDSA Sign & Verify
Security & Crypto Tools

ECDSA Sign & Verify

Use P-256/SHA-256, P-384/SHA-384, or P-521/SHA-512 with PEM keys and Base64 signatures.

ReadyCurve determines the default SHA-2 hash.

All cryptographic operations run locally in your browser. Keep private keys secret and use production key-management practices for real systems.

ECDSA signature interoperability inspector

Inspect the Base64 signature from the primary signer/verifier, detect ASN.1 DER versus IEEE-P1363 raw r||s, expose r and s, convert both encodings, and flag high-S relative to the selected curve order.

—Detected format
—S canonicality

Import or paste a signature to begin. Conversion changes encoding only; it does not re-sign a message.

Browser-local cryptographic utilities

preserves the established Web Crypto workflows while connecting token, key, KDF, encryption/signature, fingerprint and verification jobs. Inputs stay in your browser unless the page clearly states that a network request is required.

Protocol boundary

Correct primitive output does not certify a complete protocol, key-management system, parameter choice, endpoint, or production deployment. Match the source system exactly and use established application/security libraries for production authentication and storage.

Use this result with confidence

Curve, hash, and signature encoding are separate choices

ECDSA verification can fail even when the key and message are correct if one side expects a different hash or signature representation. Keep the named curve, hash algorithm, and DER versus IEEE-P1363 format with every test vector. The interoperability panel inspects encoding; it does not change the mathematical signature or re-sign the message.

DER and raw r||s carry the same two integers

ASN.1 DER stores r and s as variable-length signed integers, while P1363 concatenates fixed-width unsigned integers. Converting between them is an encoding operation. Preserve leading-zero rules carefully because a high bit in DER may require a protective 00 byte that must not become part of the fixed-width integer.

High-S is a compatibility signal

For a valid ECDSA signature, s and n-s can represent equivalent mathematical solutions. Some ecosystems require a canonical low-S form to reduce malleability, while others accept both. The inspector can flag high-S relative to the selected curve order, but whether it is acceptable depends on the protocol using the signature.

Use disposable keys for browser interoperability tests

Avoid pasting long-lived production private keys into general-purpose tools. Generate a test pair, sign a known message, inspect or convert the signature, and verify it with an independent implementation. Keep the public key, message bytes, curve, hash, and signature encoding together so a failed cross-platform test can be reproduced exactly.

Search by task, tool name, or category. Press Esc to close.
Start typing to find a tool.