Tips for saving RAM?

[RicardoPires19]

Hello,

I've been trying out this library (which is great by the way!), but it seems to consume a lot of SRAM. I've already tried to squeeze as much RAM as possible from my program, (not using Strings and allocating variables to flash with PROGMEM) and I don't know where else to cut.

I'm using the XTS-AES128 and SHA256 alongside the SD and Serial libraries. I managed to have the encryption functioning, but once I add the SHA256 there isn't enough memory to open files in the SD card. Both the XTS and SHA256 are declared as variables, should I use pointers instead?

So, what do you recommend?

(I'm using an Arduino UNO, btw)

[rweather]

XTS is very heavy - it needs two AES128 objects internally. That will use up to 400 bytes of RAM, which is nearly a quarter of all RAM on a Uno.

The random number generator RNG also consumes about 150 bytes even if you don't use it. So if you don't need that you could remove it from the library or comment it out.

I assume that you are using XTS to encrypt sectors on the SD card? It may be possible to rearrange the code to use only 1 BlockCipher object but keeping the key passed to XTSCommon::setKey() around and then setting each half of the key on the cipher during setTweak(), encryptSector(), and decryptSector(). But it would be slower to set up keys at the start of each sector encrypt/decrypt operation.

You may have to switch to an Arduino with more memory, sorry.

[rweather]

Another thing you could try is to use the AESSmall128 version of AES instead of AES128. It is slower, but it uses a lot less RAM for the key schedule.

[RicardoPires19]

Ok, I'll try to start by removing the RNG function, I think 150 bytes will be enough. But is the random() Arduino built-in function not secure?

[rweather]

If you need a source of random numbers for your application, then random() is not secure enough and you'll need RNG. But if you are encrypting/decrypting the SD card contents with a fixed XTS key then you may not need RNG.

[RicardoPires19]

Why isn't is secure? Because of the lack of randomness? Isn't the randomSeed() function good enough to compensate?

[rweather]

System random number generators like random() in Arduino and rand() in C are never safe to use for cryptographic purposes.

The randomSeed() function takes an unsigned long, which is only 32 bits of entropy, even assuming that you have a good source to get entropy from. And the random() function uses a predictable algorithm for converting one seed value into the next.

Such random number generators are fine for controlling the random firing from a monster in a video game. But not for cryptography.

Here is some more information on system random number generators: https://crypto.stackexchange.com/questions/15662/how-vulnerable-is-the-c-rand-in-public-cryptography-protocols

[profdc9]

A source of entropy based of avalanche noise of a transistor is easy to build and a schematic is included with the library. I can answer questions about it if desired. You can get several bits of entropy per sample by connecting it to the ADC of the Arduino. I made a device called the ParanoiaBox which uses a pair of such transistors. You can see the schematic and software on the github https://github.com/profdc9/ParanoiaBox/ Incidentally, the Bluepill (STM32F103CBT6) can also be used with Arduino and has much more flash, RAM, and is usually even cheaper than the Arduino Uno, being $2 to $3. You will have no problems fitting in cryptography in there and they will run much faster.

…

On Mon, Jun 1, 2020 at 11:25 PM rweather ***@***.***> wrote: System random number generators like random() in Arduino and rand() in C are never safe to use for cryptographic purposes. The randomSeed() function takes an unsigned long, which is only 32 bits of entropy, even assuming that you have a good source to get entropy from. And the random() function uses a predictable algorithm for converting one seed value into the next. Such random number generators are fine for controlling the random firing from a monster in a video game. But not for cryptography. Here is some more information on system random number generators: https://crypto.stackexchange.com/questions/15662/how-vulnerable-is-the-c-rand-in-public-cryptography-protocols — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#55 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKFIJZGAQX3GDOFNSQTHDL3RURWJ7ANCNFSM4NP5LNGA> .