• Main
• API Documentation
• Browse Source Code
• Change Log
• Project Goals
• On Naming Things
• Supported Crypto
• Roadmap and Status
• OOP in C
• API Overview
• X.509 Certificates
• Constant-Time Crypto
• Constant-Time Mul
• Speed Benchmarks

• • On Performance
  • Measuring Speed
  • Measures
    • Hash Functions
    • Symmetric Encryption
    • MAC
    • Elliptic Curves
    • RSA

• Size Calculator
• BoarSSL and Twrch
• TLS 1.3 Status
• Big Integer Design
• Extra Information
• Contribute

On Performance

BearSSL primary optimisation goal is to reduce compiled code size. This does not mean that raw execution speed is unimportant; only that, when faced with a size/speed trade-off, BearSSL tends to put more emphasis on the “size” measure than what most cryptographic libraries do. For instance, the RSA implementation will use generic code that can handle all key sizes, with no specific code for common key sizes (like 2048 bits).

Yet execution speed still matters, though situations vary a lot. For instance, some constrained environments need fast asymmetric crypto primitives, because when the SSL handshake occurs, the human user is waiting; but, conversely, symmetric encryption speed might not matter as much if it is used to support I/O over a slow network (it does not take much CPU to support encryption of a 115200 bauds serial link).

BearSSL’s API are meant to be flexible: for all algorithms, different implementations may be used, and possibly externally provided, with no modification of the library source code (this uses function pointers, not conditional compilation with preprocessor directives). BearSSL already offers several choices for most algorithms, that embody various trade-offs. The figures below illustrate the consequences of these choices.

The following points must be remembered:

• Most BearSSL implementations are written in generic, portable C code. In its current state, BearSSL has few architecture-specific code routines.

• Compilation is done with the default compiler on the platform (GCC), with “-Os” optimisation flag, which again favours size over speed. Of note, for RSA with the “i62” code, using Clang instead of GCC would offer a substantial speed-up (472 private-key operations per second instead on 355, on the “amd64” platform).

In future versions, additional implementations, notably architecture-specific routines with assembly, will be added. One notable planned import is the very efficient Curve25519 code from the µNaCl library.

Measuring Speed

Four platforms are presented here, using four different architectures:

• amd64: an Intel Xeon CPU (E3-1220 V2), at 3.10 GHz, in 64-bit mode. This is a rather powerful, yet already aging processor (launched in 2012). Compiler is GCC 5.4.0, with flags “-Os -fPIC”.

• i386: an Intel Xeon CPU (E3-1220 V2), at 3.10 GHz, in 32-bit mode. Compiler is GCC 5.4.0, with flags “-Os -fPIC”. This is the same platform as “amd64”, but used in 32-bit mode.

• pwr8: a POWER8E CPU, at 3.425 GHz, in 64-bit little-endian mode (“ppc64le”). Compiler is GCC 6.2.0, with flags “-Os -fPIC”.

• m0+: an ARM Cortex M0+, at 48 MHz (Atmel SAM D20 microcontroller). Compiler is GCC 4.9.3, with flags “-Os -mthumb -mcpu=cortex-m0plus”.

Measures are done by repeatedly processing a given data buffer (8 kilobytes) or running the relevant process (e.g. elliptic curve point multiplication) so that the total CPU time is at least two seconds (one second on the M0+, where the clock has millisecond precision). On Unix-like system, the clock() function measures CPU time allocated to the computation. Due to the unavoidable variance on multitasking operating systems, values should be considered as accurate ±3%.

On the M0+, there is no operating system, but a 1 kHz interrupt is set, allowing counting elapsed time with millisecond precision (measures show that the IRQ handler takes less than a microsecond, thus the timer overhead is negligible).

All measures have used BearSSL-0.4. Later versions might contain changes inducing different (hopefully better) performance.

Measures

Hash Functions

Processing speed for a long message (i.e. without padding overhead) is given in megabytes per second, except for the M0+ where values are expressed in kilobytes per second.

Symmetric Encryption

For AES, we again measure asymptotic speed for CBC encryption, CBC decryption and CTR mode; key schedule time is not measured. For 3DES, we also measure CBC encryption and CBC decryption, but there is no CTR mode. ChaCha20 performance is also provided.

Implementations are:

• AES “big”: a classic implementation with lookup tables (not constant-time).

• AES “small”: a compact implementation with small tables (not constant-time).

• AES “ct”: a constant-time implementation with bitslicing over 32-bit registers; two blocks are processed in parallel when the encryption mode allows it (CTR and CBC decryption, but not CBC encryption).

• AES “ct64”: a constant-time implementation similar to “ct” but using 64-bit variables.

• AES “x86ni”: an implementation using the AES-NI opcodes provided by recent (since late 2011) x86 CPU.

• AES “pwr8”: an implementation using the cryptographic opcodes of POWER8 processors.

