Code Size

The table below is a dynamic calculator for total compiled code size, depending on selected algorithms. BearSSL is pluggable, so what a given SSL client or server engine supports depends on which algorithms were configured into it. From a programming point of view, each algorithm is configured by setting a pointer to the relevant implementation into the engine context; referencing that implementation means that, at link time, the corresponding code will be pulled into the produced binary, along with all its dependencies.

By selecting some implementations below, one can observe the effect on final code size. Note that internally some code is shared; for instance, RSA public and private operations may use the same internal big-integer implementation, so selecting both results in a code size which is less than the sum of the size induced by each searately. The calculator below takes such code sharing into account.

The total code size is inferred by adding the sizes of the relevant object files, as reported by the size utility (all platforms used for these benchmarks use ELF). Note that when linking, a few extra bytes may be added for alignment, or for some glue code in case of dynamic linking support.

To use the calculator below, first select an architecture, then some implementations. The calculator computes the total binary size, as well as the features (protocol versions and cipher suites) that can be used with the selected algorithms.

Note: this calculator uses Javascript.

Architecture

First select an architecture. The list of available code elements depends on that selection.

The x86 code was compiled with GCC 5.4.0 and options “-Os -fPIC”. The POWER8 code was compiled with GCC 6.2.0 and options “-Os -fPIC”. The ARM Cortex M0+ code was compiled with GCC 4.9.3 and options “-Os -mthumb -mcpu=cortex-m0plus”.

In all sections below, check the code elements you want to include in the calculation. The total size and activated features (e.g. supported cipher suites) that correspond to the checked elements are then listed.

Hash Functions

Hash functions are used within the handshake, and also to support signature generation and verification (in particular in certificates). TLS 1.0 and 1.1 requires both MD5 and SHA-1. TLS 1.2 uses either SHA-256 or SHA-384, depending on the cipher suite.

`md5`	MD5
`sha1`	SHA-1
`sha224`	SHA-224
`sha256`	SHA-256
`sha384`	SHA-384
`sha512`	SHA-512

Elliptic Curves

Raw elliptic curve support is needed for ECDH and ECDHE cipher suites, and for ECDSA signature generation or verification.

`ec_all_m15`	P-256, P-384, P-521, Curve25519, with m15 or i15 code
`ec_all_m31`	P-256, P-384, P-521, Curve25519, with m31 or i31 code
`ec_c25519_i15`	Curve25519, with i15 code
`ec_c25519_i31`	Curve25519, with i31 code
`ec_c25519_m15`	Curve25519, with m15 code
`ec_c25519_m31`	Curve25519, with m31 code
`ec_p256_m15`	P-256, with m15 code
`ec_p256_m31`	P-256, with m31 code
`ec_prime_i15`	P-256, P-384 and P-512, with i15 code
`ec_prime_i31`	P-256, P-384 and P-512, with i31 code

ECDSA

ECDSA signature generation and verification requires an elliptic curve implementation (that supports at least one of the NIST curves: P-256, P-384 and P-521), and an extra piece of code that performs the big integer computations specific to ECDSA (as opposed to ECDH).

`ecdsa_i15_sign`	ECDSA signature generation, with i15 code
`ecdsa_i15_vrfy`	ECDSA signature verification, with i15 code
`ecdsa_i31_sign`	ECDSA signature generation, with i31 code
`ecdsa_i31_vrfy`	ECDSA signature verification, with i31 code

RSA Signatures

For ECDHE_RSA cipher suites, the server needs to compute an RSA signature, and the client needs to verify that signature. Signature verification is also needed for X.509 certificate validation (validation of the server’s certificate on the client).

For certificate-based client authentication (except for full static ECDH), the client needs to compute a signature, and the server verifies it.

`rsa_i15_pkcs1_sign`	RSA signature generation, with i15 code
`rsa_i15_pkcs1_vrfy`	RSA signature verification, with i15 code
`rsa_i31_pkcs1_sign`	RSA signature generation, with i31 code
`rsa_i31_pkcs1_vrfy`	RSA signature verification, with i31 code
`rsa_i32_pkcs1_sign`	RSA signature generation, with i32 code
`rsa_i32_pkcs1_vrfy`	RSA signature verification, with i32 code
`rsa_i62_pkcs1_sign`	RSA signature generation, with i62 code
`rsa_i62_pkcs1_vrfy`	RSA signature verification, with i62 code

RSA Encryption

RSA cipher suites (not ECDH_RSA or ECDHE_RSA) use asymmetric encryption for key exchange. The client needs an RSA encryption engine, and the server requires an RSA decryption engine.

`rsa_i15_priv`	RSA decryption (private), with i15 code
`rsa_i15_pub`	RSA encryption (public), with i15 code
`rsa_i31_priv`	RSA decryption (private), with i31 code
`rsa_i31_pub`	RSA encryption (public), with i31 code
`rsa_i32_priv`	RSA decryption (private), with i32 code
`rsa_i32_pub`	RSA encryption (public), with i32 code
`rsa_i62_priv`	RSA decryption (private), with i62 code
`rsa_i62_pub`	RSA encryption (public), with i62 code

AES

AES_CBC cipher suites need an AES/CBC encryption engine and an AES/CBC decryption engine. These need not use the same implementation, although this is usually a good idea since the encryption and decryption engines for a given implementation tend to share some code.

AES_GCM cipher suites need an AES/CTR engine.

The “big” and “small” implementations use tables and thus are not constant-time.

