ECC (P-256) Encrypt & Decrypt

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

National Standards
Other
Output

Result will be displayed here...

Input → Encrypt

Usage Guide

About ECC/ECIES (P-256)

ECC/ECIES (Elliptic Curve Integrated Encryption Scheme) using the NIST P-256 curve is a hybrid asymmetric encryption scheme. It combines Elliptic Curve Diffie-Hellman (ECDH) for key agreement with AES-256-GCM for authenticated symmetric encryption. ECIES provides confidentiality, integrity, and authenticity in a single operation. Keys are compact — a P-256 private key is only 32 bytes compared to 256 bytes for RSA-2048 — while offering equivalent security.

Encryption Algorithm — Not Signing: ECC/ECIES is an encryption algorithm that keeps data confidential. It is completely different from ECDSA, which is a signature algorithm that proves authenticity but does not encrypt. Use ECIES when you need to send a secret message to a recipient using their public key.

Usage Steps

This tool supports ECIES key pair generation, encryption (with public key), and decryption (with private key):

•
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. Encrypt a MessageSelect 'Encrypt' mode. Enter the plaintext message in the input field and paste the PEM public key in the key parameter. Click 'Encrypt' — the output is a JSON object containing the ephemeral public key (epk) and the ciphertext (ct).
•
3. Decrypt a MessageSelect 'Decrypt' mode. Paste the JSON ciphertext in the input field and paste the PEM private key in the key parameter. Click 'Decrypt' — the output is the original plaintext.
•
4. Secure Key StorageStore the private key in a secure location (password manager, encrypted vault, HSM). The public key can be shared freely. Losing the private key means losing the ability to decrypt all messages encrypted to it.
Browser-Only: All key generation and encryption operations run entirely in your browser using the WebCrypto API. No keys or messages are ever transmitted to a server.

Output Format

ECIES encryption produces a JSON object with two fields:

•
epk (Ephemeral Public Key)66 hexadecimal characters = 33 bytes. This is the compressed P-256 point of the sender's ephemeral key pair. The recipient uses this together with their private key to reconstruct the shared secret via ECDH.
•
ct (Ciphertext)Hexadecimal string. Contains the AES-256-GCM encrypted plaintext followed by a 16-byte (32 hex chars) GCM authentication tag. The authentication tag ensures the ciphertext has not been tampered with.
•
Example Output{"epk":"02a3f1e2d4c5b6...","ct":"7f8e9d0c1b2a...f3e4d5c6b7a8"}
•
Nonce (IV)The 12-byte AES-GCM nonce is derived deterministically from the HKDF key derivation step — it is embedded in the key derivation and does not need to be stored separately in the JSON.

How ECIES Works

ECIES is a hybrid encryption scheme that internally performs these steps:

•
Step 1 — Ephemeral Key PairThe sender generates a fresh (ephemeral) P-256 key pair for every encryption operation. This key pair is used only once and then discarded.
•
Step 2 — ECDH Key AgreementThe sender computes a shared secret using ECDH: shared_secret = ECDH(sender_ephemeral_private, recipient_public). This shared secret is the same value the recipient will compute using ECDH(recipient_private, sender_ephemeral_public).
•
Step 3 — HKDF Key DerivationThe shared secret is passed through HKDF-SHA256 to derive 44 bytes: the first 32 bytes become the AES-256-GCM encryption key, and the next 12 bytes become the GCM nonce (IV).
•
Step 4 — AES-256-GCM EncryptionThe plaintext is encrypted using AES-256-GCM with the derived key and nonce. The output is the ciphertext concatenated with a 16-byte authentication tag.
•
Step 5 — OutputThe ephemeral public key (compressed, 33 bytes) and the ciphertext are encoded as hex strings and returned as a JSON object.
Forward Secrecy: Because each encryption uses a fresh ephemeral key pair, even if the recipient's long-term private key is compromised in the future, past ciphertexts cannot be decrypted. This property is called forward secrecy (or perfect forward secrecy). RSA-OAEP does not provide forward secrecy.

FAQ

Q: What is the difference between ECIES and RSA encryption?

A: Both ECIES and RSA-OAEP are asymmetric encryption schemes, but they differ in several important ways. Key size: A P-256 private key is 32 bytes; RSA-2048 needs 256 bytes for equivalent security. Speed: ECIES operations are significantly faster than RSA on the same hardware. Forward secrecy: ECIES provides forward secrecy via ephemeral key pairs — RSA-OAEP does not. Output size: ECIES adds a 33-byte ephemeral public key to each ciphertext; RSA ciphertext is exactly the key size. For new systems, ECIES is generally preferred over RSA for asymmetric encryption.

Q: What is forward secrecy and why does it matter?

A: Forward secrecy (also called perfect forward secrecy, PFS) means that past encrypted messages remain secure even if the long-term private key is later compromised. In ECIES, each encryption generates a brand-new ephemeral key pair that is discarded after use. The shared secret is derived from the ephemeral private key, which no longer exists after encryption. Even if an attacker stores the ciphertext now and obtains the recipient's private key years later, they still cannot decrypt old messages because the ephemeral private key is gone. RSA-OAEP uses the recipient's long-term public key directly — if that private key is ever compromised, all past ciphertexts can be decrypted.

Q: What do the fields in the JSON output mean?

A: The ECIES output JSON has two fields: epk (ephemeral public key) is 66 hex characters representing the compressed 33-byte P-256 point of the sender's one-time key pair. The recipient needs this to reconstruct the ECDH shared secret. ct (ciphertext) is a hex string containing the AES-256-GCM encrypted data followed by a 16-byte (32 hex char) GCM authentication tag. The tag ensures that any tampering with the ciphertext will be detected during decryption. You must preserve the entire JSON — if either field is modified or truncated, decryption will fail with an authentication error.

Q: Can I encrypt multiple messages to the same public key?

A: Yes. You can encrypt as many messages as you want to the same recipient public key. Each encryption automatically generates a new ephemeral key pair, so each ciphertext is independent and uses a different derived key and nonce. There is no nonce reuse risk. The recipient decrypts each message with the same private key, but each decryption derives a different shared secret from the different ephemeral public keys in each ciphertext.

Q: Is ECC/ECIES resistant to quantum computers?

A: No. ECIES is based on the Elliptic Curve Discrete Logarithm Problem (ECDLP), which a sufficiently large quantum computer running Shor's algorithm could solve. The same applies to RSA. However, breaking P-256 would require thousands of logical qubits with very low error rates — well beyond current quantum hardware. For post-quantum asymmetric encryption, NIST has standardized ML-KEM (formerly CRYSTALS-Kyber). ECIES remains the best practical choice for classical (non-quantum) threat models today.

Use Cases

Recommended: End-to-End Encrypted Messaging

ECIES is well-suited for end-to-end encrypted messaging where the sender knows the recipient's public key. Each message is encrypted with the recipient's public key and can only be decrypted by the recipient's private key. The built-in forward secrecy means that even if the recipient's private key is compromised later, previously sent messages remain protected. This is the same principle used by Signal and similar secure messaging protocols.

Recommended Configuration:
  • ✅ Distribute your PEM public key to senders
  • ✅ Keep your PEM private key in an encrypted vault or HSM
  • ✅ Forward secrecy is built-in — each message uses a fresh ephemeral key
  • ❌ Don't share your private key with anyone, including the sender
Recommended: Hybrid Encryption for Large Data

ECIES is typically used in a hybrid encryption pattern for large files: use ECIES to securely transmit an AES-256-GCM or ChaCha20-Poly1305 symmetric key, then use that key to encrypt the actual large file. ECIES is efficient for small payloads (keys, tokens, short messages), while symmetric ciphers handle bulk data efficiently. This is how TLS, PGP, and most real-world encryption protocols work. For the standardized hybrid encryption pattern using X25519 for key exchange, see HPKE (RFC 9180).

Recommended Configuration:
  • ✅ Use ECIES to wrap/transmit the symmetric data encryption key (DEK)
  • ✅ Use AES-256-GCM or ChaCha20-Poly1305 for the actual file content
  • ✅ Store the ECIES-wrapped key alongside the encrypted file
  • ❌ Don't use ECIES to directly encrypt files larger than a few KB
Recommended: Replacing RSA-OAEP

For new systems that currently use RSA-OAEP for asymmetric encryption, ECIES with P-256 is the recommended modern replacement. It provides equivalent or better security with much smaller keys (32 bytes vs 256 bytes for RSA-2048), faster operations, and the additional benefit of forward secrecy. The migration path is straightforward: generate new ECC key pairs in PEM format and update encryption/decryption code to use ECIES.

Recommended Configuration:
  • ✅ Prefer ECIES over RSA-OAEP for new asymmetric encryption needs
  • ✅ P-256 (ECIES) keys are 8× smaller than RSA-2048 keys
  • ✅ ECIES adds forward secrecy that RSA-OAEP cannot provide
  • ❌ Don't keep RSA-OAEP in new systems unless legacy compatibility is required
Recommended: Secure API Payload Transmission

ECIES can protect sensitive data in API requests — for example, encrypting a user's credit card number or personal data with the server's public key before transmission. Even if TLS is compromised or the request is intercepted at a load balancer or proxy, the payload remains encrypted until it reaches the server holding the private key. This is sometimes called payload-level encryption and provides defense in depth beyond transport security.

Recommended Configuration:
  • ✅ Publish the server's PEM public key to API clients
  • ✅ Encrypt sensitive fields (PII, payment info) before sending
  • ✅ Combine with TLS for defense in depth
  • 💡 Each request uses a fresh ephemeral key automatically — no key rotation needed per request
Not Recommended: Direct Large File Encryption

ECIES is designed for short messages and key wrapping — not for directly encrypting large files. While it technically works, using ECIES on large files is inefficient compared to symmetric ciphers. The correct pattern is hybrid encryption: use ECIES to encrypt a randomly generated AES-256-GCM key (32 bytes), then use that AES key to encrypt the actual file. This is how OpenPGP, CMS, and modern secure file transfer protocols operate.

Recommended Configuration:
  • ❌ Don't use ECIES to directly encrypt files larger than a few KB
  • ✅ Use ECIES to encrypt a random AES-256-GCM data encryption key (DEK)
  • ✅ Use the DEK with AES-256-GCM to encrypt the file content
  • 💡 Store: ECIES-encrypted DEK + AES-encrypted file content together

Best Practice Summary

  • ECC/ECIES is an encryption algorithm — it provides confidentiality. It is not a signing algorithm. Use ECDSA for digital signatures.
  • Forward secrecy is built in: each encryption generates a fresh ephemeral key pair, so past ciphertexts remain safe even if the private key is later compromised.
  • For large data, use hybrid encryption: ECIES to wrap the key, AES-256-GCM or ChaCha20-Poly1305 for the data itself.
  • The private key (PEM format) must be kept secret. The public key (PEM format) can be freely distributed to anyone who needs to send you encrypted messages.

Discussion & Feedback

0 comments
Me