software AES encryption for NRF24

[FotoFieber]

I have tried a different setups now

• Arduino Mega2560, Arduino Uno
• different NRF modules from different vendors, with and withoud amplifier, with different capacitors
• different power supplies

I always end up getting st-fail, even with encryption only. But it is working even with these fails... :smile:

@Anticimex
You have a working setup with encrpytion and the actual libraries from github without st-fail?

Next tests:

• change NRF and power supply on the gateway
• and if all that doesn't help: make a setup without encryption

[Anticimex]

@FotoFieber No, I have no set up at all for the moment. But I have been using both encryption and signing yes. And I can tell you again (and again and again) that st=fails has nothing to do with signing or encryption. Unless you don't use the same AES key for your nodes because if the message is encrypted, it is jibberish to the receiver and NRF does not natively support encryption so I don't thinnk it will be able to ack properly. I trust you are sure you have your keys properly configured per the instructions for version 2.0.0?

[FotoFieber]

@Anticimex
I have a very reduced sketch now (sending millis() every second) and yes, I have configured the keys as it should be.

As long, as nobody can prove with a concrete setup, that with the actual git-version (with encryption and NRF24L01) it is working without st-fail, the possibility exists, that it there is a bug. :smile:

[Anticimex]

@FotoFieber No. At least not for signing. As st=fail is something set by the transport/radio layer and signing has nothing to do with that. Encryption I discourage from using (detailed in the documentation) since it provides little benefit in the form used here.

[FotoFieber]

@Anticimex
As the bug is there even with encryption only, it can't be in the signing code.

For privacy concerns, signing is no solution.

[Anticimex]

@FotoFieber Neither is encryption for NRF24 as it does not use IV:s. And the data you encrypt is predicable so the key can be derived quite easily, effectively eliminating the "protection" the encryption is supposed to give.

[FotoFieber]

@Anticimex
No IV? Then the AES Transport implementation is not secure, more ore less an obfuscation...

Is this a known bug, that will be fixed?

[Anticimex]

@FotoFieber it is a known limitation and is currently not in scope for improvement for nrf24 because it require reliable sync which nrf radios are notoriously bad at providing. If you have an idea on how to fix it, a pr is always welcome :)

[FotoFieber]

Hm, I am not an encryption expert. What about a Diffie-Hellmann key exchange and then use the key as IV?

[Anticimex]

Me neither. I care about security, not obscurity. I see no reason to encrypt a '1' or a '0' and digital streams like audio and video is not supported anyway. But exchange of constant (but random) data is already used and supported since signing is based on nonce exchange. But I believe IV:s "evolve" with the messages encrypted which implies the messages need to be exchanged trustworthy and sender and receiver need to be om sync. But I know to little about that to be sure.
In any case, I welcome any development that adds to security, and will happily review such code, but I don't have the bandwidth nor motivation to "drive" the development of encryption in the core library as I don't feel it adds enough value to be worth the effort.