Encryption plan improvements

[jmgurney]

https://github.com/meshtastic/meshtastic/blob/master/docs/about/overview/encryption.mdx

For phase 1, I'd strongly suggest using AES-GCM-SIV (https://github.com/meshtastic/meshtastic/blob/master/docs/about/overview/encryption.mdx) , or another AEAD cipher (https://en.wikipedia.org/wiki/Authenticated_encryption#Authenticated_encryption_with_associated_data_(AEAD) ) that is more microcontroller friendly, such as Keccak (aka SHA-3, but it's more than just a hash). As someone else pointed out, CTR has no authentication, and is susceptible to bit flips. an authenticated cipher prevents this. It also means if a nonce is reused, message decryption can happen. The associated data can also be used to prevent impersonation attacks in that the encrypted message can be bound to the src/dst node id and replay attacks.

For phase 3, I'd suggest looking at Signal's protocol (https://en.wikipedia.org/wiki/Signal_Protocol ) for messaging, as it's an extremely well designed protocol that provides forward secrecy (prevent the decryption of past messages if the current key is compromised) along with other features.

[thebentern]

For phase 1, I'd strongly suggest using AES-GCM-SIV (https://github.com/meshtastic/meshtastic/blob/master/docs/about/overview/encryption.mdx) , or another AEAD cipher (https://en.wikipedia.org/wiki/Authenticated_encryption#Authenticated_encryption_with_associated_data_(AEAD) ) that is more microcontroller friendly, such as Keccak (aka SHA-3, but it's more than just a hash). As someone else pointed out, CTR has no authentication, and is susceptible to bit flips. an authenticated cipher prevents this. It also means if a nonce is reused, message decryption can happen. The associated data can also be used to prevent impersonation attacks in that the encrypted message can be bound to the src/dst node id and replay attacks.

Indeed, CTR is not the ideal mode of operation for AES. We're definitely amenable to implementing some alternative algos, as long as we can use them across platforms and they don't overly strain the lower power MCUs. 😄

For phase 3, I'd suggest looking at Signal's protocol (https://en.wikipedia.org/wiki/Signal_Protocol ) for messaging, as it's an extremely well designed protocol that provides forward secrecy (prevent the decryption of past messages if the current key is compromised) along with other features.

We've taken a stab at e2e encrpytion in the past (and I believe a group of students are still attempting this on a fork). The biggest challenge was always the limited resources available on the mcu, particularly as it relates to the node keeping a catalog of each other. In fact, we had to trim out a number of things and optimize to hit our theoretical limit of 80 nodes in the local database. Attempting to add required elements for a proper key exchange blew this out of the water. So having said all of that, we are very much interested in exploring the implementation of some of those concepts in the future. We just haven't quite figured out how to work it into the existing infrastructure without headache. I'd love to see somebody take another stab at it.

[jmgurney]

Indeed, CTR is not the ideal mode of operation for AES. We're definitely amenable to implementing some alternative algos, as long as we can use them across platforms and they don't overly strain the lower power MCUs. 😄

There are other better options than AES for MCUs like Keccak as I mentioned above. I'm familiar w/ limitations of MCUs and that doing Ed255 ops takes most of a second.

For phase 3, I'd suggest looking at Signal's protocol (https://en.wikipedia.org/wiki/Signal_Protocol ) for messaging, as it's an extremely well designed protocol that provides forward secrecy (prevent the decryption of past messages if the current key is compromised) along with other features.

We've taken a stab at e2e encrpytion in the past (and I believe a group of students are still attempting this on a fork). The biggest challenge was always the limited resources available on the mcu, particularly as it relates to the node keeping a catalog of each other. In fact, we had to trim out a number of things and optimize to hit our theoretical limit of 80 nodes in the local database. Attempting to add required elements for a proper key exchange blew this out of the water. So having said all of that, we are very much interested in exploring the implementation of some of those concepts in the future. We just haven't quite figured out how to work it into the existing infrastructure without headache. I'd love to see somebody take another stab at it.

Yeah, working w/ MCUs, flash storage is always going to be a limiting factor if the project want to support limited boards, but the total storage needed for each signal user is pretty low, 172 bytes core (https://www.signal.org/docs/specifications/doubleratchet/#state-variables) plus 68 bytes for each missed message.

[EternityForest]

What about using Libsodium? It seems to be just as trusted as AES, and specifically designed to be hard to mess up. It's got an authenticated mode too.

[RadioNur]

Yeah, working w/ MCUs, flash storage is always going to be a limiting factor if the project want to support limited boards, but the total storage needed for each signal user is pretty low, 172 bytes core (https://www.signal.org/docs/specifications/doubleratchet/#state-variables) plus 68 bytes for each missed message.

This is a bit aged but I'll jump in here anyway, in this scheme for the mesh do you foresee that authentication of the distant end is left out of band? Are you of the view that you could authenticate with an endpoint and that it doesn't matter that the endpoint is unauthenticated aside from the encryption being end to end?