• Main
• API Documentation
• Browse Source Code
• Change Log
• Project Goals
• On Naming Things
• Supported Crypto
• Roadmap and Status

• • Roadmap
  • Feature Schedule
  • Documentation Effort

• OOP in C
• API Overview
• X.509 Certificates
• Constant-Time Crypto
• Constant-Time Mul
• Speed Benchmarks
• Size Calculator
• BoarSSL and Twrch
• TLS 1.3 Status
• Big Integer Design
• Extra Information
• Contribute

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 ready¹.

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 was released on July 30th, 2017. Main addition was a new testing framework called BoarSSL / Twrch in which BearSSL is automatically tested against an independent C# TLS implementation, that exercises many parameter combinations and abnormal exchanges. BearSSL was declared to reach “beta” level.

• Version 0.6 was released on August 14th, 2018. Some stand-alone general-purpose (non-SSL) implementations have been added, especially EAX and CCM authenticated encryption modes, RSA/OAEP encryption, and HKDF. Key pair generation for both RSA and EC was implemented, as well as key pair encoding in the usual formats in the X.509 world.

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.

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.