- 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 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.
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|
|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)|
|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/PSS||Planned|
|RSA key pair generation||Planned|
|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
|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)|
|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||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.↩