`aes_big_cbcdec`	AES/CBC decryption, “big” (fast, uses tables)
`aes_big_cbcenc`	AES/CBC encryption, “big” (fast, uses tables)
`aes_big_ctr`	AES/CTR, “big” (fast, uses tables)
`aes_small_cbcdec`	AES/CBC decryption, “small” (uses tables)
`aes_small_cbcenc`	AES/CBC encryption, “small” (uses tables)
`aes_small_ctr`	AES/CTR, “small” (uses tables)
`aes_ct_cbcdec`	AES/CBC decryption, “ct” (constant-time, for 32-bit architectures)
`aes_ct_cbcenc`	AES/CBC encryption, “ct” (constant-time, for 32-bit architectures)
`aes_ct_ctr`	AES/CTR, “ct” (constant-time, for 32-bit architectures)
`aes_ct64_cbcdec`	AES/CBC decryption, “ct64” (constant-time, for 64-bit architectures)
`aes_ct64_cbcenc`	AES/CBC encryption, “ct64” (constant-time, for 64-bit architectures)
`aes_ct64_ctr`	AES/CTR, “ct64” (constant-time, for 64-bit architectures)
`aes_pwr8_cbcdec`	AES/CBC decryption, “pwr8” (with POWER8 crypto opcodes)
`aes_pwr8_cbcenc`	AES/CBC encryption, “pwr8” (with POWER8 crypto opcodes)
`aes_pwr8_ctr`	AES/CTR, “pwr8” (with POWER8 crypto opcodes)
`aes_x86ni_cbcdec`	AES/CBC decryption, “x86ni” (with AES-NI opcodes)
`aes_x86ni_cbcenc`	AES/CBC encryption, “x86ni” (with AES-NI opcodes)
`aes_x86ni_ctr`	AES/CTR, “x86ni” (with AES-NI opcodes)

GHASH

A GHASH implementation is needed for AES/GCM cipher suites.

`ghash_ctmul`	GHASH with 32→64 multiplications
`ghash_ctmul32`	GHASH with 32→32 multiplications
`ghash_ctmul64`	GHASH with 64→64 multiplications
`ghash_pclmul`	GHASH with AES-NI opcodes (pclmulqdq)
`ghash_pwr8`	GHASH with POWER8 crypto opcodes

3DES

3DES cipher suites (“3DES_EDE_CBC”) need a 3DES/CBC encryption engine and a 3DES/CBC decryption engine. The “tab” implementation is faster than “ct”; however, “ct” is constant-time while “tab” is not.

`des_tab_cbcdec`	3DES/CBC decryption, “tab” (uses tables)
`des_tab_cbcenc`	3DES/CBC encryption, “tab” (uses tables)
`des_ct_cbcdec`	3DES/CBC decryption, “ct” (constant-time)
`des_ct_cbcenc`	3DES/CBC encryption, “ct” (constant-time)

ChaCha20

ChaCha20+Poly1305 cipher suites require a ChaCha20 implementation.

ChaCha20, “ct”

Poly1305

ChaCha20+Poly1305 cipher suites require a Poly1305 implementation.

`poly1305_ctmul`	Poly1305, “ctmul” (with 32→64 multiplications)
`poly1305_ctmul32`	Poly1305, “ctmul32” (with 32→32 multiplications)
`poly1305_ctmulq`	Poly1305, “ctmulq” (with 64→128 multiplications)
`poly1305_i15`	Poly1305, “i15” (with i15 big integer code)

SSL Handshake

SSL client and server share a common processing engine, but each has specific code for handling handshake messages.

`ssl_client`	SSL client engine
`ssl_server`	SSL server engine

SSL Records

The record processing code (encryption+MAC) depends on the type of encryption used.

`sslrec_cbc`	SSL records with CBC+HMAC encryption/decryption
`sslrec_chapol`	SSL records with ChaCha20+Poly1305 encryption/decryption
`sslrec_gcm`	SSL records with GCM encryption/decryption

PRF

TLS 1.0 and 1.1 use a PRF function that relies on MD5 and SHA-1.

TLS 1.2 uses a PRF that relies on either SHA-256 or SHA-384, depending on the cipher suite.

`prf_tls10`	PRF for TLS 1.0 and 1.1 (uses MD5 and SHA-1)
`prf_tls12_sha256`	PRF for TLS 1.2 with SHA-256
`prf_tls12_sha384`	PRF for TLS 1.2 with SHA-384

Certificate

The server must send a certificate that contains its public key, and use the corresponding private key. Similarly, when client certificates are used, the client must send a certificate and use the corresponding private key. The elements below contain the code that offers a single certificate chain and uses the private key.

`ssl_ccert_ec`	SSL client certificate authentication (ECDH/ECDSA)
`ssl_ccert_rsa`	SSL client certificate authentication (RSA)
`ssl_scert_ec`	SSL server certificate (ECDH/ECDSA)
`ssl_scert_rsa`	SSL server certificate (RSA)

X.509 Validation

X.509 validation is used to extract the public key sent by the peer. Clients need an X.509 engine; if client certificates are used, then servers also need an X.509 engine.

The “knownkey” engine ignores the received certificate chain, and returns an hardcoded public key. The “minimal” engine performs basic chain validation, which entails verifying signatures; which signatures are supported depends on the configured hash functions and signature verification engines.

`x509_knownkey`	X.509 validation (pseudo: public key already known)
`x509_minimal`	X.509 validation (single chain processing)

Total

Total:

Supported cipher suites as SSL client:

TLS 1.0 and 1.1:
TLS 1.2:

Supported cipher suites as SSL server:

TLS 1.0 and 1.1:
TLS 1.2: