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 important.
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 configuring, integrating and building the library 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. It also uses stack space very efficiently. Except for RSA and Ed25519, the required stack space is always less than 1000 bytes:
| RAM Memory Class | Required Stack Size (bytes) | Comment |
| Static memory | 0 | ocrypto does not use static memory |
| Heap | 0 | ocrypto does not use dynamic memory allocation |
| Stack (single-part functions, not stack-optimized) | < 1,000 (except for *) |
Single-part functions execute in a single call.
All ocrypto functions are available in single-part form, |
| Stack (single-part functions, stack-optimized) | < 300 (except for **) |
A few single-part functions are stack-optimized. The caller must provide a pre-allocated context object. ML-KEM and ML-DSA are always stack-optimized.
Ed25519 and SRP are available in both stack-optimized |
| Stack (incremental functions) | < 300 |
Incremental functions are provided for SHA, AES, The caller must provide a pre-allocated context object. |
* RSA < 7,900, Ed25519 < 1,300
** SRP < 400
Memory footprint of ML-DSA (PQC algorithm)
Given new regulations such as CNSA 2.0, an increasingly important challenge is to update existing devices with a secure bootloader that uses quantum-resistant authentication and integrity-checking of firmware images. Key to that is signature-verification, in particular with the increasingly popular ML-DSA as PQC algorithm. The ocrypto implementation of ML-DSA is best in class with the following footprint example for a Cortex-M4F (includes key generation, signing and sign verification; built with small option and an Arm Keil compiler; rounded up to KB):
See these industry-standard benchmarks for additional examples of memory requirements.
Contact us for speed measurements of PQC algorithms like ML-DSA, e.g., for Cortex-M4 or Cortex-M0!
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:
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. For ML-DSA, decide whether to use the default speed/size tradeoff or the small or fast alternatives. No complex configuration space to navigate, no searching by trial and error for the optimal runtime behavior!
Management of the ocrypto code is simple:
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 abysmal 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. For example, TLS 1.3 uses AEAD with unique nonces for every encrypted message.
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 inordinate 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.