$ end-to-end encryption
(I) Continuous protection of data that flows between two points in
a network, effected by encrypting data when it leaves its source,
keeping it encrypted while it passes through any intermediate
computers (such as routers), and decrypting it only when it
arrives at the intended final destination. (See: wiretapping.
Compare: link encryption.)
Examples: A few are BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS,
SILS, SSH, SSL, TLS.
Tutorial: When two points are separated by multiple communication
links that are connected by one or more intermediate relays, end-
to-end encryption enables the source and destination systems to
protect their communications without depending on the intermediate
systems to provide the protection.
There's a bunch of older references as well. Since SSL/TLS wasn't really adopted by a lot of services until 2008+ usages of it are mainly in papers, old forum posts, etc. I saw it used and was discussing it back in the day on IRC with folks who were way more knowledgeable than me on this topic and had been in the trenches for a while :D
I think part of the problem is that prior to WhatsApp's E2EE implementation in like 2014, TLS was very often called "End to End Encryption" as the ends were Client and Server/Service Provider. It got redefined and now the new usage is way more popular than the old one.
I can't blame most people for calling TLS "E2EE", even some folks in industry, but it's not great for a company to advertise that you offer X if the meaning of X has shifted so drastically in the last decade.
I’m pushing back on that one. I’ve been running websites since the ‘90s, and I’ve never heard E2EE used that way until very recently by vendors who, bluntly, want to lie about it.
It was pretty common to call client-side encryption/SSL "end to end encryption" among network engineers who were analyzing data flowing through their networks[0] as well as those who were implementing SSL/TLS into their applications[1]. The ends were the client and the server and the data was encrypted "end to end". The goal at that time was to prevent MITM snooping/attacks which were highly prevalent at the time.
Papers in academia and the greater industry[2] also referred to it in this way at the time.
Stack Overflow has plenty of examples of folks calling it "end to end encryption" and you can start to see the time period after the Signal protocol and WhatsApp implemented it that the term started to take on a much wider meaning[4]
This also came up a lot in the context of games that rolled out client side encryption for packets on the way to the server. Folks would run MITM applications on their computer to intercept game packets coming out of the client and back from the server. Clever mechanisms were setup for key management and key exchange[3].
[0] as SSL became more common lots of tooling broke at the network level around packet inspection, routing, caching, etc. As well as engineers "having fun" on Friday nights looking at what folks were looking at.
[1] Stack Overflow's security section has references from that era
At least in some circles, the real meaning of "end-to-end encryption" was being addressed. For example, in the field of credit card processing, here's an article from 2009 which talks about how people back then were misusing the term: https://web.archive.org/web/20090927092231/http://informatio...
Granted, it's a marketing piece trying to sell a product, but still.
I wasn't a network engineer, but to my recollection "end-to-end encryption" was only used occasionally, probably by people not too knowledgeable in cryptography
Well respectfully your recollection is missing lots of references by people that were "knowledgeable in cryptography".
You can easily find these references in the literature, often comparing link encryption with end-to-end encryption. Some of the earliest papers outlining the plans for SSL in the 90s (Analysis of the SSL 3.0 Protocol) are based on this exact foundation from the 80s (End-To-End Arguments in System Design).
Hell, you can even go back to 1978 and see MITRE discussing this exact thing in "Limitations of end-to-end encryption in secure computer networks".
With three citations I was about to give in, and accept that my experience might have been limited, but then I checked those citations and... are you trolling? Or were those given you by an llm?
1. "End-To-End Arguments in System Design" (https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...) argues that it's appropriate to perform various functions at the high-level, application, ends, rather than for example leaving encryption to devices external to the hosts.
It's really a stretch to affirm that it considers "end-to-end encryption" a proper term for transport, client-server encryption.
Actually, I'd say that transport-level, origin-server -> server-destination encryption is precisely one of the things that the paper would not consider end-to-end.
a. it doesn't "outline the plans for ssl", it's an analysis of its third version???
b. It doesn't reference "End-To-End Arguments in System Design" anywhere, and doesn't even contain the expression "end-to-end"
3. "Limitations of end-to-end encryption in secure computer networks" is mostly concerned with warning about side-channels, that they can be used to disseminate information despite encryption.
Its usage of end-to-end encryption is defined in the paper that's being criticized (https://dl.acm.org/doi/pdf/10.1145/1499799.1499812):
«The term end to-end encryption refers to data being enciphered at the source and remaining unintelligible until it deciphered at its final destination.»
I'll take the hit on the loose phrasing regarding the SSL paper "outlining plans". That was a poor description of mine of an analysis paper and wasn't a good example of the point I was trying to make. However, you are focusing on the trees and missing the forest. The citations you analyzed actually prove the semantic shift I am describing, specifically the MITRE one.
You quoted the MITRE paper (or the older paper it references) defining end-to-end encryption as:
> "data being enciphered at the source and remaining unintelligible until it deciphered at its final destination."
This is the exact crux of the disagreement. In classic Client-Server architecture, the Server was the "final destination". The application processing the data lived on the server. Therefore, by the definition you just quoted, SSL/TLS from Client to Server was "End-to-End Encryption" because the network (routers/ISPs) could not decipher it.
The "modern" definition (post-Signal/WhatsApp) effectively redefined "final destination" to mean "another human user," relegating the Service Provider to a mere hop in the middle. That is a massive semantic shift.
re Saltzer's "End-to-End Arguments": The paper argues that functions (like reliability or encryption) should be moved from the lower network layers (links) to the "ends" (hosts/applications). SSL/TLS is the literal implementation of this argument: moving encryption out of the network links (Link Encryption) and into the application endpoints (Host-to-Host).
The term "End-to-End" in networking *has* historically meant Host-to-Host (Transport Layer), whereas the modern messaging usage means User-to-User. That is why a lot of folks from that era (and the RFCs) called SSL "End-to-End encryption" because relative to the network, it is.
> At this time all Internet Protocol (IP) packets must have most of their header information, including the "from" and "to" addresses, in the clear. This is required for routers to properly handle the traffic even if a higher level protocol fully encrypts all bytes in the packet after the IP header. This renders even *end-to-end encrypted* IP packets subject to traffic analysis if the data stream can be observed.
---
Regarding your claim that "no one really used the E2EE term before it got the current meaning," the IETF standards for the internet (albeit an informational RFC and not a standards RFC) explicitly list SSL and TLS as examples of End-to-End encryption. The definition of "End" has simply shifted from the Machine to the User.
> I'll take the hit on the loose phrasing regarding the SSL paper "outlining plans". That was a poor description of mine of an analysis paper and wasn't a good example of the point I was trying to make
I don't understand why you cited it at all; I didn't read it carefully, but I didn't find anything relevant to the discussion.
---
RFC4949 might indeed support your point; it says intended final destination, though: while SSL is listed among the examples, does that include the "SSL-server-SSL" of a non-E2EE messaging system?
I think there's a good chance that it doesn't, in the intentions of the RFC's authors.
---
> This is the exact crux of the disagreement. In classic Client-Server architecture, the Server was the "final destination"
The disagreement is on whether in a user-server-user system, encrypting the two user-server sides was ever considered sufficient to call it an end-to-end encrypted system.
I think it wasn't, and to my recollection, luckily, no one ever tried to call it that.
Keep in mind that it used to be rare both to use any kind of encryption, and to go through an intermediary server for real-time, one-to-one communication.
It's only when centralized messaging systems begun to use SSL that the possibility of confusion arose.
They should just never have called themselves encrypted, in my opinion; encrypting the traffic was sure a big improvement, but I'd only call a messaging system encrypted if no decryption occurs before reaching the recipient
---
> The definition of "End" has simply shifted from the Machine to the User.
The ends are actually machines in the current definition too, it's not like people decrypt stuff by hand ;)
---
You sure proved that E2EE was a term already in use, anyhow (although I don't think too widely)
The two endpoints of the communication with Kohler's app are the client and the server. In WhatsApp's E2EE implementation the endpoints are two client devices. Both are valid meanings of E2EE. You're defining that "end to end" means the server cannot access it but that's simply not what it means.
The modern usage of E2EE definitely means that "the server cannot access it". That's the meat of this entire discussion.
While you are technically correct in a network topology sense (where the "ends" are the TCP connection points), that definition has been obsolete in consumer privacy contexts for a decade now due to "true" E2EE encryption.
If we use your definition, then Gmail, Facebook, and Amazon are all "End-to-End Encrypted" because the traffic is encrypted between my client and their server. But we don't call them E2EE because the service provider holds the keys and can see the data.
In 2025, when a company claims a camera product is "E2EE", a consumer interprets that to mean "Zero Knowledge". I.e. the provider cannot see the video feeds. If Kohler holds the keys to analyze the data, that is Encryption in Transit, not E2EE. Even though in an older sense (which is what my original comment was saying), it was "End to End Encrypted" because the two ends were defined as Client and Server and not Client to Client (e.g. FB Messenger User1 and FB Messenger User2).
> If we use your definition, then Gmail, Facebook, and Amazon are all "End-to-End Encrypted" because the traffic is encrypted between my client and their server.
That may or may not be the case. TLS is always terminated at a load balancer that uses TLS but it's still common to use HTTP within datacenters. So it may not be E2EE and it's a meaningful security feature.
It was only a decade or so ago that "End-To-End Encryption" began to mean something other than "encrypted in transit".
E2EE now means something wildly different in the context of messaging applications and the like (since like 2014) so this is more of an outdated way of saying "no one is getting your poop pictures between your toilet and us".
It also feels like it would never make sense for this to be "E2EE encrypted" in the modern sense of the term as the "end user recipient" of the message is the service provider (Kohler) itself. "Encrypted in Transit" and "Encrypted at Rest" is about as good as you're going to get here IMO as the service provider is going to have to have access to the keys, so E2EE in a product like this is kind of impossible if you're not doing the processing on the device.
I wonder if they encrypt it and then send it over TLS or if they're just relying on TLS as the client->server encryption. Restated, I wonder how deep in their stack the encrypted blob goes before it's decrypted.
> It was only a decade or so ago that "End-To-End Encryption" began to mean something other than "encrypted in transit".
No, before that it was simply not a term, except in some obscure radio protocol (and even there someone competent in cryptography would probably not have chosen that term)
> E2EE now means something wildly different in the context of messaging applications and the like (since like 2014) so this is more of an outdated way of saying "no one is getting your poop pictures between your toilet and us".
The outdated way was saying "Military-grade 128-bit encryption", no one really used the E2EE term before it got the current meaning
> I wonder if they encrypt it and then send it over TLS or if they're just relying on TLS as the client->server encryption. Restated, I wonder how deep in their stack the encrypted blob goes before it's decrypted.
Some homemade encryption added on top of TLS is very unlikely to increase the security of the system
> Some homemade encryption added on top of TLS is very unlikely to increase the security of the system
"Some homemade encryption" is not what I was suggesting at all. E.g. encrypted-at-the-source (client side) AWS files are still sent over TLS as an encrypted blob within an encrypted blob but remain encrypted past the TLS boundary.
That paper is about PKI-based session setup for End-End which is the ancestor of SSL/TLS. It even mentions a CAE which is effectively a CA and it does a synchronous handshake to establish a symmetric key. It's very clearly about transport layer security from end to end.
It's not about User-User E2EE (akin to Signal) and shares very little other than that data is encrypted from point A to point B.
To be clear, SSL/TLS and other transport protocols can absolutely be considered end-to-end encryption, if they're established between the two real interlocutors.
Otherwise, you have two instances of encryption with decryption in the middle; that can't logically be called end-to-end encryption, I never heard it called so, and hopefully it never was.
> "Some homemade encryption" is not what I was suggesting at all. E.g. encrypted-at-the-source (client side) AWS files are still sent over TLS as an encrypted blob within an encrypted blob but remain encrypted past the TLS boundary.
They need to analyse the data; adding layers of encryption, thus, could only improve security if the keys for the inner encryptions are better protected than the server's TLS private key.
Which would honestly, actually, likely to be the case, but it would probably be a modest improvement
Usually when you commission something you're asking the artist to do art and create something unique with their own artistic flair... not just line-trace an existing photo.
The intention and cost of something like that is not at all comparable to what is being offered here.
> We found that the the Great Flood in the book of Genesis existed
Can you elaborate what you mean by the "Great Flood"? There's certainly evidence for regional megafloods, but I'm not aware of any professional geologic body that recognizes what most people mean when they say "Great Flood", i.e. a single planet-wide flood around that time period.
The Black Sea Deluge Hypothesis posits that around 7,500 years ago, the Mediterranean Sea breached the Bosporus Strait, causing a massive influx of water into the Black Sea. This event transformed the Black Sea from a freshwater lake into a saltwater sea, resulting in a dramatic rise in water levels. This rapid flooding would have submerged large areas of land, displacing human settlements along the coastline. The catastrophic nature of this event is believed to have been preserved in the oral traditions of ancient cultures, leading to the creation of flood myths, such as those in the Bible and the Mesopotamian epics like the Epic of Gilgamesh. Archaeological evidence, including submerged prehistoric settlements and shifts in the Black Sea's shoreline, supports the idea of this sudden and profound flooding event. The Black Sea Deluge is considered a key historical event that likely influenced the development of various ancient flood myths across the Near East and beyond.
implies most people since the King James version was published. Not at all clear that's what author meant; the concept of the world as we now know it didn't exist then.
So very reasonable to conclude that the Great Flood in Genesis was meant to describe a regional megaflood, which innundated the "whole world" meaning all of Mesopotamian civilization.
And there is archeological evidence of ancient cities totally buried in mud, i.e. as you say regional megafloods.
I don't think that's true at all. The narrative is very clear that all humans and land animals that are not on the ark die, and in the Talmud I'm not aware of any debate that all humans died.
Is it fair to say that also in your experience, those crucial edge cases/misses accumulate over time, making it even harder to ship things?
I've found this a lot in data systems where folks glue stuff together as fast as possible to "ship", while missing the huge glaring issues with the foundation that they've built on top of wet, sliding mud.
Yeah pretty fair to say. The company is in a domain where accuracy is very important and crucial because we deal with people’s money, but most products are also in a market where competition is high so moves must be made quickly.I have not been there for long but it seems in the beginning, the foundation laid because of fast shipping culture has caused all these problems.
In my head, I'm imagining someone early in the morning posting a flyer up on a bulletin board downtown.
Throughout the day many folks walked by and took photos of the flyer with their cell phone.
At the end of the day, the original person came back and removed the flyer.
IMO, at the time that the folks took the photo of the flyer, that flyer was public information. It remains public information even after the flyer is removed[0].
This isn't a great analogy of mine, and has plenty of holes, but was interesting to me after I read your comment. I know it was in the context of doxxing, but I think it's pretty interesting philosophically.
I think something similar applies to photos taken of other people in public spaces. Both the person who took the photo and the subject of the photo are no longer in that physical public space, but the actions took place within that space.
I think something similar applies to digital "public spaces". But what does a public space even mean in the context of walled gardens[1], etc.
[0] you then run into the question of what happens if someone posts non-public information, publicly?
[1] are digital walled garden communities that different from physical communities that gate access, whether free or paid. Whether information shared within those contexts are public or private is an interesting thread as well.
I think there's a decent case to be made that he was considered a "rabbi", or teacher in the time period prior to the destruction of the second temple, by a group of jewish folks.
As far as I understand it, the more formalized, institutional rabbinic structure came after the destruction of the second temple.
Sure, but as far as I understand it, his followers were Jewish people, those followers called him Rabbi, so at that time... it was a "Jewish viewpoint".
A lot of the houses that don't currently have modern high speed internet access also don't have water pipes and sewer pipes. They have wells or water collection/delivery and septic tanks.
Electricity and twisted pair phone line is really all that's been pulled to their property.
RFC 4949 (Internet Security Glossary, Version 2) from 2007: https://datatracker.ietf.org/doc/html/rfc4949
There's a bunch of older references as well. Since SSL/TLS wasn't really adopted by a lot of services until 2008+ usages of it are mainly in papers, old forum posts, etc. I saw it used and was discussing it back in the day on IRC with folks who were way more knowledgeable than me on this topic and had been in the trenches for a while :D