• 3DES “tab”: a classic, table-based 3DES implementation (not constant-time).

• 3DES “ct”: a constant-time implementation that uses internal bitslice.

• ChaCha20 “ct”: a straightforward constant-time implementation of ChaCha20.

Note that in SSL, a MAC is also applied on the bulk of the data. CBC cipher suites use HMAC, which processes data at roughly the same speed as the underlying hash function. For GCM, the MAC part is GHASH; for ChaCha20, Poly1305 is used.

There again, speed is provided in megabytes per second, except for the M0+, where performance is given in kilobytes per second.

MAC

These are the MAC algorithms used in AEAD cipher suites: GHASH is combined with AES-CTR in AES/GCM, while Poly1305 is used with ChaCha20. Provided implementations are:

• GHASH “ctmul”: uses 32→64 multiplications.

• GHASH “ctmul32”: uses 32→32 multiplications.

• GHASH “ctmul64”: uses 64→64 multiplications.

• GHASH “pclmul”: an implementation that leverages the pclmulqdq opcode of recent x86 CPU (this opcode was added along with the AES-NI instructions).

• GHASH “pwr8”: an implementation that leverages the cryptographic opcodes of POWER8 processors.

• Poly1305 “ctmul”: uses 32→64 multiplications.

• Poly1305 “ctmul32”: uses 32→32 multiplications.

• Poly1305 “ctmulq”: uses 64→128 multiplications (available only on some 64-bit architectures).

• Poly1305 “i15”: an implementation that relies on the generic “i15” big integer code (also used by RSA and elliptic curves).

Processing speed is asymptotic, i.e. only bulk data bandwidth, not per-record overhead (which is slight for records of a few kilobytes in length). Bandwidth is expressed in megabytes per second, except for the M0+, where kilobytes per second are used.

Elliptic Curves

Elliptic curve implementations compute point multiplications: a given curve point is multiplied by a scalar whose length is that of the curve subgroup order. Four curves are supported: the three main NIST curves (P-256, P-384 and P-521), and Curve25519. Each implementation supports only some of these curves:

• “prime_i15” uses the “i15” big-integer code (32→32 multiplications) and supports the three NIST curves.

• “prime_i31” uses the “i31” big-integer code (32→64 multiplications) and supports the three NIST curves.

• “p256_m15” uses 32→32 multiplications and supports only P-256.

• “p256_m31” uses 32→64 multiplications and supports only P-256.

• “c25519_i15” and “c25519_i31” use, respectively, the “i15” and “i31” big-integer code, to implement Curve25519.

• “c25519_m15” and “c25519_m31” use, respectively, 32→32 and 32→64 multiplications, to implement Curve25519.

BearSSL also provide aggregate wrappers: the “all_m15” implementation uses “p256_m15” (for P-256), “c25519_m15” (for Curve25519), and “prime_i15” (for P-384 and P-521). Similarly, “all_m31” wraps around “p256_m31”, “c25519_m31” and “prime_i31”.

The “p256_m15” and “p256_m31” also feature an optimised code path when the point that is to be multiplied is the conventional generator for the curve. This is called “fixed point” (FP) below.

Numbers below are given in number of point multiplications per second. These figure translate to actual performance along the following lines:

• Static ECDH (not ECDHE) requires one point multiplication (both on the client and the server).

• ECDHE requires two point multiplications on the server (one is amenable to FP), and two point multiplications on the client (again, one may use FP optimisation).

• ECDSA signature generation (on the server when doing ECDHE_ECDSA, on the client when using client certificates with EC keys) requires one point multiplication (with FP optimisation), and a few extra operations that add about 10 to 20% overhead.

• ECDSA signature verification (on the client when doing ECDHE_ECDSA, on the server when validating a client signature with an EC key, and also for all ECDSA signatures on certificates) requires two point multiplications, one of which being amenable to FP optimisation. There is also a bit of overhead similar to that of signature generation.

RSA

For RSA, we measure the number of public-key and private-key operations per second, for a 2048-bit key (public exponent is the classic 65537). RSA key exchange involves a private-key operation on the server, a public-key operation on the client. RSA signature generation is a private-key operation, while verification is a public-key operation.

There are four implementations, that correspond to the underlying generic big-integer code:

• “i15”: uses 32→32 multiplications only; internally, integers are represented as arrays of 16-bit variables, each containing 15 bits of value.

• “i31”: uses 32→64 multiplications only; internally, integers are represented as arrays of 32-bit variables, each containing 31 bits of value.

• “i32”: a predecessor to “i31”, that stores 32 bits of value in each 32-bit variable. In general, “i32” is slower than “i31” on all platforms.

• “i62” uses the same internal representation as “i31”, except when computing multiplications, in which case 64-bit variables and 64→128 multiplications are used. It is available only on some 64-bit architecture. When present, it is much faster than “i31”.