We Built a Signal Protocol Messenger. Then We Checked If It Was Legal in 5 Jurisdictions.
TL;DR: We checked Halonyx - our self-hosted E2EE messenger implementing X3DH + Double Ratchet - against the EU's Chat Control, US EARN IT Act, India's IT Rules 2021, the UK's Online Safety Act + Investigatory Powers Act, and the UN Cybercrime Convention. Here's the honest answer for each.
When you implement end-to-end encryption from scratch, you spend a lot of time thinking about cryptographic threat models. Key substitution attacks. OPK exhaustion. WebRTC IP leakage. The adversaries you model are largely technical. At some point, you have to model a different kind of adversary: the legal one.
We built Halonyx - a self-hostable E2EE messenger implementing the Signal Protocol (X3DH key exchange, Double Ratchet, Safety Numbers, WebTorrent P2P file transfer). The server architecturally cannot read your messages - not by policy, but because it holds no decryption keys and no plaintext. We wrote a STRIDE threat model across 17 attack surfaces. We did not write a legal threat model. So we did.
This is what we found across five jurisdictions. None of this is legal advice. All of it is current as of July 2026, in a policy landscape that is actively moving.
Quick Architecture Recap
Before the jurisdiction breakdown, a one-paragraph recap of what Halonyx actually does, because the architecture is what determines the legal exposure.
The relay server stores and forwards only AES-256-GCM ciphertext. It holds no private keys, performs no cryptographic operations on behalf of users, and has no mechanism to identify message content or originators. User identity is a pseudonymous 256-bit USID - the server stores only SHA-256(USID). Files transfer peer-to-peer via WebTorrent; the server receives only a magnet URI. This architecture - which we call Federated Relay Architecture (FRA) - is what creates the legal situation described below.
1. European Union - Chat Control / CSAR
Current status: No conflict with anything currently in force.
The EU's Child Sexual Abuse Regulation (CSAR), known as "Chat Control," has been in negotiation since 2022 and has generated more alarming headlines than almost any other encryption policy debate. The current actual situation as of mid-2026:
- The original mandatory client-side scanning demand was dropped by the Council in late 2025.
- A temporary voluntary-scanning derogation expired April 2026; a July 2026 extension vote survived but with an amendment explicitly excluding E2EE communications from its scope.
- The permanent regulation is still in trilogue negotiation - open questions remain on age verification and "risk-mitigation" design obligations.
Halonyx position: No conflict with anything currently in force. We have no scanning mechanism - there is nothing to exclude, because the server never accesses plaintext. Age verification is an open gap if it becomes a firm legal requirement; we do not implement it. The permanent regulation's "risk-mitigation" obligations are not yet defined clearly enough to assess against. The EU is trending away from mandatory scanning of E2EE services, not toward it, as of this writing.
2. United States - EARN IT Act + PQC Executive Order
Current status: No enacted law. Two tracks pulling in opposite directions.
Two separate policy threads run in parallel in the US and almost never get discussed together:
- EARN IT Act (not enacted as of mid-2026): Would condition Section 230 liability protection on compliance with "best practices" set by a government-influenced commission. Critics including EFF, ACLU, and cryptographer Matthew Green argue this creates indirect pressure toward backdoors or scanning without explicitly mandating either. It has not passed in multiple Congressional sessions.
- 2026 PQC Executive Order (enacted): Directs federal agencies and contractors to complete a transition to post-quantum cryptography by December 31, 2030. NIST, NSA, and CISA are leading standards work. This is a cryptographic strengthening mandate - the opposite direction from EARN IT.
Halonyx position: No current compliance obligation. The PQC gap is real - we use classical curves (X25519, P-256, Ed25519), the same as Signal's current production design. CRYSTALS-Dilithium and Kyber integration is on our roadmap. The 2030 deadline applies to federal contractors, not to us at current stage.
The important framing: the largest federal cryptographic initiative currently running in the US points toward stronger encryption, not backdoored encryption. The coverage of the US encryption landscape that focuses only on EARN IT misses this.
3. India - IT Rules 2021, Rule 4(2) Traceability
Current status: In force, litigated, and in direct structural tension with strict E2EE.
This is the only jurisdiction in this survey where there is a currently-in-force legal rule in genuine conflict with how Halonyx works. IT Rules 2021, Rule 4(2) requires "significant social media intermediaries" (5M+ users) offering messaging to identify the "first originator" of a message within India upon a valid judicial or law enforcement order for specified serious offences.
WhatsApp challenged this in the Delhi High Court, arguing traceability is technically impossible without retaining data that breaks E2EE guarantees. Signal's founder has publicly stated the two are architecturally incompatible. The government's FAQ insists the intent is not to break encryption while declining to specify a technical implementation that wouldn't. The litigation remains unresolved.
Halonyx position: Technically not applicable at current scale - we are nowhere near 5 million users. But architecturally, Halonyx is on the same side of this argument as WhatsApp and Signal, for the same structural reason: a server holding only SHA-256(USID) and AES-256-GCM ciphertext has no mechanism to identify a message originator even if legally compelled. The architecture produces the same "traceability is architecturally impossible" conclusion independently of our intent. This is the jurisdiction to watch most carefully if Halonyx ever scales.
4. United Kingdom - Online Safety Act 2023 + Investigatory Powers Act 2016
Current status: The clearest existing enforcement mechanism in this survey, already reportedly used once.
The UK runs two parallel legal mechanisms:
- Online Safety Act 2023 (OSA): Empowers Ofcom to require "accredited technology" - including client-side scanning - on encrypted services. No accredited technology currently exists. Ofcom's final implementation guidance was expected in spring 2026; enforcement has not yet been technically deployed against any service.
- Investigatory Powers Act 2016 (IPA): Allows the Home Secretary to issue secret Technical Capability Notices (TCNs) compelling companies to remove "electronic protection." This mechanism was reportedly used against Apple's iCloud Advanced Data Protection in 2025. Apple withdrew the feature for UK users rather than complying. The matter is before the Investigatory Powers Tribunal. Signal has published that it would exit the UK market before implementing client-side scanning. This is not rhetorical - it is a statement about architectural limits.
Halonyx position: Less likely to attract TCN-level attention than Apple, for obvious scale reasons. But not architecturally exempt. A legal order compelling a client-side change would bind Halonyx's maintainers the same way it bound Apple's - structural difficulty does not constitute a legal defence.
What the architecture does provide: the non-exportable CryptoKey design and server-side blindness mean silent server-side compliance is structurally impossible. Any compliance would require a visible, explicit change to the client codebase - which, for an open-source AGPL-3.0 project, would be publicly observable.
The OSA is the more concerning long-term mechanism because it applies to encrypted services broadly, not just major providers. The accredited technology question - what would even satisfy Ofcom's requirement - remains technically unresolved.
5. UN Convention Against Cybercrime
Current status: Not yet in force anywhere. Monitor, don't act yet.
The UN Convention against Cybercrime was adopted by the General Assembly in December 2024 and opened for signature in October 2025. It requires 40 ratifications to enter into force. As of mid-2026, 72+ countries have signed - but signature creates no binding obligations. The ratification count remains short of 40. The US has not signed. India has not signed.
Article 28.4 is the provision privacy organisations (EFF, Internet Society, Privacy International) are watching: it could be read to permit domestic authorities to compel handover of encryption keys or other information defeating security measures during search and seizure, with safeguards left to domestic law rather than specified in the treaty.
Halonyx position: Not applicable anywhere currently. Even once in force, the treaty creates no direct obligations on services - it directs states to legislate domestically. The eventual effect flows through whichever of the four national regimes above choose to ratify and implement Article 28.4, not through the treaty text directly.
The Cross-Jurisdiction Picture
| Jurisdiction | Mandates breaking E2EE? | Currently enforced? |
|---|---|---|
| EU (CSAR) | No (E2EE excluded) | No |
| US (EARN IT) | Not enacted | No |
| India (IT Rules) | Effectively yes (argued) | Contested in court |
| UK (OSA + IPA) | IPA: yes (Apple case) | IPA: reportedly yes |
| OSA: power exists | OSA: not yet | |
| UN Convention | Ambiguous | Not in force |
The Architectural Observation That Matters More Than the Jurisdiction Table
Every mechanism reviewed here - client-side scanning, traceability, TCNs, and the UN treaty's compelled-key-handover language - works by compelling change at the client or at the point of key exchange. A server that holds no plaintext and no decryption keys cannot be secretly compelled to hand over content it does not possess.
This is what Halonyx's Federated Relay Architecture produces: silent server-side compliance is structurally impossible, because there is nothing to silently comply with.
This is not a legal shield. A government order compelling a client-side change would still bind us. What the architecture guarantees is that such compliance could not happen silently - it would require a visible, explicit change to an open-source codebase that anyone can audit. Transparency as an architectural property, not just a policy aspiration.
What We Are Watching
Three things we are tracking as they develop:
- EU trilogue conclusion - the permanent CSAR regulation will define whether "risk-mitigation obligations" mean anything concrete for E2EE services. The current direction is encouraging but not settled.
- India High Court ruling - the Delhi High Court decision on Rule 4(2) will either validate or reject the "traceability is architecturally incompatible with E2EE" argument at a judicial level. This will have implications beyond India.
- UK OSA accredited technology - whether Ofcom ever identifies technology that satisfies the OSA scanning requirement without breaking E2EE. The cryptographic community's consensus is that no such technology exists. If Ofcom concludes the same, the OSA's bite on E2EE services diminishes significantly.
Conclusion
Halonyx is not in conflict with any currently-enforced law in the EU or US. It has no live compliance obligation in India or the UK today, primarily because its scale and non-commercial status place it outside the practical reach of existing mechanisms - not because its architecture has been tested against them at scale.
The global regulatory direction is not uniformly toward weaker encryption. The largest cryptographic initiative currently running in the US points toward stronger algorithms. The EU has, for now, excluded E2EE from scanning scope. The most aggressive enforced mechanism (UK IPA) has produced market exit rather than compliance from a major provider.
The picture is messier and more contested than either "encryption is under attack" or "encryption is safe" captures.
Full technical writeup on how Halonyx works: I Built a Signal Protocol Messenger from Scratch (placeholder - actual link not provided in original)
GitHub: github.com/ABHIRAM-CREATOR06/Halonyx (AGPL-3.0)
This article reflects public reporting as of July 2026. Not legal advice. The policy landscape is actively moving.
Comments
No comments yet. Start the discussion.