ECDSA (P-256) Encrypt & Decrypt

Free online ECDSA (P-256) Encrypt & Decrypt tool. 100% local processing — your data never leaves your device.

Select Algorithm

National Standards

Other

Public Key (PEM)

Private Key (PEM)

Input

Output

Result will be displayed here...

Input → Encrypt

Usage Guide

About ECDSA (P-256)

ECDSA (Elliptic Curve Digital Signature Algorithm) using the NIST P-256 curve (also known as secp256r1 or prime256v1) is a widely deployed digital signature standard (standardized in FIPS 186-5). It underpins HTTPS/TLS certificates, code-signing infrastructure, and many blockchain protocols. P-256 provides 128-bit security — equivalent to RSA-3072 — while keeping keys compact (32 bytes each). WebCrypto, Java, Go, Python, and virtually every TLS library support P-256 natively.

Signing Algorithm — Not Encryption: ECDSA is a digital signature algorithm. It proves that a message was signed by the holder of a specific private key — it does not encrypt data. To keep data confidential, combine ECDSA signatures with a symmetric cipher like ChaCha20-Poly1305 or AES-256-GCM.

Usage Steps

This tool supports P-256 key pair generation, message signing, and signature verification:

•

1. Generate Key PairClick 'Generate Key Pair' to create a linked private/public key pair. Both keys are output in PEM format (-----BEGIN PRIVATE KEY----- / -----BEGIN PUBLIC KEY-----).

•

2. Sign a MessageSelect 'Sign' mode. Enter the message text in the input field and paste the PEM private key in the key parameter. Click 'Encrypt' — the output is a Base64-encoded 64-byte signature in IEEE P1363 format (r‖s, not DER).

•

3. Verify a SignatureSelect 'Verify' mode. Enter the input as 'message|signature_base64' (pipe-separated). Paste the PEM public key in the key parameter. Click 'Decrypt' — the output will be '✓ Signature verified' or an error.

•

4. Secure Key StorageSave the PEM private key in a secure location (password manager, encrypted vault). The public key can be freely shared. Losing the private key means losing the ability to sign — there is no recovery.

Browser-Only: All key generation and signing operations run entirely in your browser using the WebCrypto API. No keys or messages are ever transmitted to a server.

Key Format

ECDSA P-256 keys in this tool use PEM encoding (Base64-wrapped DER):

•

Private KeyPEM block beginning with -----BEGIN PRIVATE KEY----- (PKCS#8 format). Contains the 32-byte scalar secret. Keep this strictly confidential.

•

Public KeyPEM block beginning with -----BEGIN PUBLIC KEY----- (SubjectPublicKeyInfo / X.509 format). Contains the 65-byte uncompressed curve point (04 || x || y). Safe to share publicly.

•

SignatureBase64-encoded 64-byte value: r (32 bytes) concatenated with s (32 bytes) — IEEE P1363 format. Note: OpenSSL and many libraries use DER-encoded signatures instead; they are not directly interchangeable.

•

Verify Input FormatWhen verifying, the input field must contain the message and Base64 signature joined by a pipe character: message|signature_base64

ECDSA vs EdDSA

ECDSA and EdDSA are both elliptic-curve signature algorithms but differ in critical security properties:

•

Nonce SafetyECDSA requires a cryptographically random nonce (k) per signature. If the nonce is reused across two signatures, an attacker can algebraically recover the private key. This is exactly how the Sony PS3 signing key was compromised in 2010. EdDSA derives its nonce deterministically from the private key and message — nonce reuse is mathematically impossible.

•

Deterministic SigningEdDSA (Ed25519) produces the same signature for the same message+key every time. ECDSA produces a different signature each time (due to the random nonce). Deterministic signing simplifies testing and makes reproducible builds verifiable.

•

Curve DesignP-256 (secp256r1) is a NIST-standardized curve with broad compatibility. Ed25519 uses Twisted Edwards Curve25519 designed to resist side-channel attacks and with cleaner arithmetic. Both provide ~128-bit security.

•

RecommendationFor new projects, prefer EdDSA (Ed25519) due to deterministic signing and stronger resistance to implementation errors. Use ECDSA P-256 when compatibility with existing TLS infrastructure or hardware security modules that do not yet support Ed25519 is required.

Quantum Resistance: Like RSA and EdDSA, ECDSA is vulnerable to a sufficiently powerful quantum computer running Shor's algorithm. For post-quantum security, look into NIST-standardized algorithms like ML-DSA (CRYSTALS-Dilithium). ECDSA P-256 remains the best practical choice for classical (non-quantum) threat models today.

FAQ

Q: What is the difference between ECDSA and EdDSA?

A: Both ECDSA and EdDSA are elliptic-curve signature algorithms, but they differ in critical ways. ECDSA (used with NIST curves P-256, P-384) requires a random nonce (k) per signature — if the nonce is reused or weak, the private key can be completely recovered. This is exactly how the Sony PlayStation 3 private key was extracted in 2010. EdDSA uses a deterministic nonce derived from the private key and message hash, making nonce reuse mathematically impossible. For new implementations, EdDSA is strongly preferred over ECDSA.

Q: Why is nonce reuse in ECDSA so dangerous?

A: In ECDSA, each signature requires a secret random value k (the nonce). If you sign two different messages with the same nonce k, an attacker who observes both signatures can use simple algebra to recover your private key — completely and irreversibly. This is not theoretical: the PlayStation 3 was jailbroken in 2010 when Sony reused the same nonce for all firmware signatures. The fix is either to use a cryptographically secure random number generator for every signature (as WebCrypto does), or to switch to EdDSA, which eliminates the nonce problem entirely through deterministic derivation.

Q: Can ECDSA encrypt data?

A: No. ECDSA is a digital signature algorithm only — it cannot encrypt or decrypt data. Signing proves authenticity (who created the message) but provides no confidentiality (anyone can read the message). To encrypt data, use a symmetric cipher like ChaCha20-Poly1305 or AES-256-GCM. For asymmetric key exchange, use X25519 (ECDH). For asymmetric encryption with P-256, use ECC/ECIES.

Q: What is the difference between P-256 and secp256k1?

A: Despite the similar names, P-256 (secp256r1, prime256v1) and secp256k1 are different elliptic curves with different parameters. P-256 is a NIST-standardized curve widely used in TLS certificates, government systems, and WebCrypto. secp256k1 is the curve used by Bitcoin and Ethereum (for ECDSA signatures on regular transactions). secp256k1 has different efficiency characteristics and is generally not supported by TLS libraries or WebCrypto. Do not confuse them — keys and signatures are completely incompatible between the two curves.

Q: How large is an ECDSA P-256 signature?

A: An ECDSA P-256 signature in IEEE P1363 format (used by this tool and WebCrypto) is exactly 64 bytes: two 32-byte big-endian integers r and s. Base64-encoded, this is 88 characters. In DER format (used by OpenSSL, X.509, TLS), the same signature is variable-length, typically 70–72 bytes, because DER uses a tag-length-value encoding with leading zero bytes for positive integers. When interoperating with OpenSSL or other tools, be aware of the format difference.

Use Cases

Recommended: TLS Certificates / HTTPS

ECDSA P-256 certificates are the modern standard for HTTPS. They are supported by all major browsers and TLS 1.3, and are significantly smaller and faster than RSA-2048 certificates. Certificate Authorities like Let's Encrypt fully support ECDSA P-256. Use openssl ecparam -name prime256v1 -genkey to generate a P-256 key for a CSR.