Wastes global RAM

[zhekaus]

For instance, if I want to use simple Acorm128, it steals 153 bytes from the global memory of microcontroller! That’s definitely bad behavior.

Every byte matters in embedded programming .

[rweather]

The number of bytes to represent the Acorn128 state in my library is 60 bytes on AVR. It has to go somewhere. :-)

If you have a higher-level "encrypt packet" function in your program, then you can put the Acorn128 object on the stack temporarily during packet encryption and then reclaim the memory afterwards by popping it off the stack. You still need the 60 bytes to encrypt the packet, but you can use those 60 bytes for something else afterwards.

The RNG also needs at least 150 or so bytes of global memory to store the ChaCha20 state to perform secure state mixing. So perhaps that is where all your global memory is going. Random numbers are kind of essential for secure cryptography.

The RNG's size could be reduced by using a different algorithm than ChaCha20, or trying to move some of it to the stack. But that would take quite a bit of work and you'd still be paying the flash memory cost of whatever alternative algorithm was used even if the RAM could be reduced.

I do plan to revisit the RNG at some point once a suitable lightweight algorithm presents itself. NIST is currently running a competition to standardise a new lightweight algorithm but it will be a year or two before the competition runs its course.

[zhekaus]

Your library uses RAM even if it does nothing. This is unusual case and must be refactored. Normally, RAM is used when functions are active and objects are created.

However, your library takes RAM even if I have not constructed any object.

150 bytes of global space is too much for two encrypt/decrypt calls during the whole life-cycle of the device.

[rweather]

I just did a test of an empty sketch, compiling for AVR. You're right that just doing #include will use 150 or so bytes of global space. Commenting out the RNG code reduces that down to almost nothing.

So the default usage is the RNG state. Since every useful cryptographic protocol needs a random number generator to create nonce and session key material, the cost is kind of unavoidable. Even if the memory was created on-demand the first time the RNG was used, you'd still be paying the cost on the heap anyway.

If it bothers you and you have no need for a random number generator, then comment out the code in RNG.cpp and have fun.

Alternatively, feel free to fork the code and create a version of the RNG that creates the random pool memory on the fly, and submit a merge request.