AES delay

[dagid4]

Hello,

I'm fiddling with AES encryption for RFM69HCW. According to datasheet:

The encryption/decryption process takes approximately 7.0 us per 16-byte block. Thus for a maximum of 4 blocks (i.e. 64 bytes) it can take up to 28 us for completing the cryptographic operations.

But when I measure with osciloscope using this pseudocode:

Code Select Expand

  signal_high();
  
  rf69_command(0x810C);
  
  if(!CHECK(rf69_ready()))
    return -1;
  
  if(!CHECK(rf69_wait(0x2800, PACKET_SENT)))
    return -2;
  
  signal_low();

For 64kbit/s, 1B preamble, 2B sync word, 5B payload, 2B CRC => 10B total:

I got approx. 1,5ms without AES, but 3ms with AES. Why is there 1,5ms delay for AES?

PS: When I add 10B to preamble, it is 4,5ms with AES, so it seems to be constant overhead.

Config: 00040001F40657D8B99A40200092F520006E050A000000008051414080060000000000000000070000E40000000188D1C0D4583627891358050000000101534D415254484F4D4552455345415243000000000000000000002D005D007C000000000000000000000000000000000000200000

[Felix]

I've done similar tests in the past when I created and tweaked my RFM69 library. As a quick guestimate answer, AES is an additional computing load on the RFM69 transceiver, ie it takes time to encrypt the 16byte chunks. That is mentioned in the datasheet. How you can arrive at 1.5ms that is a bit more involved and I believe there might be a formula associated with that datasheet AES section.
But I see you're using Radio Head instead?

I'd have to dig into that to understand exactly what is written to the registers, it's a lengthy exercise to hunt for that 1.5ms delay if it's not totally obvious from the datasheet, I remember spending days deciphering the datasheet, oscilloscoping, logic analyzing, and CurrentRanger'ing a Moteino to get exact measurements of everything happening on the SPI bus, registers, and power consumption.

Maybe if you can try this with my library? You can write to registers directly.

[dagid4]

But I see you're using Radio Head instead?

I'm using lowcost MCU STM8S103F3P6. To make a smaller code, I've written my own very small library.

Maybe if you can try this with my library? You can write to registers directly.

I will try if I can get better results with your lib. Thank you.

[dagid4]

Unfortunately no luck getting RFM69 library to work on STM8:

I've installed:

• Arduino 1.8.19
• Sduino STM8 by Michael Mayer v0.5.0

Compiling:

Code Select Expand

#include <RFM69.h>

void setup() {
}
void loop() {
}

I got:

Arduino\libraries\RFM69\/RFM69_OTA.h:38:22: fatal error: SPIFlash.h: No such file or directory

Probably SPIFlash.h is not available for Sduino STM8

[Felix]

It's another library:
https://github.com/LowPowerLab/spiflash

[dagid4]

Is there any guide for installing? I've only found:

Library Installation (Arduino IDE)
Copy the content of this library in the "Arduino/libraries/RFM69" folder.
To find your Arduino folder go to File>Preferences in the Arduino IDE.
See this tutorial on Arduino libraries.

I must admit that I don't like Arduino. Especially solving library issues, like different compatible versions. I like to have things under my control.

Anyway, thanks for helping me. I have tried to add the SPIFlash library, but now I got:

sdcpp.exe: fatal error: when writing output to : Broken pipe
Arduino/libraries/RFM69_LowPowerLab/RFM69.h:186: syntax error: token -> 'RFM69' ; column 11
exit status 1

[dagid4]

Back to AES. I was wrong, it is not a constant delay.

I was incrementing the payload length 1,2,3,4,... and TX time was always same ~3,7ms. I was like, what the heck is going on? Then I incremented to 17 and now it was 5,8ms, for 33 it was 7,9ms, ...

Tx Processing
1. User enters the data to be transmitted in FIFO in Stdby/Sleep mode and gives the transmit command.
2. On Tx command the Packet handler state machine takes over the control and If encryption is enabled then the
message inside the FIFO is read in blocks of 16 bytes (padded with 0s if needed), encrypted and stored back to FIFO.
All this processing is done in Tx mode before enabling the packet handling state machine. Only the Message part of the
packet is encrypted and preamble, sync word, length byte, address byte and CRC are not encrypted.
3. Once the encryption is done the Packet handling state machine is enabled to transmit the data.

