Roadmap

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 will have a revamped build system that handles multiple architectures. In particular, it should work on most Unix-like systems, including OS X, and also on Windows platforms; it shall also properly handle cross-compilation, since development for embedded systems uses cross-compilation.

    The new build system is meant to allow inclusion of architecture-specific source files, thus permitting optimised implementations with intrinsics or assembly. Version 0.3 will use that feature to provide AES and GHASH implementations powered with SSE2 and/or AES-NI instructions.

    Estimated release date is late January 2017.

  • Version 0.4 will focus on making better implementations for asymmetric cryptographic algorithms, in particular some big integer code that can use 64-bit multiplications (with a 128-bit result) on platforms that offer such operations. Support for some of the “newer” curves (Curve25519 and Curve448) will probably be included (as defined in RFC 7748) but maybe not yet integrated in TLS handshakes (depending on draft status at that point, and existence of interoperable implementations to test against).

    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 Scheduled for 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 Requires arch-specific compilation.
SHA-512 (assembly, ARM) Planned Requires arch-specific compilation.
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) Scheduled for 0.3 Requires arch-specific compilation.
GHASH (x86/AES-NI) Scheduled for 0.3 Requires arch-specific compilation.
Poly1305 Done (0.2)
Poly1305 (64->128 multiplications) Scheduled for 0.3 Requires arch-specific compilation.
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 Requires arch-specific compilation.
AES (tiny, assembly, i386) Planned Requires arch-specific compilation.
AES (tiny, assembly, amd64) Planned Requires arch-specific compilation.
AES constant-time (32-bit) Done (0.1)
AES constant-time (64-bit) Done (0.1)
AES constant-time (x86/SSE2) Scheduled for 0.3 Requires arch-specific compilation.
AES constant-time (x86/AES-NI) Scheduled for 0.3 Requires arch-specific compilation.
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) Scheduled for 0.4 Requires arch-specific compilation.
RSA with OAEP/PSS Planned
RSA key pair generation Planned
EC (generic, 32-bit) Done (0.1)
EC (generic, __uint128) Scheduled for 0.4
EC NIST P-256 (32-bit) Scheduled for 0.3
EC NIST P-256 (with __uint128) Scheduled for 0.4 Requires arch-specific compilation.
EC NIST P-384 (32-bit) Scheduled for 0.3
EC NIST P-384 (with __uint128) Scheduled for 0.4 Requires arch-specific compilation.
EC Curve25519 Scheduled for 0.4 TLS integration may wait for the RFC.
EC Curve448 Scheduled for 0.4 TLS integration may wait for the RFC.
EC EdDSA Planned When the final RFC is published.
ECDSA (generic, 32-bit) Done (0.1)
EC key pair generation Scheduled for 0.3 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: TLS_FALLBACK_SCSV Done (0.2)
SSL ext: ClientHello padding Done (0.2)
SSL ext: ALPN Planned Needed for HTTP/2 support.
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.