Security audit of Reticulum+LXMF

[cannon-c]

I'm organizing a security audit of Reticulum+LXMF.

I am in contact with a company called Trail of Bits whom has expertise in conducting security audits of software, protocols, cryptography. Before proceeding, it would be good to understand what the community feels would have the biggest impact from a third-party security review.

1. If we had a third party review by an expert group such as Trail of Bits, what would be the most valuable thing they could help with?

2. Where would people in the community feel like Trail of Bits could help enhance security or make the development processes more secure and efficient?

3. Is it automated testing tools, formal verification, or something else that the community would find most useful?

Any other thoughts or suggestions?

My personal thoughts initially were to request:

• Audit of the cryptography implementation of Reticulum and LXMF
• Software security review of Reticulum, LXMF, NomadNet (emphasis on security from remote code exploits)

After having this extra input and answers to these questions from others, Trail of Bits would be happy to setup a call with the broader community to discuss the security review considerations and get feedback.

[cannon-c]

Let's use this page for discussing this topic. Please feel free to link to this and make mention of this in other places such as Reddit, Matrix, wherever else appropriate and to forward and consolidate comments from such into here.

[LoongUser77]

Hi,
Maybe this helps, I have run Bandit ([https://github.com/PyCQA/bandit]) over nomadnet code:
Bandit_in_Nomadnet.txt

It won't test crypto security, but just the code. But it could help

[cannon-c]

I was not aware of this Bandit tool, this is neat. While not a replacement of course for a manual and professional audit; this is still helpful for finding at least some potential issues. Thank you for sharing these results! This is helpful.

[silveroranges]

The things I would love to see audited is essentially your first thought, Reticulum, LXMF and how it implements the cryptography.

I don't know if this is in the scope of what they do, but also potential flaws that could lead to a DoS attack would also be good to know, in case a well funded group or state tries to block the network. I think this would be a good avenue of investigation because while jamming may work on one specific frequency or even a range of frequencies, the nature of reticulum and how it is able to communicate over any medium would mean the attack of choice would be something against the network specifically and not the transport medium.

[cannon-c]

You have a good point, as you do point out, a Reticulum network can overlap across many different mediums making a DoS attack at the software/protocol layer more widespread as a result. Especially since Reticulum is desirable as a solution for sovereign decentralized networks, availability is of high importance.

[bornac1]

You can always dinamically change the frequency by shifting it slightly to prevent jamming, but preventing DoS and DDoS is very hard. I would go in a direction of rate-limiting, but maybe something is even better...
Do you have any metrics for processing large number Reticulum packets? Did anybody test it on low-power hardware you are planning to use?

[LinuxinaBit]

You’re gonna want to get @markqvist ’s and @faragher ’s opinion on this, but I think you’re absolutely right about auditing the whole cryptography/identity system at least.
Probably gonna be hard to get them to audit the protocols themselves because I don’t think that’s what they specialize in, and I don’t think an audit of NomadNet specifically is that important (it’s just one of many LXMF clients), but I do think a general audit of the reference Reticulum and LXMF implementations is a good idea.

[LinuxinaBit]

The other thing to worry about is how much this would cost. I’m not terribly familiar with Trail of Bits and their pricing, but I don’t think it’s terribly wise to audit things other than the reference stack (Reticulum and LXMF) for now.

[bornac1]

The other thing to worry about is how much this would cost. I’m not terribly familiar with Trail of Bits and their pricing, but I don’t think it’s terribly wise to audit things other than the reference stack (Reticulum and LXMF) for now.

I don't know for Python, but for C# it starts from 5€ per one line of code for the agency I use. I managed to get lower price (can't say exact publicly) for my project because of MIT licence and my work (my company uses their service as well).

[markqvist]

Yes, as @LinuxinaBit says, the essential parts to get verified right now are the core workings of Reticulum itself, in order of priority:

• The core cryptography implementation (not the pure-python stuff for now, we still consider that highly experimental, and is only really there for the sake of experimentation and development)
• The core Identity implementation and Destination derivation from identity keys and destination aspects
• The cryptography involving the announce mechanism, and signature validation of received announces, plus mapping to valid destination paths
• Link establishment, link key exchange and encryption setup for links
• Ratchet distribution for ratchet-enabled destinations and per-packet ratchet-based encryption

In my personal opinion, those are the most relevant and valuable parts to get verified at this point. Once that is done, it would be interesting to start looking at higher-level protocols such as LXMF, but not before.

[bornac1]

@markqvist Finally you are discussing the idea that I suggested many months ago...

[markqvist]

I'm quite unsure what the point of your comment is here, and as such really have no way of answering it.

[bornac1]

I'm quite unsure what the point of your comment is here, and as such really have no way of answering it.

I mentioned this a long time ago while I was sending NoIPChat for certification and I didn't get any answer whether you would like me to send it as well or not. Also, Reticulum was updated too fast at that time and any certificate we would get would be for the outdated version.

[markqvist]

Reticulum was updated too fast at that time and any certificate we would get would be for the outdated version

Exactly.

[KenSamson]

I set up an lmxd instance... set it to announce.. then when it did announce I could see it in both MeshChat and NomadNet as clients, using a shared rnsd instance runng on the same machine.

I then sent it messages... looking to play around with storing messages on the server and writing a program to come retrieve them later. All experimental stuff. Just trying to learn.

in the .lxmd/storage/messages folder, a message got stored for each one I sent, in a separate file. All seems to be working just fine.

Then I opened one of the messages in notepad on windows... and the body of the message was stored in cleartext...

I was really hoping that the body of the message would have been encrypted in an lmxf message.. but maybe I have a lot more to learn.

It may be that because the server itself is the destination of these test messages (which really is a bit of an unusual circumstance), the server just happens to have the required keys handy and decrypts the message. I can think of several ways that could be useful where you could send the server commands because it would decode the messages. Would it not be useful to be able to use the network to send the routers instructions? (powerful and dangerous too, perhaps.)

To test end to end encryption, I would need to send the lxmd a message that is not "TO" the server itself. I'll work on that next, and see what the message looks like.

[markqvist]

I think you should post this in a new thread, since it is not relevant to the current subject of security auditing of Reticulum, but it is still relevant to an overall understanding of LXMF.

That being said, what you're seeing here is the correct and intended behaviour. As you say, you are sending LXMF messages to the lxmf.delivery endpoint of the LXMF instance you are running. The message gets decrypted and handled by whatever functionality you configure. If the final receiver of an LXMF message could not decrypt it and act on it, there would be no point of the protocol. The lxmd program can act both as a final receiver of LXMF messages, and as a propagation node for other instances.

If you enable the propagation node functionality of this instance in the LXMF config file, and send a message to another destination via this propagation node, it will of course be stored encrypted in the propagation message store. You can verify this for yourself.

[RFnexus]

Hi @cannon-c,

I visited the node you're hosting from the address in your Github profile and saw this:

Could I ask what this entails, and what the logistics are you have planned for fundraising? I think it is very important to be as transparent as possible with any sort of fundraising effort as this requires a large degree of trust between the organizer and the community. There are far too many bad actors out there when it comes too crowdfunding (see https://blog.thecrowdfundingformula.com/crowdfunding-scams/ for examples) and unfortunately I just don't think this approach is something that can be done realistically.

[cannon-c]

I agree that trust should be minimized. And I absolutely agree with the importance of transparency. This is a good place to start discussion on this as well.

"I just don't think this approach is something that can be done realistically." Do you mean the approach of crowdfunding as being unrealistic or something else?

What I have in mind was having funds raised from two ways. Applications submitted to various organizations that give funding and grants to open source projects, and also with a way for anyone to donate to go towards it also. Perhaps funding from such organizations can be released directly from the one or more pledgers to the company conducting the audit, after the total amount of pledges is sufficient to fund a the security audit. As for donations from people, perhaps a bitcoin wallet under the control of someone who has reputation and merit in this space (not me as I am new and not well known), a multisig would be better to eliminate a sincle point of failure and eliminate the need to trust a single person. Geyser Fund (https://geyser.fund) platform can be looked into (I am personally starting more research on Geyser Fund), or it can be as simple as a listed BTC address. While lightning transactions are great for micro-donations, onchain may be better suited for this since onchain addresses would support multisig and transparency of all donations. Something to think about, is what to do with the already donated funds in the BTC address if the targetted funding amount is not reached within the targetted timeframe. Would the funds just remain in that donation address allocated for the specific purpose (security audit) until one day when it is a sufficient amount to fund a security audit? Would the funds get refunded (minus the transaction fee) back to the sender after a certain time? Maybe instead of collecting donations from people, have people pledge what they'd be willing to donate and then start collecting donations after the pledged amount is sufficient? But if go that route with people then also need to think about how to prevent abuse of intentionally fake pledges.

Alternatively, if anyone knows how a proper security audit can be conducted without the need of funds (for free), please do share.

[cannon-c]

My personal suggestion would be grants from organizations paid directly to the company conducting such an audit conditionally if the audit is collectively fully funded within a declared timeframe; alongside a bitcoin multisig donation address collaboratively controlled by people with merit and reputation in this space; with donations refunded to senders (minus transaction fees) if funding is not reached in the same timeframe. Let's hear other thoughts.