Encrypt identity at rest

[konsumer]

I think it would be much better if the identity (files in PATH_IDENTITY & PATH_IDENTITY_BAK) on SD card were encrypted-at-rest.

• messages should be stored in original over-the-wire format, which is pretty safe (without plaintext identity)
• identity should be stored encrypted, with a password the user must type in on first use, so nothing can be spoofed or read when it's turned off, or if someone bad gets access to the SD card. After getting password, the identity key can be read into memory and should just work the same. Even if the user doesn't want to enter a password, it could still be stored, and all would work the same, but slightly better.

Here is a script for desktop to interop and arduino lib to encrypt/decrypt with password, in a reasonably safe way:

identity_file.zip

Also, sidenote, but we should work together on this stuff, if you're down. I made a bunch of stuff in this space, and I think we could make it all better if we team up.

Here are some related projects I made:

• reticulum-arduino - very light arduino-based protocol-only library
• rns-lite - light python reference-implementation for figuring out how to do things in other languages
• nomadnet-js - javascript client-lib for native & web
• signal-worker - a websocket server that runs on free CF workers (which works with native python clients and nomadnet-js)
• cyd-nomad - this is just the start of ideas, but I like ratdeck/ratcom better

My focus is light no-class setups that run on arduino/python/javascript (web & node.)

[defidude]

Hey @konsumer, apologies for the late reply here. To be completely honest, SD support was lazily added early on, and completely neglected, forgotten, and avoided up until now.

For no reason other than the fact that most people I spoke to were testing without an SD card, so I was mimicking that, and I got sidetracked working on the never-ending bugs/improvements.

That said, I agree, there should definitely be some encryption-at-rest on the SD card. I had talked about this in another chat just about the Ratdeck, but ultimately set it aside, as I think it's important and inevitable, but wasn't a top priority. I think I'll try to elevate it though and get it supported on both the Ratcom and the Ratdeck in the near future.

Re: working together on stuff, I'm always open to collaboration and building transparently as I try to do, but I find it hard to take the time and build in a truly shared team sense while things are moving so quickly. I'm always open to PRs, issues, and just general feedback/communication like you've given, either on GitHub or in our Telegram/Discord, and when things slow down in the future it will be easier to bring on contributors in a more official/serious sense if it's of any interest.

[konsumer]

I have been working on a new client that uses my arduino-lib, but I think you could still use that part here, if you want. Originally I made my own lib because I wanted to be able to test all the pieces independently, easier, and use different libraries for different parts of things (for example all the M5 libs make working on a cardputer or other M5 devices much simpler, or I might want to use it with other SD libs/storage-formats or whatever) but I am often like "maybe just using microreticulum here would be simpler here", so it's probably not better. The password stuff is sound, and there is a simple register/login flow example, on boot, and you could use a similar flow with microReticulum (but it might be complicated trying to use it with the built-in SD persistence stuff.)

The idea I am working with now is that it asks for a password to unlock the identity on boot, then uses the private identity as password for anything else that is secret (peers are fine plaintext, but all messages are encrypted.) The above idea was made very quickly with LLM, but I think it's over-complicated, and doesn't actually help that much.

A couple notes:

• over-the-wire format is fine for sent messages, since user has their own private-key, but since you don't have the other users private decrypt-key, you need a user-decryptable way to store it. In mine I use AES256, with 10,000 iterations, with the user's identity encrypt-key
• this is not specific to the SD, you can read plain-text secret-keys in flash almost as easily, but also the same techniques apply (password required at boot.) Also, the password serves to just keep unwanted people out of the device, even if it's just on flash (like I dropped my radio in a coffee shop.)
• I set the first byte to a known value, so I can quickly check if they got the password right. It's not infallible, but serves as a very quick check before loading identity. if they didn't get the password right, everything will still be garbled, even if they brute-forced a password that returns the correct 1st byte on the key-material. Update: in my PR to microreticulum, I dropped this, and use a full hash. it helps make it resistant to a lot more attacks.

I hear you on working together. It's especially hard in the LLM-age, where a better way might be to wipe old the old stuff (that other people are working on) and start over. We can just be like adjacent projects that help each other when it makes sense. Cross-testing would also be a good angle, like make sure yours works with mine, and vice-versa, and we can create 2 better, but independent clients. For testing protocol things, the simplified implementation stuff (arduino, js, python libs I made) have also helped a lot with figuring out how stuff works.

My next goal is getting everything working, in a functional client (my library works I think, but i need a UI for it, and it needs to be all connected to lora correctly) then on to direct UDP/TCP/websocket. I may just end up using microReticulum, too, and gutting the SD persistance stuff, since that seems to be the only real implementation-specific thing that blocks me.

[konsumer]

I made some improvements and added as PR to microreticulum, above. It is slower to initially verify password, but more resistant to attack and overall seems to work better.