- API Documentation
- Browse Source Code
- Change Log
- Project Goals
- On Naming Things
- Supported Crypto
- Roadmap and Status
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 +
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.
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.
|API documentation (HTML)||Done (0.2)|
|API documentation (man pages)||Planned|
|Arch-specific compilation||Done (0.3)|
|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|
|SHAKE||Planned||Required for Ed448 signature support.|
|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)|
|GHASH (POWER8)||Done (0.4)|
|Poly1305 (32->32 multipications)||Done (0.3)|
|Poly1305 (64->128 multiplications)||Done (0.4)|
|HMAC constant-time||Done (0.1)|
|HMAC DRBG||Done (0.1)|
|AES/CTR DRBG||Done (0.6)|
|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)|
|AES constant-time (POWER8)||Done (0.4)|
|ChaCha20 (x86/SSE2)||Done (0.5)|
|DES/3DES (classic, with tables)||Done (0.1)|
|DES/3DES (constant-time)||Done (0.1)|
|RSA (constant-time, 32-bit)||Done (0.1)|
|RSA with OAEP||Done (0.6)|
|RSA with PSS||Planned|
|RSA key pair generation||Done (0.6)|
|EC (generic, 32-bit)||Done (0.1)|
|EC (generic, 32->32 only)||Done (0.3)|
|EC NIST P-256 (32-bit)||Done (0.3)|
|EC NIST P-256 (32->32 only)||Done (0.3)|
|EC NIST P-256 (with
|EC NIST P-384 (32-bit)||Planned|
|EC NIST P-384 (32->32 only)||Planned|
|EC NIST P-384 (with
|EC Curve25519 (32-bit)||Done (0.3)|
|EC Curve25519 (32->32 only)||Done (0.3)|
|EC Curve25519 (with
|ECDSA (generic, 32-bit)||Done (0.1)|
|ECDSA (generic, 32->32 only)||Done (0.3)|
|EC key pair generation||Done (0.6)|
|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)|
|Private key encoding (traditional)||Done (0.6)|
|Private key encoding (PKCS#8)||Done (0.6)|
|PEM encoding||Done (0.6)|
|Cert Request generation (PKCS#10)||Planned|
|SSL core engine||Done (0.1)|
|SSL client API||Done (0.1)|
|SSL server API||Done (0.1)|
|TLS 1.0||Done (0.1)|
|TLS 1.1||Done (0.1)|
|TLS 1.2||Done (0.1)|
|TLS 1.3||Planned||See the dedicated page|
|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||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.|
|Automatic test framework||Done (0.5)|
|Documentation||Ongoing||More documentation is always needed.|
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.
For some appropriate notion of readiness.↩