Memory requirements
RAM and flash memories are often the most critical resources of a microcontroller. A larger library footprint can even require a switch 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:
| RAM memory class |
Required 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) |
- RSA < 7,900 - SRP < 3,900 - Ed25519 < 1,300 - Everything else < 1000 |
All functions are available in single-part form |
|
Stack (stack-optimized and incremental functions) |
- SRP < 400 - Everything else < 300 |
Caller must provide pre-allocated context object, of similar size as stack space for single-part functions |
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 SRP and Ed25519. 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 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 a description of the function types that are supported (single-part, stack-optimized and incremental), see this page.
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.