While BearSSL improvements and fixes are pushed when ready into the git repository, one at a time, I plan to make some “formal releases” when some milestones are reached. This is not a strict schedule and may change over time; in particular, dates are merely estimate and code is shipped when ready, only when ready1.

Right now, this is how releases should go:

  • Version 0.2 was realeased on December 13th, 2016. It got the last “big API changes” with the addition of client certificates. Subsequent releases (until 1.0) may still break binary compatibility, but should keep source compatibility.

  • Version 0.3 was released on January 29th, 2017. The build system (makefiles) has been revamped, to more easily handle multiple architectures and cross-compilation.

    This new build system has been used to allow inclusion of AES and GHASH implementations powered by the AES-NI opcodes. These are compatible with GCC, Clang, and also Visual Studio + nmake.exe (on Windodws).

    That version also saw inclusion of many elliptic curve implementations, including support for Curve25519, and RSA/EC code optimised for ARM Cortex M platforms.

  • Version 0.4 was released on April 3rd, 2017. It includes some new implementations: optimised AES/GCM on POWER8 systems (with specialised crypto opcodes), and new Poly1305 and RSA implementations leveraging 64→128 multiplications (available on some 64-bit architectures).

  • Version 0.5 will focus on validating the SSL code, especially buffering. This should entail a combination of thorough documentation of the internal behaviour, and a test/fuzzing system to exercise various adverse conditions. This step is required to advance the library to “beta” status.

    There is no estimated release date for this version.

Feature Schedule

The table below lists the BearSSL features, and their status. Each status is one of:

  • Done (x.y): feature is implemented, first appearing in version “x.y”.

  • Scheduled for x.y: feature is not implemented yet, but should be included in version “x.y”.

  • Planned: feature will be implemented in a future version, but no schedule has been made yet.

  • Never: feature will not be implemented.

All schedules are potentially subject to change; even a feature tagged “never” may still be implemented at some point, if some compelling arguments make me change my mind on that subject.

Feature Status Notes
API documentation (HTML) Done (0.2)
API documentation (man pages) Planned
Arch-specific compilation Done (0.3)
MD5 Done (0.1)
SHA-1 Done (0.1)
SHA-224 and SHA-256 Done (0.1)
SHA-384 and SHA-512 Done (0.1)
SHA-512/224 and SHA-512/256 Planned Delayed: no standard “TLS” identifier defined.
SHA-256 (assembly, ARM) Planned
SHA-512 (assembly, ARM) Planned
Multi-Hasher Done (0.1)
GHASH (32->64 multiplications) Done (0.1)
GHASH (32->32 multiplications) Done (0.1)
GHASH (64->64 multiplications) Done (0.1)
GHASH (x86/SSE2) Planned Maybe not much useful.
GHASH (x86/AES-NI) Done (0.3)
Poly1305 Done (0.2)
Poly1305 (32->32 multipications) Done (0.3)
Poly1305 (64->128 multiplications) Done (0.4)
HMAC Done (0.1)
HMAC constant-time Done (0.1)
HMAC DRBG Done (0.1)
PRF for TLS 1.0/1.1 Done (0.1)
PRF for TLS 1.2 Done (0.1)
AES (classic, with tables) Done (0.1)
AES (small, with tables) Done (0.1)
AES (tiny, assembly, ARM) Planned
AES (tiny, assembly, i386) Planned
AES (tiny, assembly, amd64) Planned
AES constant-time (32-bit) Done (0.1)
AES constant-time (64-bit) Done (0.1)
AES constant-time (x86/SSE2) Planned
AES constant-time (x86/AES-NI) Done (0.3)
ChaCha20 Done (0.2)
DES/3DES (classic, with tables) Done (0.1)
DES/3DES (constant-time) Done (0.1)
RC4 Never
RSA (constant-time, 32-bit) Done (0.1)
RSA (constant-time, __uint128) Done (0.4)
RSA with OAEP/PSS Planned
RSA key pair generation Planned
EC (generic, 32-bit) Done (0.1)
EC (generic, 32->32 only) Done (0.3)
EC (generic, __uint128) Planned
EC NIST P-256 (32-bit) Done (0.3)
EC NIST P-256 (32->32 only) Done (0.3)
EC NIST P-256 (with __uint128) Planned
EC NIST P-384 (32-bit) Planned
EC NIST P-384 (32->32 only) Planned
EC NIST P-384 (with __uint128) Planned
EC Curve25519 (32-bit) Done (0.3)
EC Curve25519 (32->32 only) Done (0.3)
EC Curve25519 (with __uint128) Planned
EC Curve448 Planned
EC EdDSA Planned Stalled for identifier definition (rfc4492bis)
ECDSA (generic, 32-bit) Done (0.1)
ECDSA (generic, 32->32 only) Done (0.3)
EC key pair generation Planned Mostly done, needs only an API.
X.509 chain validation API Done (0.1)
X.509 “known key” model Done (0.1)
X.509 minimal validation Done (0.1)
X.509 name extraction (DN, SAN) Done (0.2)
X.509 Name Constraints (basic) Planned
X.509 wrapper for CryptoAPI Planned
Private key decoding (traditional) Done (0.1)
Private key decoding (PKCS#8) Done (0.1)
PEM decoding (streamed) Done (0.1)
Cert Request generation (PKCS#10) Planned Requires RSA and EC key pair generation.
SSL core engine Done (0.1)
SSL client API Done (0.1)
SSL server API Done (0.1)
SSL 2.0 Never
SSL 3.0 Never
TLS 1.0 Done (0.1)
TLS 1.1 Done (0.1)
TLS 1.2 Done (0.1)
TLS 1.3 Planned When the final RFC is published.
DTLS (1.0, 1.2) Planned
SSL RSA key exchange Done (0.1)
SSL ECDH key exchange Done (0.1)
SSL ECDHE key exchange Done (0.1)
SSL renegotiation Done (0.1)
SSL no-renegotiation flag Done (0.2)
SSL session resumption (client) Done (0.1)
SSL session resumption (server) Done (0.1)
SSL session cache (client-side API) Done (0.2)
SSL session cache (server-side) Done (0.1)
SSL client certificates (client) Done (0.2)
SSL client certificates (server) Done (0.2)
SSL ext: ClientHello padding Done (0.2)
SSL ext: ALPN Done (0.3)
SSL multi-threaded wrappers Planned Locks and synchro for multi-threaded access.
T0 optimisation (inlining) Planned Automatic function inlining when appropriate.
T0 optimisation (encoding) Done (0.2) More space-efficient bytecode format.
Documentation Ongoing More documentation is always needed.

Documentation Effort

Documentation is an ongoing effort, especially since one of the long-term goals of BearSSL is to be usable as a pedagogical implementation of SSL/TLS. In other words, techniques employed therein make most sense only when they are duly explained.

Future documentation efforts will primarily focus on the following areas:

  • API for existing and new features. The function-by-function documentation in HTML is partly done (with Doxygen) and should be completed soon. Man pages (for Linux and other Unix-like systems) will be done at some point, too. More usage samples are still needed.

  • T0 documentation. The T0 language shall be thoroughly explained and documented: syntax, compilation, structure, and rationale.

  • Buffering. Most of the inner workings of the SSL engine is about keeping track of data and assembly of records. It is a complex system, which should be thoroughly detailed, and, if possible, “proven” by making explicit all assumptions throughout the code. It is expected that such a documentation work will uncover some potentially nasty bugs.

  • Cryptographic trickeries. Cryptographic algorithm implementations employ some specific techniques that are important for performance and/or security, in particular constant-time code, which must be explained in full details.

  1. For some appropriate notion of readiness.