'AESLib::gen_iv' is not random

[m3th0d]

AESLib::gen_iv doesn't fill IV with random bytes but with 0xFF:

void AESLib::gen_iv(byte  *iv) {
    for (int i = 0 ; i < N_BLOCK ; i++ ) {
        iv[i]= (byte) 0xFF; // getrnd();
    }
}

I can see AESLib::getrnd() above:

uint8_t AESLib::getrnd()
{
   uint8_t really_random = *(volatile uint8_t *)0x3FF20E44;
   return really_random;
}

Is it an accident or by design?

[suculent]

This os by original design, feel free to submit better implementation.

Odesláno z iPhonu

31. 3. 2019 v 13:55, Alexey Bogdanov notifications@github.com:

AESLib::gen_iv doesn't fill IV with random bytes but with 0xFF:

void AESLib::gen_iv(byte *iv) { for (int i = 0 ; i < N_BLOCK ; i++ ) { iv[i]= (byte) 0xFF; // getrnd(); } } I can see AESLib::getrnd() above:

uint8_t AESLib::getrnd() { uint8_t really_random = (volatile uint8_t )0x3FF20E44; return really_random; } Is it an accident or by design?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[m3th0d]

Well, I'm not a pro in Arduino. But as I can see it's kinda tricky to get true random on this microcontrollers. I decided to use Crypto library by Rhys Weatherley. The library provides RNG (Random Number Generator) class, which uses NoiseSource class to generate random numbers. There are two implementations of NoiseSource in the library - RingOscillatorNoiseSource and more secure but requires additional electric components TransistorNoiseSource. You can read more about it in the links I provided if interested in this topic.

Anyway, it's 100% not a good idea to use same 0xFF-filled IV. I think the best (the fastest) option here is to remove these two methods from AESLib and expect users to init IV in their own way. And fix examples: use default random() from standard Arduino library. My guess is it's weak, but anyway better than nothing (0xFF) and gives an idea about how IV-initialization should be implemented. And add warning comment in this case to your examples, something like: "Do not use standard Arduino random to fill IV in security-sensitive projects".

[suculent]

Anyway, it's 100% not a good idea to use same 0xFF-filled IV.

Reason for this was testing in development, because it does what it does... encrypting always with the same result. Changed to getrnd().