b2KIT

ECDSA Key Pair Generator

Generate Elliptic Curve key pairs (P-256, P-384, P-521) for digital signatures and key exchange.

Tested tool guide Tested browser tools Checked August 16, 2026

What ECDSA Key Pair Generator does and how it behaves

Pick P-256, P-384, or P-521 to create a new elliptic-curve private key and its mathematically corresponding public key. Generation occurs in the browser, so the key material is not uploaded by the tool. Curve selection fixes the domain parameters; it does not make the result repeatable, and generating again should produce a different pair. A frequent source of confusion is the name P-521: it identifies a 521-bit prime-field curve, not a misspelling of P-512.

How the result is produced

1

Named curve selection

Each offered choice is a named NIST prime-field curve. The selected name determines the finite field, curve equation, base point, and group order used to relate the two keys. P-256, P-384, and P-521 are not interchangeable labels. The curve affects key and signature component sizes, but key generation does not choose the message digest later used by ECDSA.

2

Private and public halves

The private half is a secret scalar in the valid range for the selected curve. Its public half is the curve point obtained by multiplying the curve's base point by that scalar. A verifier can receive the public half without learning the private value. Pair generation does not sign data, calculate a shared secret, issue a certificate, or attach an identity.

Good uses

  • Creating a P-256 or P-384 signing key for a development service whose verifier explicitly supports that named curve and the generated key encoding.
  • Producing a public key for a signature-verification test harness while retaining the matching private key for signing test messages.
  • Generating a same-curve pair for an ECDH interoperability experiment after confirming that the receiving software accepts the encoding and permits agreement use.

Limits and checks

  • Selecting only a curve cannot yield a predictable worked output. New key generation is nondeterministic, so retain the exact private key if the same identity must be used again.
  • A bare EC point, SubjectPublicKeyInfo, PKCS #8 private key, and RFC 5915 ECPrivateKey are different encodings or containers. Confirm what the destination expects before importing the result.
  • ECDSA and ECDH use related curve mathematics but are different operations. A system may restrict a key to signing or agreement, and a generated pair is not automatically a certificate or trusted identity.

Common questions

Can I use the same generated pair for ECDSA and ECDH?

The underlying private scalar and public point can be suitable for either operation on these supported curves, but protocol rules, key-usage restrictions, and import formats may forbid reuse. Generating the pair does not perform an ECDH exchange or establish a shared secret. Confirm that the destination accepts the named curve and encoding for key agreement; otherwise, no.

Which of the three curves should I choose?

Use the exact named curve required by the protocol or receiving application. A P-256 key cannot become P-384 or P-521 by changing its label, and support for one EC curve does not imply support for the others. If no requirement is documented, this generator cannot determine compatibility; inspect the destination's accepted curve and key format first.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools