Encrypting data in transport over ESP-NOW and LoRa

[generalmanager]

Have you given any thoughts on encrypting the data sent via LoRa and ESP-NOW?
Would you consider adding it, if it's not too complicated to implement and doesn't take up too much airtime & space?

I know ESP-NOW supports encryption, but only with 6 devices. And there seems to be little care given to some pretty serious flaws in the implementation, e.g this one or this other one.

As far as I'm aware, unlike LoRaWAN, LoRa itself doesn't support encryption out of the box and neither does radiolib.
So it'd seem to make more sense to encrypt and verify the data independent of transport mode. (This way one could even do it over serial, if someone really wants to.)

As usual in networking, encrypting stuff is easy, while deciding on how to manage and deploy the keys is a much bigger challenge.

I am aware there are lots of different approaches on how to implement something like this. Both in regard to key management / key exchange (shared keys / public-private key ) as well as to encryption ciphers and cipher modes.

But before going into too much detail on possible implementations, I'd like to hear your opinion on the topic in general. Should you already have some ideas, I'm all ears.

Key exchanges and some other parts of different protocols require two-way communication. But as far as I can tell, you're already working on that anyway. Also block cipher modes like AES use padding if the message is shorter than the block size, which increases the amount of packets sent via small frame protocols like LoRa.

Very generally speaking, the consensus currently tends towards forward secret AEAD algorithms combined with a good hashing algorithm and some nifty variation/combination of DH and other key exchange mechanisms.

There are several simple (and some not so simple) to use libraries, both fast regular ones as well as specifically for IoT applications.

Here is a good overview.

Some of the more famous ones are libhydrogen (made by the main author if libsodium aka NaCl) and TweetNaCl by Daniel J. Bernstein himself, but there are also monocypher (fast & compatible with libsodium but less known author without strong background in encryption) or the very interesting noise protocol framework

Others include Charm (example), Tiny-AES-c . bearssl has AES and other traditional crypto primitives. portable8439 is a cute little poly1305+chacha20 implementation. There are also BLINKER and the promising embeddeddisco which uses X25519 + STROBE.

One pretty nifty project I found is EnigmaIOT: overview technical details, which is specifically designed for use with ESP-NOW and LoRa on ESP8266 & ESP32 in mind.
At first glance, I'd say it seems quiet solid.

Also NIST just announced the Ascon cipher suite as the winner of their lightweight cryptography challenge. So that's supposed to become the de facto standard for low powered devices, as AES is for other scenarios. An RFC is already in the making.

https://www.nist.gov/news-events/news/2023/02/nist-selects-lightweight-cryptography-algorithms-protect-small-devices

https://csrc.nist.gov/projects/lightweight-cryptography

As this is pretty new, there are less ready made libraries and documentation, but luckily Rhys Weatherley (author of the noise reference implementation in C) has a plethora of useful information as well as implementations of tons of algorithms, including the contenders of the NIST Lightweight Cryptography challenge on his github:

Ascon Suite Arduino library
Ascon Suite documentation https://rweather.github.io/ascon-suite/index.html
ASM lib

LWC Finalists libraries & info:
great introduction
https://rweather.github.io/lwc-finalists/algorithms.html
https://rweather.github.io/lwc-finalists/index.html
https://github.com/rweather/lwc-finalists
https://rweather.github.io/lightweight-crypto/index.html#mainpage_arduino
https://rweather.github.io/lightweight-crypto/performance.html

His crypto library for arduino with lots of examples is tested on ESP8266 and he benchmarked lots of algos on ESP32:
documentation
https://rweather.github.io/arduinolibs/crypto.html
https://rweather.github.io/arduinolibs/crypto_esp.html

For what it's worth here are some interesting tidbits. Comments on Chacha/Poly vs the new hotness from LWC, even ESP32 is featured, Tesla build something highly similar to libhydrogen

PS: Sorry if this post seems a bit rough. I had already posted it, but the first one got lost as github decided to have a hiccup when I presed comment. So I lost an hour's worth of editing and had to recreate it from memory.

[timmbogner]

had to recreate it from memory.

Ooof I've been there and feel your pain. I appreciate you typing it back out because this is a huge wealth of information to me. I've said in the past that security will become a topic once controllers are implemented, and here we are.

I'll give an initial comment before diving in to your links:

First, I'm learning all of this as I go and am starting with practically zero knowledge of crypto. I'm going to study this information to give a better response about what is the best move here. The first thing that came to my mind was EnigmaIOT. I learned about this project after FDRS was somewhat developed, and I recognize it covers a lot of similar ground. It's clearly well done, but the crypto adds complication that I think turns away inexperienced users. My goal for FDRS is for a user to be able to use it very soon after learning to use Arduino.

So basically: I'm really supportive of adding a crypto layer, but it should be as unobtrusive as possible. From your overview, the Ascon suite sounds like it would be a good fit. It will be a bit before I'm personally able to make these changes (though I plan to start researching). I'm adding crypto to my list of things I want to do after the release is finished.

If you or anyone else is interested in trying to implement this on their own, I'll be happy to help in any way I can.