>The FTC went after Zoom in 2020. The complaint alleged that since at least 2016, Zoom misled users by claiming “end-to-end, 256-bit encryption” when it actually provided a lower level of security, and Zoom saved the cryptographic keys that would allow it to access the content of customers’ meetings.
May 7th 2020: https://www.zoom.com/en/blog/zoom-acquires-keybase-and-annou...
May 22nd 2020: https://github.com/zoom/zoom-e2e-whitepaper
E2EE seems to be available to free accounts
https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_arti...
(opinions are my own etc.)
In Proton Meetzoom
zoom-e2e-whitepaper
Security & Privacy2020–2026
zoom / zoom-e2e-whitepaper
zoom-e2e-whitepaper
Zoom Cryptography Whitepaper
19Distinct people
20Mentions
0Explicit recommenders
558GitHub stars
What to know before exploring
What it is
Zoom Cryptography Whitepaper
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year20 dated mentions
Observed mentions: 2020-05-22 17:54:07 UTC to 2026-05-07 09:07:30 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 17 | 9 | 8 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Zoom Cryptography Whitepaper
This is the home of the whitepaper documenting the cryptographic design powering several Zoom
products, including end-to-end encryption for emails, phone and meetings. The latest released PDF will always be available
here. This repository will be
updated as we implement and iterate on our cryptographic protocols.
See the changelog for a summary of what changed in each version. Note that, before
version 4.0, this document was titled "E2E Encryption for Zoom Meetings", but we updated the name to
reflect its expanded scope. We still value feedback, recommendation and corrections. Please continue
to post them under Issues.
Timeline
24 June 2025: Version 4.7 was published.
23 December 2024: Version 4.6 was published.
17 June 2024: Version 4.5 was published.
21 May 2024: Version 4.4 was published.
21 November 2023: Version 4.3 was published.
21 August 2023: Version 4.2 was published.
27 March 2023: Version 4.1 was published.
18 November 2022: Version 4.0 was published.
18 July 2022: Version 3.3 was published.
29 October 2021: Version 3.2 was published.
5 October 2021: Version 3.1 was published.
15 December 2020: Version 3 was published.
3 November 2020: Version 2.3.1 was published.
14 October 2020: Version 2.3 was published.
17 June 2020: Version 2 was published.
22 May 2020 - 5 June 2020: A comment period on the initial design
22 May 2020: Version 1 was published.
Read the full README on GitHubWhat Hacker News says
20 sourcesI've been saying this for maybe nine months vis-à-vis my consulting work keeps proving it.
Go is an excellent language for LLM code generation. There exists a large stable training corpus, one way to write it, one build system, one formatter, static typing, CSP concurrency that doesn't have C++ footguns.
The language hasn't had a breaking version in over a decade. There's minimal framework churn. When I advise teams to adopt agentic coding workflows at my consultancy [0], Go delivers highly consistent results via Claude and Codex regularly and more often than working with clients using TypeScript and/or Python.
When LLMs have to navigate Python and TypeScript there is a massive combinatorial space of frameworks, typing approaches, and utility libraries.
Too much optionality in the training distribution. The output is high entropy and does
Read the rest
n't converge. Python only dominated early AI coding because ML researchers write Python and trained on Python first. It was path dependence, not merit.\
The thing nobody wants to say is that the reason serious programmers historically hated Go is exactly why LLMs are great at it: There's a ceiling on abstraction.
Go has many many failings (e.g. it took over a decade to get generics). But LLMs don't care about expressiveness, they care about predictability. Go 1.26 just shipped a completely rewritten go fix built on the analysis framework that does AST-level refactoring automatically. That's huge for agentic coding because it keeps codebases modern without needing the latest language features in training data or wasting tokens looking up new signatures.
I spent four years building production public key infrastructure in Golang before LLMs [1]. After working coding agents like everyone else and domain-switching for clients - I've become more of a Go advocate because the language finally delivers on its promise. Engineers have a harder time complaining about the verbose and boilerplate syntax when an LLM does it correctly every single time.
[0]: https://sancho.studio
[1]: https://github.com/zoom/zoom-e2e-whitepaper
Zoom End-to-End Encryption Whitepaper
2 points · Open discussionIn both the "normal" case and in situations where end-to-end encryption is enabled, the audio and visual streams are individually encrypted with AES-GCM-256 using a key derived from a shared per-meeting key. The difference is that in the normal case, the per-meeting key is stable for the entire meeting and is available to Zoom (as is needed for POTS bridge, cloud recordings, etc...). When the meeting is E2EE, the key is generated by the host, distributed to the other attendees, and rotated as the meeting participants change.
Details: https://github.com/zoom/zoom-e2e-whitepaper/blob/master/zoom...
In Zoom Rolling Out End-to-End Encryption OfferingWhat was published not too long ago: https://github.com/zoom/zoom-e2e-whitepaper
In Zoom Rolling Out End-to-End Encryption OfferingHere's their whitepaper, linked in the post: https://github.com/zoom/zoom-e2e-whitepaper
In Zoom to bring end-to-end encryption to all users, including non-payingThis is covered in the whitepaper: https://github.com/zoom/zoom-e2e-whitepaper
In Zoom to bring end-to-end encryption to all users, including non-payingThat was my thought exactly, but I read the zoom whitepaper (https://github.com/zoom/zoom-e2e-whitepaper/blob/master/zoom...), and it looks like the scheme addresses many of those issues.
Some things that looked like good steps:
> we will allow the
SSO IDP (Identity Provider) to sign a binding of a Zoom public key to an SSO identity,
and to plumb this identity through to the UI.
> Second, we allow users to track contacts’ keys across meetings.
This way, the UI can surface warnings if a user joins a meeting with a new public key.
> we will implement a mechanism that forces Zoom servers (and SSO
providers) to sign and immutably store any keys that Zoom claims belong to a specific
user, forcing Zoom to provide a consistent reply to all clients about these claims. Each
client will periodically audit the keys that are being advertised for thei
Read the rest
r own account and
surface new additions to the user.
> In Phase IV, we look to the future where Bob should sign new devices
with existing devices, use an SSO IDP to reinforce device additions, or delegate to his local
IT manager.
All of this of course relies on a zoom client actually doing everything described in the whitepaper, but it certainly looks like a good faith effort to implement real, functional e2ee
Zoom End-to-End Encryption Whitepaper
51 points · Open discussionWhat makes you think they're abusing the term? Did you read their whitepaper?
https://github.com/zoom/zoom-e2e-whitepaper
In Zoom to bring end-to-end encryption to all users, including non-payingZoom End-to-End Encryption Whitepaper
1 points · Open discussionTheir E2E proposal design is open:
https://github.com/zoom/zoom-e2e-whitepaper
In Zoom says it won’t encrypt free calls so it can work more with law enforcementSure. Study a PhD in cryptanalysis and reverse engineering.
If you want to look at something now, the white paper for the E2E protocol design is public and open right now:
https://github.com/zoom/zoom-e2e-whitepaper
On a more serious note, until there is a protocol and implementation available then we can't say anything for sure. Us Security folks aren't magicians.
In Zoom says it won’t encrypt free calls so it can work more with law enforcementPaper: E2E Encryption for Zoom Meetings [pdf]
2 points · Open discussionZoom End-to-End Encryption Whitepaper
1 points · Open discussionShowing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.