Hello,
I'm fiddling with AES encryption for RFM69HCW. According to datasheet:
QuoteThe 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:
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
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 (https://lowpowerlab.com/shop/product/152)'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.
QuoteBut 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.
QuoteMaybe 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.
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:
#include <RFM69.h>
void setup() {
}
void loop() {
}I got:
QuoteArduino\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 :(
It's another library:
https://github.com/LowPowerLab/spiflash
Is there any guide for installing? I've only found:
QuoteLibrary 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:
Quotesdcpp.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
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, ...
QuoteTx 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.
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.
QuoteYes time increases for 16byte increments, exactly how the datasheet specifies.
I disagree, but I won't argue. Maybe support your statement with quotation.
QuoteThe 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.
Quotecan'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?
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 (https://github.com/LowPowerLab/RFM69/blob/master/Examples/Node/Node.ino)):
#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
QuoteI 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.
Quoteexactly how the datasheet specifies.
You shouldn't say it is exactly how the datasheet specifies, if you cannot say where.
QuoteSomehow 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.
QuoteThat 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 :)
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? ;D
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
Quotedo 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:
Quotetime 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.
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.
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.
Not with my library so I can't speak to that.
That AES encryption time of 1b == 16b is implied from the library.
QuoteNot with my library so I can't speak to that.
Yes, even with your library you cannot decrypt the message on the receiver side without the whole 16 byte block!
QuoteThat AES encryption time of 1b == 16b is implied from the library.
Your library is not a datasheet. So, please stop saying it's exactly how the datasheet specifies when it clearly doesn't mention it.
That's all I want, don't imply that I can't read a datasheet.
EDIT: Again, I'm not talking about encryption time. Encryption time is 7us per block and it is completely clear and exactly specified in datasheet. I'm talking about TRANSMISSION time. The delay is caused by TRANSMISSION, because for 1B message you still need to send 16B block and this is not clear from datasheet.
It obviously takes more time to modulate a longer message. Like speaking a longer sentence.
That has nothing to do with the encryption time X which is identical for each 1-to-16 byte block. You have to look at the packet engine not just encryption to fully understand the picture, hence I pointed you to the datasheet.
And since you're not using *THIS* RFM69 library, but another 3rd party library, I don't see how we can talk about any such delays or why you're seeing 120ms more that you expected. I'm trying to point you in the right direction.
QuoteI'm trying to point you in the right direction.
You are not even trying to understand what I'm talking about.
If you would try to send:
- 1B message with 1kbit/s and encryption disabled
- 1B message with 1kbit/s and encryption enabled
You would see the same 120ms delay, even with you library.
Quote from: dagid4 on March 24, 2023, 06:27:07 AM
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?
My 2 cents : your 5B unencrypted payload are encrypted in a 16B word, so your total of 10B without encryption becomes 21B with encryption, twice more bits, twice more time to be sent, I don't see any mystery.
The us delay are for decryption computation, not about the bandwidth (imagine sending at 512b/s, decryption will still take some us while the whole process will take much longer time just for the transmission part...)
From the datasheet, you can learn that encryption works with 16B packets, so if your packet is smaller, encryption will compute your payload into 16B packets, adding some bytes to your unencrypted payload. More bytes, more time to transmit depending on the bandwidth, unrelated to the decryption process.
Sorry if I misunderstood your request.
QuoteMy 2 cents : your 5B unencrypted payload are encrypted in a 16B word, so your total of 10B without encryption becomes 21B with encryption, twice more bits, twice more time to be sent
Finally someone who understand. You got it right. I wish you reply was first, then I would know immediately.
QuoteI don't see any mystery. ... From the datasheet, you can learn that encryption works with 16B packets
From datasheet I can learn that:
QuoteIf 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.
But not a single word that the whole 16 bytes block must be transmitted. That was the only mystery for me (see my comment (https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/aes-delay/msg29762/#msg29762)).
I thought that RF sends only part of the block (5B from example) and decrypts only the part (5B from example) of the block. But this is not how AES work.
It is obvious for someone who knows AES, but for me it was a strange delay.