Encryption
Typology
Ken Macon:
"The term “encryption” is often used broadly, but in the realm of private messaging services, it usually implies a specific standard: default end-to-end encryption.
There are Two Main Types of Encryption:
Non-End-to-End Encryption (Cloud Encryption)
"In non-end-to-end encryption, messages are encrypted by the sender, but the encryption keys needed to decrypt the messages are accessible to the service provider. This means that while the messages are protected during transmission (over the internet), once they reach the service provider’s servers, the provider can decrypt and access the content of the messages. This setup is common in services where the provider might need to access message content for various reasons, such as indexing for search, applying spam filters, or complying with legal requests.
For example, Gmail uses this type of encryption. When you send an email via Gmail, it is encrypted during transit, ensuring that interceptors cannot read it. However, once your email reaches Google’s servers, Google has the capability to decrypt the emails. This is because Google controls the encryption keys. This capability allows Google to scan emails for spam and malware, provide search functionality across your emails, and comply with legal demands such as subpoenas or warrants that require access to email content.
End-to-end Encryption
"Conversely, with end-to-end encryption, the data (such as messages or calls) are encrypted on the sender’s device and only the intended recipient has the key to decrypt it. This means no intermediary, not even the service provider, has access to the encryption keys necessary to decrypt the data. The message stays encrypted throughout its journey from sender to receiver, becoming readable only when it reaches its intended destination.
When you send a message via these platforms, nobody besides you and the recipient—not even the companies running these services—can read what’s sent. This secures your communication against both cyber threats and any potential surveillance from service providers or government authorities, making it a stronger option for protecting privacy.
...
For simplicity’s sake, there are two basic forms of end-to-end encryption – open source, and closed source.
Open Source Encryption
"Open-source encryption is widely regarded by cybersecurity experts as one of the most secure methods of encryption. This preference is rooted in the transparency and community scrutiny that open-source projects afford. When encryption software is open source, its source code is publicly available, allowing anyone to examine how the software functions and verify the security of its encryption methods.
Transparency and Security Audits: One of the primary advantages of open-source encryption is the level of transparency it provides. Since the source code is accessible to all, independent security experts, researchers, and developers can scrutinize it for vulnerabilities, flaws, or backdoors. This continuous and open vetting process tends to result in more secure software, as issues are identified and, in theory, patched more quickly compared to proprietary software, where the code is only accessible to the company’s internal team.
Community Collaboration: Open source projects benefit from the collective expertise of a global community. Developers from around the world can contribute to the project, enhancing the software with new features, security enhancements, and fixes. This collaborative approach not only speeds up the development and fortification of the software but also fosters innovation within the field of encryption.
Building Trust Through Transparency: For encryption software, trust is paramount. Users need to trust that the software will protect their data as claimed. Open-source encryption builds trust through its transparency—users don’t need to rely on the security claims of a vendor; they can see for themselves or rely on the assessment of independent experts who have reviewed the code.
Closed-Source Encryption
Most experts caution against the use of closed-source encryption due to its lack of transparency, which can obscure potential vulnerabilities and limit external verification. Unlike open-source encryption, where the code is available for public review, closed-source encryption keeps its operational code hidden, restricting the assessment of its security to the internal teams of the company that owns it. This secrecy can prevent independent security experts from conducting thorough audits, making it harder to trust the encryption’s robustness. Additionally, without external scrutiny, it’s more challenging to identify and rectify security flaws, which could potentially leave user data at risk of unauthorized access or breaches.
When using closed-source encryption, requires more trust as the claims about the degree to which communications are encrypted can’t be independently verified."
(https://reclaimthenet.org/is-telegram-encrypted)
Example
- Telegram analyzed: https://reclaimthenet.org/is-telegram-encrypted
Discussion
Encryption as Gravity: Reticulum
The Zen of Reticulum:
"If we accept that there is no center - that the network is a chaotic, peer-to-peer mesh - we are forced to confront a terrifying reality: There is no one guarding the door.
In the traditional networking mindset, we rely on the concept of the “trusted core”. We assume our local coffee shop WiFi is safe, or that the backbone providers are neutral custodians. We build our security like a castle: strong walls on the outside, soft and trusting on the inside. We use encryption only when we step out into the “wild” internet.
- Hostile Environments
The Zen of Reticulum requires you to invert this. You must assume that every environment is hostile. This isn’t cynicism, just uncaring physics.
When you transmit information over radio waves, you are shouting into a crowded room. Anyone can listen. When you traverse the internet, your packets pass through routers controlled by strangers, corporations, and state actors. Assuming privacy in this environment without cryptographic protection is not optimism but gross negligence.
Reticulum is built on the premise that every link is tapped, and every peer is a potential adversary. If your system cannot survive an adversary owning the physical layer, it cannot survive at all.
But this is the paradox: By assuming the network is hostile, you make it safe. When you accept the dangers for what they are, they become manageable. When you stop trusting the infrastructure and start trusting the math, you eliminate the single point of failure: Human integrity.
- Encryption Is Not A Feature
In the world of TCP/IP, encryption is an afterthought. It is a layer we slap on top of the protocol (HTTPS, TLS) to patch the security holes of the original design. It is a “feature” you sometimes enable for “sensitive data”. This is fundamentally flawed, since all data is sensitive.
In Reticulum, encryption is gravity.
It is not optional. It is not a plugin. It is the fundamental force that allows the network to exist. If you were to strip the encryption from Reticulum, the routing would break. The Transport system uses cryptographic signatures and entropy to verify paths and pass information. If packets were plaintext, intermediate nodes could not prove that a route was valid, nor could endpoints prevent spoofing or tampering.
In Reticulum, the entropy of the encrypted packet is the routing logic.
To ask for a version of Reticulum without encryption is like asking for a version of the ocean without liquid. You are not asking for a feature change; you’re asking for a different physical universe. We design for a universe where information has mass, structure, and integrity.
- Zero-Trust Architectures
We must unlearn our reliance on Institutional Trust.
For decades, we have been trained to trust authorities. We trust a website because a chain of Certificate Authorities (companies we don’t know) vouches for it. We trust an app because it is in an app store (run by a corporation we don’t control). We trust a message because it comes from a phone number assigned by a telecom. Yet, everything in our digital information sphere today is more untrustworthy and risky than a medieval second-hand underwear market.
Reticulum replaces institutional trust with Cryptographic Proof.
In Reticulum, you do not trust a node because it has a nice hostname or because it is listed in a directory. You trust it because it holds the private key corresponding to the Destination Hash you are communicating with. This trust is binary, mathematical, and absolute. Either the signature matches, or it does not. There is no “maybe”.
This shift moves the power from the institution to the individual. You become the ultimate arbiter of your own trust relationships. You decide which keys to accept, which paths to follow, and which identities to recognize.
Consider:
- The Old Way: “I trust this site because the browser says the lock icon is green”.
- The Zen Way: “I trust this destination because I have verified its hash fingerprint out-of-band, and the math confirms the signature”.
When you internalize the Physics of Trust, you stop looking for protection from firewalls, VPNs, and Terms of Service agreements. You realize that true security comes from the design of the protocol itself. You can stop trusting the cloud, and you start trusting the code - because you can verify it yourself."