RFM69
RFM69 copied to clipboard
LowPowerLab
Should enable Whitening by default
Lost two days debugging my application of sending 41 bytes every 33ms with no ACK. Was getting high packet loss. Forum member finally had me enable whitening with
RF_PACKET1_DCFREE_WHITENING
and problems went away. Why not have this on by default? Is there a drawback to enabling whitening all the time?
Might consider using WHITENING by default at some point but it will require some testing and vetting. I was hesitant to do this because of all the people having lots of deployed nodes that do not use that setting and it's not evident that it was changed, especially if they miss a press release.
I have a feeling most people are using your boards/library to send sensor data or commands which will probably always be non-zero. I was using them for a DMX interface for theatrical lighting control, which must be able to tolerate all channels at 0. Radios were terrible during this case, 50-80% packet loss at 6" until whitening was enabled.
So at the very least, so something positive comes out of my days wasted, maybe an exposed function to enable whitening and a note in the example sketches about having to enable it if most of the paylooad is all 0x00s or 0xFF?
Thank you for your feedback about your packet loss, it's certainly very valuable and I will surely look into making this change. FWIW Usually packets have data which is not DC characterized. It's not unusual to have some bytes that resemble DC but it's not common. Either way WHITENING should probably be implemented asap.
A remark about whitening: if AES encryption is enabled, there is a good chance that whitening isn't needed as the encrypted bit-stream should be pseudo-random.
@madsci1016: when you experienced the packet loss, did you have AES encryption enabled?
Is the whitening semi-standardized across modules from different manufacturers? It looks like several other radios are very similar in the RF data formats they use, keeping compatibility is always nice.
I'm using Golay error correcting encoding and ChaCha encryption, both of which add whitening for free.
Is there any interest in eventually just adding a more comprehensive data format with support for authentication, replay attacks, etc, rather than just making a breaking change to existing work?
IMO at the very least encryption should be enabled which will scramble the payload. Authentication and replay attacks should be implemented in the application layer and so are beyond the scope of this library.
I'm not quite so sure about the default hardware encryption, IIRC it's the (Not really used anymore) electronic codebook mode, which isn't that secure, and I don't think it gives you any kind of authentication (Which is one of tbe main purposes for encryption for a lot of embedded applications).
I think it also pads messages to multiples of 16, if it really is ECB. Seems kinda yucky in general.
On Tue, Jun 23, 2020, 3:14 PM Felix Rusu [email protected] wrote:
IMO at the very least encryption should be enabled which will scramble the payload. Authentication and replay attacks should be implemented in the application layer and so are beyond the scope of this library.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LowPowerLab/RFM69/issues/70#issuecomment-648456092, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFZCHZIPRB57KW3DGPCTTLRYESLNANCNFSM4DGCPBZQ .
@EternityForest - I suggest opening the datasheet, it can be very enlightening. The encryption is AES128, not ECB. Also, in computer security, encryption is NOT the same as authentication. They are very different things with very distinct purposes
The datasheet says AES but doesn't seem to even mention what mode the cipher is used in. Some forum posts say ECB, but the lack of ability to use it on the fly might imply CBC.
Either way, if it's unspecified, that seems like a problem in and of itself, and if it is CBC you would still need a random IV, or else the same packet would encrypt to the same ciphertext every time, which is undesirable.
On Thu, Jun 25, 2020, 6:24 AM Felix Rusu [email protected] wrote:
@EternityForest https://github.com/EternityForest - I suggest opening the datasheet, it can be very enlightening. The encryption is AES128, not ECB. Also, in computer security, encryption is NOT the same as authentication. They are very different things with very distinct purposes
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LowPowerLab/RFM69/issues/70#issuecomment-649538865, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFZCH7SPYNKKWO4ZJMOJD3RYNFZBANCNFSM4DGCPBZQ .