I know from datasheet that encryption/decryption works with 16 bytes block. But not a single word that you need to TRANSMIT the whole AES block. So, no matter what is your exact payload length, you will always transmit 16,32,48,64,...

This is very important, especially for low bitrates. Can anybody confirms that?

EDIT: My bad of not knowing how AES block encryption works. It needs to have the whole block to be able to decrypt it. So it's obvious, no need to mention it in datasheet.

[Felix]

Yes time increases for 16byte increments, exactly how the datasheet specifies.
The library is copy-paste in your Arduino/libraries folder. Or install it via the Tools > Library Manager, can't get any easier than that, search for SPIFlash_LowPowerLab.

[dagid4]

Yes time increases for 16byte increments, exactly how the datasheet specifies.

I disagree, but I won't argue. Maybe support your statement with quotation.

The library is copy-paste in your Arduino/libraries folder. Or install it via the Tools > Library Manager

I have already done exactly what you are saying (both way), got the error mentioned above.

can't get any easier than that

It can be easier, for example you should list all necessary libraries on https://github.com/LowPowerLab/RFM69.

How can a newcomer know they need this SPIFlash library if you don't mention it in the installation steps?

[Felix]

I will leave it to the datasheet - for such level of detail I will assume anyone would first consult the datasheet in depth.
My short answer is that it's clear from the datasheet that AES encryption will add delay for each additional 16byte block.

Somehow the library works for everyone else. I never had a complaint about installing difficulties. It is officially published with the Arduino Libraries repository, shows up in library manager and it's a 1 click install.

That documentation could me much better, I agree. But every sketch will list libraries and header files at the top, along with comments where to get the library, I believe that also is not too bad of a start:

For instance (from Node.ino):

Code Select Expand

#include <RFM69.h>         //get it here: https://www.github.com/lowpowerlab/rfm69
#include <RFM69_ATC.h>     //get it here: https://www.github.com/lowpowerlab/rfm69
#include <SPIFlash.h>      //get it here: https://www.github.com/lowpowerlab/spiflash

[dagid4]

I will leave it to the datasheet - for such level of detail I will assume anyone would first consult the datasheet in depth.

Now I think you don't even looked there to find out.

exactly how the datasheet specifies.

You shouldn't say it is exactly how the datasheet specifies, if you cannot say where.

Somehow the library works for everyone else. I never had a complaint about installing difficulties.

I think it could be related only to my STM8 board. Other boards maybe don't suffer with this issue.

That documentation could me much better, I agree. But every sketch will list libraries and header files at the top, along with comments where to get the library, I believe that also is not too bad of a start

I've tried TxRxBlinky.ino where the SPIFlash header is not present, but it is still required for compilation.

Anyway, it is a great work which you've made opensource and help many people to get it working. That counts

[Felix]

You could just remove the SPIFlash code if that is easier than installing the library .... 

RE the datasheet .... look in section "5.5.5 AES" it's literally specified right there, or do you want me to copy paste here to convince you? 
All you have to do is open the PDF ... search ... type "AES", 55 references found.

https://www.mouser.com/datasheet/2/761/sx1231h-1277666.pdf

[dagid4]

do you want me to copy paste here to convince you?

Yes, I want you to do exactly this Find me the sentence where it says:

time increases for 16byte increments, exactly how the datasheet specifies

I've read this section like 30x times, maybe you see something that I don't.

[sparky]

check out section 5.5.5.2

The encryption/decryption process takes approximately 7.0 us per 16-byte block. Thus for a maximum of 4 blocks (i.e. 64
bytes) it can take up to 28 us for completing the cryptographic operations.

[dagid4]

If you look at my first post, you will see that I quoted it But this is not the delay we are talking about.

EDIT: If you send 1B payload with encryption, it will take same time as if you send 16B without encryption. This is the delay we are talking about and it's not directly mentioned in datasheet.

EDIT2: With 1kbit/s bitrate, this is a delay of 120ms! Way more than 7us.