◈ 9ce92808be498e9e05590ff27cbfdfe4
RNS 1.4.2 released https://pypi.org/project/rns/
Forum / General / Post-quantum encryption on RNS

Post-quantum encryption on RNS

Started by pcarr ·

edited

Recently there's been some discussion about fast timelines for cryptographically-relevant quantum computing.

Since Reticulum currently relies on non-quantum-safe asymmetric cryptography, I was wondering whether anyone has considered a timeline for migrating to quantum-safe crypto.

It seems like there would have to be a transition period where every node has two identities, the existing non-quantum-safe one and a quantum-safe one, that are linked together somehow. If a connection can be routed entirely through nodes that support post-quantum encryption, it is upgraded to use everyone's post-quantum identities.

Once some adoption threshold is met, the non-quantum-safe identities could be phased out. This could even be done node-by-node, eg when 90% of the traffic through a node is using post-quantum encryption, it deprecates its non-quantum-safe identity.

I am not very well-educated on this subject myself -- mostly just opening the floor for discussion. I expect that there would be a significant bandwidth and compute-time tradeoff, since all current PQE algorithms are significantly slower and require larger keys than ed25519. However, this tradeoff may be worth it to ensure that Reticulum remains secure over the next few years.

Anonymous

I am wondering is there a post quantum cryptography that actually has the neede functionality.

hardened_malloc 1984c4b048aecbf9...

pcarr wrote:

Recently there's been some discussion about fast timelines for cryptographically-relevant quantum computing.

Since Reticulum currently relies on non-quantum-safe asymmetric cryptography, I was wondering whether anyone has considered a timeline for migrating to quantum-safe crypto.

It seems like there would have to be a transition period where every node has two identities, the existing non-quantum-safe one and a quantum-safe one, that are linked together somehow. If a connection can be routed entirely through nodes that support post-quantum encryption, it is upgraded to use everyone's post-quantum identities.

Once some adoption threshold is met, the non-quantum-safe identities could be phased out. This could even be done node-by-node, eg when 90% of the traffic through a node is using post-quantum encryption, it deprecates its non-quantum-safe identity.

I am not very well-educated on this subject myself -- mostly just opening the floor for discussion. I expect that there would be a significant bandwidth and compute-time tradeoff, since all current PQE algorithms are significantly slower and require larger keys than ed25519. However, this tradeoff may be worth it to ensure that Reticulum remains secure over the next few years.

In my opinion the best approach would probably be a layered encryption scheme, although it would come at the cost of increased bandwidth usage, and higher computational overhead. It also avoids placing all trust in relatively new post-quantum algorithms from the outset while preserving compatibility between older and newer nodes. Additionally, if a weakness were later discovered in the post-quantum algorithm, the existing classical security layer could still provide a degree of protection rather than relying solely on the new scheme.

The general idea would be to establish a connection using the existing protocol, then, if both peers advertise post-quantum support, negotiate a post-quantum-secured channel within that connection and migrate subsequent traffic to it. This would allow older nodes to continue operating unchanged while newer nodes gain post-quantum protection whenever both ends support it.

I’m approaching this from an engineering standpoint rather than a cryptographic one, so this is more about practical system design than formal security modeling.

edited

hardened_malloc wrote:

In my opinion the best approach would probably be a layered encryption scheme, although it would come at the cost of increased bandwidth usage, and higher computational overhead.

This is probably makes the most sense, we would just default to assuming all reticulum packets are unencrypted and transparent and then make a protocol ontop of it to actually encrypt, in the same way we made HTTPS from HTTP. We still get all the nice routing from reticulum which is what matters more. Even in this case we can make the assume that 99% of traffic probably wouldn't get compromised and read because the quantum computers capable doing this attack would likely be rare and or slow, and decrypting all traffic would be impractical.

In the scenario where everyone magically gets a device capable of breaking encryption and owns a quantum phone, we'd need entirely new protocols anyways for sending quantum data and that scenario is so far in the future that it just doesn't matter because we cannot possible prepare for it.

I will note that any future reticulum-like protocol that is incompatible with the current spec could use the existing reticulum network itself as an interface to bootstrap itself in the same way that reticulum uses the regular internet to bootstrap itself for adoption, so breaking changes are slightly less of a big deal than with other protocols. Infact it's even less a big deal than the would-be transition from the current internet to reticulum as a future implementations could still bridge distant reticulum nodes together using their newer protocol allowing old reticulum code to work while currently there's no possibilities of normal internet traffic routing through reticulum.

pla55 fbe1cb380f6bd761...

Mark's thoughts on PQ-crypto (from 2023): https://github.com/markqvist/Reticulum/discussions/181

Just thought I'd leave it here for context, not sure if the situation has changed and there's some proven safe algorithm now but I'm still going to assume it's not a priority yet.

Post a Reply

Markdown

Supports Markdown: **bold**, *italic*, `code`, ```code blocks```, [links](url)

Log in to upload images

Proof of work verification for anonymous posting

Copied to clipboard