ECDSA Toolkit

Generate ECDSA keys, sign messages, and verify signatures.

What ECDSA Toolkit helps you do

Generate ECDSA key pairs, sign messages and verify signatures with the browser's Web Crypto API. It uses the P-256 curve and SHA-256, exports keys as Base64 SPKI and PKCS#8, and returns the signature in Base64. Elliptic-curve signatures are smaller than RSA for a comparable security level.

ECDSA operations happen in your browser; keys and messages are not uploaded to Haivix.

How it works

Every operation runs in your browser, and the keys and plaintext stay on the device. The underlying libraries are fetched from a public CDN when the page loads, so the code itself comes from a third party at runtime; that is acceptable for learning and interoperability, not for high-assurance key handling. These are low-level primitives, not a complete protection scheme: CBC, ECB and RC4 provide confidentiality only, with no integrity check, so altered ciphertext may decrypt to something an application still accepts. Modern designs pair encryption with authentication, such as AES-GCM or ChaCha20-Poly1305, and keep keys in a dedicated store rather than a form field.

How to use ECDSA Toolkit

  1. Generate an ECDSA key pair or paste an existing one.
  2. Sign a message or verify a signature.
  3. Use the same curve and hash on both sides.
  4. Copy the signature or the verification result.

When to use it

  • Test ECDSA signing and verification in an application.
  • Produce a compact signature for a demonstration.
  • Compare ECDSA output with an RSA signature.
  • Check that a Base64 key pair belongs together.
  • Generate a test key for a Web Crypto workflow.
  • Verify a signature produced with P-256 and SHA-256.

When not to use it

  • Do not use it for encryption; ECDSA signs and verifies only.
  • Do not expect a curve choice; the tool is fixed to P-256.
  • Do not use a browser-generated key as a production identity.

Example

A message signed with the ECDSA private key verifies against the corresponding public key and fails against a different one. The signature is Base64 over the raw 64-byte r and s values, not an ASN.1 DER sequence, so another library may need a format conversion. Changing a single character in the message makes verification fail.

What you can do with ECDSA Toolkit

  • Generate a P-256 ECDSA key pair.
  • Export the public key as Base64 SPKI.
  • Export the private key as Base64 PKCS#8.
  • Sign a message with SHA-256.
  • Verify a Base64 signature.
  • Run the operations locally in the browser.

Example: know what you have before choosing an operation

Identify the input format. A raw key in hex, a passphrase and a PEM key are different things, and using one where another is expected produces garbage rather than an error.

Test with a known vector or a short round trip. Encrypt, decrypt and compare before using the tool on data you cannot afford to lose.

Never paste a production private key or long-lived secret into a web page. Use a throwaway key for experiments and a proper key store for real work.

Check the mode and padding against the system you are interoperating with. The same algorithm with a different mode is a different ciphertext format.

Prefer an authenticated mode for anything new. If the tool only offers CBC or ECB, treat the output as a demonstration rather than a protection mechanism.

Record the output encoding as well as the algorithm. Base64, hex and raw bytes are easy to confuse, and a format mismatch looks like a wrong key.

What to know before you start

  • Correctness depends on using the same curve and hash for signing and verification.
  • Keys generated in the browser are for testing and not a substitute for secure key storage.
  • Only P-256 with SHA-256 is supported.
  • Signatures are raw WebCrypto format, not DER, and there is no certificate handling.

Common mistakes

  • Expecting the signature format to match an OpenSSL DER signature.
  • Using a different curve or hash on the verifying side.
  • Trying to encrypt with an ECDSA key.
  • Treating a browser key pair as a durable identity.

Troubleshooting

If signing fails, the private key may not be Base64 PKCS#8.

If verification fails, check the message, the public key and the signature encoding.

If the key is rejected, confirm it was generated for P-256.

If another tool rejects the signature, convert the raw r||s format to DER.

Related standards and documentation

  • FIPS 197 defines AES, and NIST SP 800-38A defines its common modes of operation.
  • NIST SP 800-38D defines GCM, an authenticated mode suited to new designs.
  • FIPS 186-5 covers digital signatures, including RSA and ECDSA.
  • RFC 8017 defines RSAES and RSASSA, including PKCS#1 v1.5 and OAEP.
  • NIST SP 800-57 describes key management and key lifetime practices.
Primitives, not a scheme
  • Check key and input formats.
  • Round-trip before trusting.
  • No integrity in CBC or ECB.
  • Use AEAD for new work.