Improvement: Use Blake2 in get_random

[secworks]

Hi!

As one of the Tillitis developers, I love to see this project.

A possible small improvement I would like to suggest is to use Blake2 when generating random numbers. The TRNG generates quite good random data (at least I as the developer of the TRNG core think so). But it is recommended to not use the TRNG data directly in an application, but instead as seed to a CSPRNG / DRBG. The reason for this is that if the TRNG starts having bias (possibly due to an attack), is not working correctly, this will affect the output directly. By using a good hash to scramble and compress the TRNG data, you are guaranteed much more uniform randomness with high quality.

You use the random data as nonce for the ChaCha20 based AEAD, and for this algorithm a good nonce is important. In the RNG stream app I use blake2s to generate random numbers by extracting words from the TRNG, and then hash them together:

https://github.com/tillitis/tillitis-key1-apps/blob/main/apps/rng_stream/main.c

(Pardon my ugly C code.)

The downside of this change is that you will need to read out more TRNG data, and perform Blake2 hashing. This will make the get_random function slower. You have the Blake2b function as part of Monocypher, so the code will not increase very much.

Just at suggestion.

[0xMihir]

Would it be faster to use the blake2s from the FPGA? Also, since the algorithms are different, would it still be suitable?

[secworks]

(Sorry for a slow response.)

Yes and yes. ;-)
The Blake2s in firmware should be faster than Blake2b. Blake2b has 1024 bit internal state and use 64 bit operations. Blake2s has 512 bit internal states and use 32 bit operations. This means that an add vill take one cycle on the PicoRV32, not multiple cycles.

Regarding the security - Blake2s is a replacement, alternative to SHA-256, and has in several ways better properties than SHA-256. For generating good random numbers for keys, IV, nonce Blake2s is very useful and suitable.

If you use the Blake2s in FW you can shave of a kByte or so of the app binary. And we get an app that tests the usability of the FW function.