A TLS 1.3 handshake with an Ed25519 certificate costs about 11 \u00b5s of CPU on a modern server core. RSA-2048 signing costs roughly 90 \u00b5s, plus 35 \u00b5s for the client-side verify. Those numbers sound like an 8x win, and they are – right up until you measure a real server at load and find that neither signature operation appears anywhere near the top of the profile. This article measures all three layers: SSH host keys, TLS 1.3 cipher suites, and where the CPU actually goes at 5,000 handshakes per second.<\/p>\n
The most common conflation in tuning discussions is between the host key algorithm and the key exchange method. On SSH, Key exchange dominates the asymmetric cost of an SSH handshake, not the signature. Curve25519 scalar multiplication is around 50 \u00b5s per side on a small core; a group14 (2048-bit MODP) DH operation is several hundred microseconds to over a millisecond depending on the exponent size. Switching the host key from RSA to Ed25519 saves the signature – tens of microseconds – while switching the kex from DH group14 to Curve25519 saves an order of magnitude more. Tuning only the host key is the usual mistake.<\/p>\n Benchmark with the server actually accepting connections, not with a microbenchmark of On a 2 vCPU instance the typical result is 1.8-2.4 ms of server CPU per full SSH handshake, of which the asymmetric crypto is 100-200 \u00b5s. The remainder is process setup, PAM, and filesystem lookups for In TLS 1.3 the handshake is one round trip and the key exchange is always ephemeral. The suite name encodes only the AEAD and hash; the key exchange group is negotiated separately. The “ECDHE vs RSA” question no longer exists in 1.3, so the real choices are the group (X25519, P-256, X448) and the AEAD.<\/p>\nssh-ed25519<\/code> and rsa-sha2-256<\/code> are host key types – what the server signs the exchange hash with. Separately, curve25519-sha256<\/code> and diffie-hellman-group14-sha256<\/code> are the key exchange algorithms that produce the shared secret. A server can run an RSA host key with Curve25519 key exchange, a combination far cheaper than the host key name suggests. Check what is negotiated, not what is configured.<\/p>\n# What the client and server settle on\nssh -vvv user@host 2>&1 | grep -E 'kex: algorithm|host key algorithm|peer server KEXINIT'\n\n# Server side, once connected\nsshd -T | grep -E 'hostkeyalgorithms|kexalgorithms|pubkeyacceptedalgorithms'\n\n# Generate an Ed25519 host key alongside the RSA one\nssh-keygen -t ed25519 -f \/etc\/ssh\/ssh_host_ed25519_key -N ''\n# sshd prefers the first matching key by default for new clients<\/code><\/pre>\nMeasured: SSH Handshake Cost Per Connection<\/h2>\n
openssl speed<\/code>, because the syscall and process cost of sshd<\/code> dwarfs the crypto. Use hyperfine<\/code> against a throwaway host on the same LAN, or measure server-side CPU with perf stat<\/code> around a fixed number of serial connections.<\/p>\n# 200 serial full handshakes, server CPU only (run on the server)\nperf stat -e task-clock,cycles -p $(pgrep -o sshd) -- \\\n bash -c 'for i in $(seq 200); do ssh -o BatchMode=yes host true; done'\n\n# Client-side wall clock, RSA host key vs Ed25519\nhyperfine --warmup 5 'ssh -o HostKeyAlgorithms=rsa-sha2-256 host true' \\\n 'ssh -o HostKeyAlgorithms=ssh-ed25519 host true'\n\n# Is the server forking per connection? (it should not be the bottleneck)\nsshd -T | grep -E 'maxstartups|maxsessions|usepam'\n<\/code><\/pre>\nauthorized_keys<\/code> and sshd_config<\/code>. Replacing the host key changes the 100 \u00b5s slice; it does not change the 2 ms. If SSH login latency is your problem, UsePAM no<\/code> on a key-only host and a smaller authorized_keys<\/code> file matter more than the curve.<\/p>\nTLS 1.3: Cipher Suite Choice and the Real Cost<\/h2>\n