Cipher Suite Selection and Hardware Acceleration Trade-offs

Symmetric Cipher Selection

Cipher suites define which cryptographic algorithms TLS uses for key exchange, authentication, and bulk encryption. Modern TLS implementations offer two primary symmetric ciphers: AES-GCM and ChaCha20-Poly1305. Both are AEAD ciphers (Authenticated Encryption with Associated Data), meaning they provide both confidentiality (encryption) and integrity (tampering detection) in a single operation, eliminating classes of attacks possible with older separate encrypt then MAC approaches.

AES-GCM (Advanced Encryption Standard in Galois Counter Mode) achieves 2 to 5 Gbps per core on x86 server CPUs with AES-NI (dedicated hardware instructions for AES operations). However, on mobile devices and ARM processors lacking AES-NI, AES-GCM performance degrades significantly, using 3 to 5x more CPU cycles. ChaCha20-Poly1305, designed for efficient software implementation, outperforms AES-GCM by 2 to 3x on devices without hardware acceleration, making it preferred for mobile clients.

Certificate Type Trade offs

Certificates use either RSA or ECDSA (Elliptic Curve Digital Signature Algorithm) for signatures. RSA (Rivest-Shamir-Adleman) has been the standard for decades and works with virtually every client, including old embedded devices and enterprise systems. ECDSA uses elliptic curve mathematics to achieve equivalent security with smaller keys. A 256 bit ECDSA key provides similar security to a 3072 bit RSA key.

RSA signatures during handshakes are computationally expensive, typically 5 to 10x slower than ECDSA for equivalent security. RSA certificate chains are also larger: 4 to 6 KB versus 2 to 3 KB for ECDSA. This size difference matters because at a typical 1500 byte MTU (Maximum Transmission Unit, the largest packet size a network can transmit), RSA chains fragment into 3 to 4 packets while ECDSA fits in 2 packets. On lossy mobile networks, fewer packets means fewer opportunities for loss, improving handshake success rates by 5 to 15 percent.

Key Exchange Curve Selection

TLS 1.3 key exchange uses elliptic curves to establish shared secrets. X25519 is a modern curve designed for performance and security with simple, constant time implementations resistant to timing attacks. P-256 (also called secp256r1) is an older NIST standard with broader compatibility but more complex implementation requirements. Most modern clients support both.

Curve mismatch causes performance problems in TLS 1.3. When the client offers curves the server does not support, the server sends a HelloRetryRequest asking the client to try again with different parameters. This adds a full extra round trip, negating TLS 1.3s 1-RTT handshake advantage. Production systems monitor HelloRetryRequest rates, targeting below 2 to 5 percent. If a server only supports P-256 but 40 percent of clients offer X25519 first, those connections add 50 to 100ms extra latency on typical mobile RTTs.

Dual Certificate Deployment

Large scale deployments serve both RSA and ECDSA certificates simultaneously. Modern clients (representing over 95 percent of traffic) automatically select smaller ECDSA chains for faster handshakes and lower packet loss. Legacy clients that do not support ECDSA fall back to RSA. This maximizes compatibility while optimizing performance for the majority, at the cost of doubling certificate management complexity.