Back to Blog
TechnicalApril 15, 2026

Why We Choose ECDSA P-256 for SSH Certificate Authorities

A technical look at our decision to standardize on ECDSA P-256 for CA keypairs, focusing on Go's crypto implementation, entropy handling, and ubiquitous compatibility.

When building Mezite, we had to make a fundamental decision about the cryptography underpinning our Certificate Authorities (CAs). The CA is the root of trust for the entire SSH infrastructure. It signs short-lived certificates for users and hosts, meaning its security properties directly dictate the security of the access platform.

We choose ECDSA with the NIST P-256 curve (ECDSA P-256) as the exclusive algorithm for our CA keypairs. Here is why we mandate this specific elliptic curve over newer alternatives.

The Compatibility Mandate

In a certificate-based SSH architecture, the User CA and Host CA certificates are fundamental to access. Every time a user logs in, the Auth Service uses the User CA to issue a new short-lived certificate. Every time an agent joins, the Host CA issues a host certificate.

Crucially, every SSH client connecting to a target node must verify the host certificate against its local known_hosts CA public key. If the client does not support the CA’s algorithm, the connection fails.

ECDSA P-256 (ecdsa-sha2-nistp256) provides the widest compatibility matrix in the ecosystem. It is universally supported across OpenSSH clients, hardware security modules, smart cards, and standard TLS libraries. When you deploy Mezite in an enterprise environment, you guarantee that every client and appliance can seamlessly participate in the trust model.

Addressing the Entropy and Nonce Threat

Historically, developers criticize ECDSA for its reliance on high-quality randomness during the signing process. The ECDSA algorithm requires a fresh, cryptographically secure random number (the nonce, or $k$) for every single signature it generates.

If a system uses a biased Random Number Generator (RNG), or worse, reuses the exact same nonce to sign two different messages, the private key can be mathematically recovered. This catastrophic failure mode famously compromised the PlayStation 3 code signing key.

It is common to see arguments that deterministic signature schemes are inherently safer because they eliminate this footgun. However, this argument ignores how modern cryptography libraries actually implement ECDSA.

Mezite is built entirely in Go. The Go standard library crypto/ecdsa implementation specifically mitigates this threat. When the Mezite Auth Service calls ecdsa.Sign() to generate an SSH certificate, Go does not simply pull bytes from /dev/urandom and blindly trust the result.

Instead, Go implements a hybrid approach. It combines entropy from the system’s cryptographically secure pseudo-random number generator (CSPRNG) with the private key and the message hash. This ensures that even if the system’s random number generator completely fails or is compromised, the generated nonce remains unique and unpredictable for every signature, fully protecting the private key.

Performance and Key Size

For a high-throughput proxy brokering hundreds of concurrent SSH sessions, cryptographic performance matters.

ECDSA P-256 provides excellent performance characteristics for both signing and verification. It is significantly faster than RSA, while offering roughly 128 bits of security (comparable to a 3072-bit RSA key).

As stated in our architecture documentation, we store the User CA and Host CA private keys encrypted at rest in the database (SQLite or PostgreSQL). An ECDSA P-256 private key is small—just 32 bytes of raw data. This tiny footprint makes it trivial to encrypt, store, and transmit securely. The small public key size also keeps the resulting SSH certificates compact, preventing fragmentation issues during the SSH handshake.

Conclusion

Cryptography requires a balance between security, performance, and operational reality. By standardizing on ECDSA P-256 for our Certificate Authorities, we provide our users with a universally supported root of trust. We rely on the robust, production-tested implementations within Go’s standard library to handle the complexities of nonce generation securely, ensuring that Mezite remains a highly compatible, secure, and minimal-attack-surface platform.


MT

Mezite Team

Engineering