Security Issue: Link establishment flaw discovered and addressed

[markqvist]

Important!
For all Reticulum versions up until and including 0.3.11 based on elliptic curve cryptography, a rather serious security flaw has existed. An error in the link establishment key exchange handshake has meant that all links, while still being secure and encrypted, have not been able to provide perfect forward secrecy. Let's explore what this means in practical terms.

What does this mean?
We will imagine an attacker that has been monitoring the traffic of Alice, and recording it all. At this point in time, all traffic is still private and secure. The flaw does not affect the security of exchanged data, or provide any elevated risk of the attacker gaining access to neither ephemeral, nor long-term Identity keys. The flaw is only exploitable if the attacker obtains the primary Identity Keys from Alices device, for example by gaining physical access to the device.

• If an attacker somehow obtained the link-specific ephemeral key for an established link, the attacker will still only be able to decrypt data from that link.
• If an attacker is able to obtain the RNS Identity key data that Alice used to create destinations that were linked to, for example by physically stealing Alices device, and exfiltrating the key data, the attacker will be able to decrypt previously recorded link data.

This is obviously not the intended behaviour, and quite severe. The flaw is already adressed in 8886ed5, and will be published as release version 0.3.12 shortly.

How can this be mitigated for existing users?
The best mitigation path is to update to RNS 0.3.12 when it becomes available shortly. The fixed version is already available in the master branch. Updating to 0.3.12 will intentionally break backwards compatibility with all previous versions.

If you have exchanged sensitive data that you are paranoid about being discovered in the future, I will recommend completely deleting any key data that was associated with the transfer of that information. If an attacker does not hold the primary Identity keys, the data is still secure.

Personal Notes
I am truly quite sorry that I managed to plonk this one into Reticulum when I switched everything to EC. It just goes to show that it's important to not even trust yourself, and that you have to re-challenge everything previously written as often as possible.

I hope it can be a redeeming factor that I actually try to do this persistently, and that this flaw was discovered while still in beta.

I will of course answer any questions about this issue here, so bring it on if there is anything on your mind or you have any doubts!

[4c3e]

Thanks for disclosing and working on a fix, this is why beta software is beta 😄

One resource that might be useful before publishing the 1.0 version of Reticulum is looking into pro bono security audits like LeastAuthority's offerings: https://leastauthority.com/pro-bono-security-consulting/

Always good to have as many eyes as possible on a project's cryptography!

[markqvist]

this is why beta software is beta 😄

Yeah, exactly, but oh man does it sting sometimes as well when stuff like this happens ;) Good thing it is fixed now. I should have the release ready very soon.

I had no idea about the existence of that offering. How awesome. And Reticulum looks to check all the boxes regarding their criteria. I will probably submit an application with them when the time comes. Thanks for sharing it!