software AES encryption for NRF24

[Anticimex]

Not sure if it is a typo or now but you list
#define MY_SIGNING_ASOFT but it should be #define MY_SIGNING_SOFT

In any case, you get st=fail which mean your radio setup is basically not working.
For any security to work, messages has to get through, and from your log, they don't:
"Failed to transmit signing presentation!"
"Failed to transmit nonce request!"
So I think from the log that signing and encryption is working, but occasionally you get messages dropped due to a poor radio link which manifests itself as failed transmissions.

[lyndaeldo]

If implemented correctly, AES is AES; the output between two different implementations is identical, and therefore no distinction is possible in after-the-fact comparison -- if done correctly, the one is exactly the same as the other.

But there are a few points where differences can crop in:

Operation Mode
Truecrypt implements a modified counter mode called XTS. It's pretty well vetted and has withstood some serious abuse from some powerful attackers (such as the US Government).

From examining the p7zip source code, it appears that AES encoding for the 7-zip format operates in CBC mode. This is certainly not necessarily insecure; it's the mode most popularly used in protocols such as TLS, but it is potentially vulnerable to padding oracle attacks. See this discussion on operation modes for more information.

Key Derivation
Truecrypt uses PBKDF2 to turn your password into an encryption key. It's difficult to come up with a better alternative than that. p7zip uses a salted SHA256 hash repeated over a configurable number of iterations. PBKDF2 is a bit more configurable, but 7-zip's alternative is functionally similar and arguably reaches the same goals.

[FotoFieber]

@Anticimex
Sorry for the typo.

Interestingly, the sketch is working perfect without signing.

I will try to add another power source and try again.

Do you have a working setup with encryption and signing?

[Anticimex]

@FotoFieber When you use signing, the max message size is used, and this strains the rf link the most. Signing is still not your problem. It is clear from the log that messages fail to transmit, and that is a radio problem.

[alexsh1]

@Anticimex @FotoFieber

We have been through this a few times. Just a suggestion - shall we do an FAQ link explaining what you have just said (st=fail is a problem of radio and not singing). Ingerestingly enough I did not manage to resolve this issue with the Sensebender. I still get several fail to transmit nonce before it starts working fine. Only the Sensebender. All other nodes work flawlessly

[Anticimex]

@alexsh1 It is already documented where all signing is documented:
https://ci.mysensors.org/job/Verifiers/job/MySensorsArduino/branch/master/Doxygen_HTML/group__MySigninggrp.html

Check the troubleshooting section for details. Link to all documentation is on the github frontpage and on the "head" post of the signing topic on this forum.

[alexsh1]

@Anticimex OK, that's super. I think we all became victims of nrf24l01+ terrible fake copies. Some of these work OK until....
Then a woodoo dance has to be performed (highly recommended) in order to make them work again.

[Anticimex]

@alexsh1 Don't forget the goat sacrifice

[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.