• Main
• API Documentation
• Browse Source Code
• Change Log
• Project Goals
• On Naming Things

• • The BearSSL Name
  • C Identifiers

• Supported Crypto
• Roadmap and Status
• 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

The BearSSL Name

As soon as the first version of BearSSL was published, there has been some debate about its name.

The “Bear” part is not a reference to any existing SSL/TLS library, be it PolarSSL, wolfSSL, or any other. I just happen to be quite fond of bears; I have been for a long time, and this is why I use a bear picture for my presence on online forums (usually a photo of a black bear that I took in a zoo in the city of Bonaventure, Québec, Canada, back in 2009). There is also a longstanding tradition of naming cryptographic algorithms out of animals (e.g. Blowfish or Serpent) so the use of an ursine theme is hardly surprising.

The “SSL” name is traditional. I am aware that the recent versions of the protocol are called “TLS”, and that there is a relatively widespread convention of saying “SSL” to mean SSL-3.0, and “TLS” for TLS-1.0 and later. This, however, does not map well to the technical reality. To state things in some details:

• “SSL” stands for “Secure Socket Layer” and was invented by Netscape, back when Netscape was still a thing. They applied that name to three quite different protocols, thereafter known as SSL-1.0, SSL-2.0 and SSL-3.0.

  SSL-1.0 was never published, though it has been apparently presented once to some external researchers, resulting in some immediate breakage; it has been informally described as “embarassing”. Not many details are known about it, except its unwise use of CRC-32 for integrity checks.

  SSL-2.0 has many known shortcomings and has been deprecated for years, even explicitly prohibited by RFC 6176. Recently, an attack called DROWN was presented, that shows that even if not actually used by clients, the mere presence of an SSL-2.0-aware server can be severely toxic.

  SSL-3.0 was a complete rewrite of the protocol, long published only as an informal draft (in 2011, RFC 6101 was published to finally document it).

• “TLS” means “Transport Layer Security”. The change of name is more or less a hint at the applicability of the protocol to transport mechanisms other than TCP sockets, but, in reality, what prompted the new name was a new ownership: from TLS-1.0 onward, the protocol was no longer maintained by Netscape, but by the IETF. Using a new name was a simple way to avoid any trademark-related shenanigans.

  In practice, TLS-1.0 and SSL-3.0 are almost identical (one of the minute differences turned out to be a major defect in SSL-3.0, a vulnerability nicknamed POODLE, which is why SSL-3.0 is officially deprecated). Even TLS-1.1 and TLS-1.2 share great similarity with TLS-1.0 and SSL-3.0, and SSL-3.0 is much closer to TLS-1.2 than to SSL-2.0.

So basically, the “SSL vs TLS” taxonomy represents the ownership change in 1999, but not the technical details of the protocols. From a purely technical point of view, lumping together SSL-3.0 with SSL-2.0 but separating it from the TLS versions is about as wrong as, in biology, classifying whales as a kind of fish (despite what Herman Melville wrote about them).

Therefore, I tend to use “SSL” (or “SSL/TLS”) to designate the whole conceptual family of protocols, from SSL-1.0 to TLS-1.2. This is the main reason why BearSSL is called BearSSL and not BearTLS.

A secondary reason is more about marketing. People who know what TLS is also know what SSL is, but not the other way round. For instance, Web site owners look for a “SSL certificate”, not a “TLS certificate”. By using the “SSL” acronym, I thus reach a wider audience, even if it is at the cost of irritating some of the more pickish taxonomists (and I am totally ready to out-pedant them if need be, as demonstrated above).

C Identifiers

C does not have true namespaces. It has a few scopes; e.g., a function declared static won’t be visible from files other than the one it was defined in (technically, “translation unit”, not “file”, but that’s not important here). But anything that is globally reachable lives in a single space of names where collisions must be avoided.

In order to lower the risk of name collisions, every single globally accessible BearSSL function or data element has a name that begins with the three characters “br_”. Similarly, macros and macro-like functions (static inline functions) defined in header files, to be included by applications using BearSSL, all have a name starting with “br_” or “BR_”. Hopefully, this should avoid most if not all of potential collisions.

I tried to follow relatively systematic naming conventions:

• C function names are in lowercase, consisting in words separated by underscore characters. This is common in C code; e.g. this is how things are normally defined in the Linux kernel.

• Such word sequences go from the general to the particular. For instance, the br_aes_ct64_cbcenc_init() function name should read as:

  • br: this is a BearSSL function;
  • aes: which is about AES;
  • ct64: using the “ct64” implementation (constant-time code that uses 64-bit integers, thus runs well on 64-bit platforms);
  • cbcenc: for CBC encryption;
  • init: and doing some context initialisation.

It is highly probable that I slipped at some point and that one function or another is inadequately named. At this point of the BearSSL development cycle (the “0.*” versions), naming inconsistencies are considered as bugs to be fixed (good naming is considered, at that point, more important than backward compatibility; this will change once entering the “stable” versions).