Quality has many dimensions. For a cryptographic library, security is the most important quality attribute. It hinges on a good selection of algorithms and the correctness of their implementations. Given the rising importance of side-channel attacks, implementation techniques like constant-time, pc-secure and table-free execution are also essential.

Yet memory footprint, speed / power consumption, the breadth of supported platforms, the simplicity and suitability of a library's APIs (e.g., support for incremental processing), and the simplicity of integrating and building the library with different toolchains are also important in practice. Footprint, speed and power consumption are particularly critical for low-cost, battery-powered devices that are the foundation of large-scale IoT applications.

Thanks to its quality implementation, ocrypto is the choice of many market-leading companies, for example of Nordic Semiconductor for their Bluetooth Low Energy chips and their low-power cellular IoT products.

RAM and flash memories are often the most critical resources of a microcontroller. A larger library footprint may even require moving to a more expensive microcontroller model with more memory.

ocrypto is highly memory-efficient, both regarding code size and RAM usage. Code size is typically less than 1/2 to 1/6 the size that competing libraries require. Regarding RAM requirements, this table gives more details:

In order to make memory consumption (and speed) predictable, the ocrypto library does not use any dynamic memory allocation. Neither does it allocate any static variables. By default, its crypto functions only use the stack (single-part functions in the table above).

There are applications where stack real estate comes at a premium, e.g., when using an RTOS with many threads that only have 1 KB of stack space per thread. For such challenging situations, ocrypto provides an alternate set of functions for algorithms that require (relatively) large chunks of memory – in particular Ed25519 and SRP. When calling these alternate functions, the caller provides a context memory block that need not reside on the stack.

As an example, the stack-based Ed25519 sign function requires 1192 bytes of stack space, which is already extremely frugal for this algorithm. However, the stack-optimized alternate implementation of Ed25519 brings this down even much further, to 280 bytes of stack space (plus a context memory block for the rest). This leaves valuable room on the stack for application variables.

These stack numbers have been measured with a Keil compiler for a Cortex-M4F microcontroller.

For an application example that includes code size: the crypto code needed for a HomeKit Light Bulb profile implementation requires the following memory for a Cortex-M4F core (all numbers in bytes):

• code size: 18,600
• stack size: 3,236
• static variables and heap size: 0

See these industry-standard benchmarks for additional examples of memory requirements.

Speed means low cost and low-power operation

The speed of cryptographic code is important for maximizing throughput and for minimizing latencies in protocols that use the code. This can be relevant for meeting timing constraints or to obtain a good user experience. However, having faster code – i.e., code that performs the same work in fewer processor cycles – could also allow you to select slower microcontrollers and thereby reduce the BOM costs of your hardware. Moreover, as CMOS circuits mainly consume power when switching states, using fewer processor cycles means fewer state switches and therefore less power drain, which is particularly relevant for battery-powered devices.

See our benchmarks for performance and energy scores compared to other popular crypto libraries for embedded hardware.

Algorithmic innovations

We have developed, analyzed and optimized the cryptographic code of ocrypto since 2013. During that time, we have introduced several unique algorithmic innovations, in order to achieve state-of-the-art performance while ensuring constant-time, pc-secure and table-free execution in order to increase side-channel resistance:

• Combination of known algorithms for multiplication in a prime field including modular reduction. It reduces the number of expensive instructions. For example, it brings down the number of multiplications for SRP from 64 to 8 million.
• New bitslice implementation for AES. A new field-theoretical approach for the S-box calculation allows an efficient and table-free implementation of AES without the overhead and complications of handling multiple blocks in parallel.
• New mathematical approach for NIST elliptic curves. Our enhanced co-Z implementation of the NIST curves (P-256 etc.) is unique in that it is complete, correct, efficient, table-free, and executes in constant time even in all edge cases.

Assembly-language optimizations

Going beyond algorithmic innovations, we have carefully written the most critical parts of the code in assembly language for popular microcontroller cores. ocrypto thus makes advanced communication protocols and advanced firmware security features feasible even on low-power, low-cost 32-bit microcontrollers without hardware accelerators. Or even for processors with hardware acceleration: in situations where the hardware accelerator does not cover all relevant algorithms, is not available to all microcontroller cores, or in systems where real-time threads compete for the accelerator hardware (e.g., where the application code competes with a BLE stack, or multiple encrypted connections run in parallel).

To make development as easy as possible, the ocrypto API is simple and identical across all platforms.

Configuration is easy. Just answer this question: which instruction set architecture are you targeting? For example, the ISA of a Cortex-M4F processor core. This determines which assembly files to use. No complex configuration space to navigate, in search of optimal runtime behavior!

To make development as easy as possible, the ocrypto API is simple and identical across all platforms.

Management of the ocrypto code is simple:

• The code has no dependencies on other software or on special hardware, only on the chosen instruction set architecture.
• The code does not contain any assertions/panics that would need to be caught by the device firmware.
• No open source disclosure is required.

Side-channel attacks are an increasingly important threat to the security of embedded systems. There exist several types of side-channels. The most important side channels are observable power consumption, timing behavior, and emitted radiation of a processor. Analysis of a single occurrence of a cryptographic operation (Simple Power Analysis, or SPA) is a prime example. A more elaborate variant requires an attacker to be able to force the same message being decrypted thousands of times (Differential Power Analysis, or DPA).

Countering side-channel attacks – without major sacrifice in execution speed – has proven to be a hard problem.

Illustration of how power measurements can infer information about the data being processed

ocrypto is resistant against SPA attacks using countermeasures described below. It is also resistant against DPA when used in protocols that make sure that repeatedly sending the same message always results in a different bit pattern being sent. This thwarts attempts to use statistical tools for determining secret data or keys. The HomeKit Accessory Protocol is an example of such a protocol.

To provide best-in-class side-channel resistance, all relevant operations in ocrypto have been designed from the outset for fast constant-time, PC-secure, and table-free execution. This makes the library side-channel resistant against the most likely attacks, even for microcontrollers with data caches. Moreover, ocrypto guarantees correctness and completeness (correct output for all edge cases) for NIST elliptic curves, which is notoriously difficult in a highly efficient implementation without giving up constant-time operation. Achieving this level of resistance to side-channel attacks, without introducing massive overhead, is what makes ocrypto unique in the industry. Check out these benchmarks to see what we mean.

We have created formal correctness proofs for our novel algorithmic approaches to modular reduction and had them reviewed by an independent authority (Prof. W. Meier, one of the designers of the BLAKE hashing algorithm). Our proofs were found “in all parts mathematically and formally correct”. Proof and review documents are available to licensees.

Excerpt from the review of our formal correctness proofs

An extensive test suite is used for validating ocrypto, with standard test vectors, test vectors for border cases, negative tests and random tests. The test suite is available to licensees.