All of this is aimed at building extremely good end-to-end protections for Zoom meetings while remaining easy to use and to deploy. Key management is hard. This is one of the biggest lessons I learned when I started building crypto in practice rather than only in theory.
-
Show this thread
-
We had a *huge* advantage when designing this: Zoom already has the meeting contents traverse the servers encrypted. So what you’ll see in this paper is changing how Zoom does key management rather than a full-on design for a videoconferencing system.
3 replies 0 retweets 36 likesShow this thread -
Like I said when Zoom acquired Keybase: crypto is better with friends. The Keybase folks are amazing, as are
@alexstamos and@matthew_d_green.1 reply 4 retweets 111 likesShow this thread -
Also: please put your comments in the github because if we tried to use Twitter and HN as a project management tool it’s going to be excessively exciting.
1 reply 4 retweets 70 likesShow this thread -
Lea Kissner Retweeted Alex Stamos
@alexstamos has a better list of Twitter handles (and thanks to all of the other folks who were involved, including the external counsel who suggested we use the phrase "as contemplated herein" multiple times and I almost did it)https://twitter.com/alexstamos/status/1263896949712814080 …Lea Kissner added,
Alex StamosVerified account @alexstamosZoom has published an initial design and roadmap for deploying end-to-end encryption for hundreds of millions of meeting participants. Check it out and leave your comments here: https://github.com/zoom/zoom-e2e-whitepaper/blob/master/zoom_e2e.pdf …Show this thread1 reply 0 retweets 34 likesShow this thread -
Replying to @LeaKissner @alexstamos
Coming in hot with my q's about the web client
https://github.com/zoom/zoom-e2e-whitepaper/issues/2 …2 replies 0 retweets 10 likes -
3 replies 0 retweets 9 likes
-
What’s the new hotness in protecting JS from being changed for one user?
6 replies 0 retweets 5 likes -
Replying to @alexstamos @sleevi_ and
I'm not sure its a problem worth solving, you have to trust the provider, because bugdoors are perfect and plausibly deniable. If you distribute a targeted backdoor to one user, you might get caught, but w/bugdoor, just say "oops, please be responsible" if someone catches you.
2 replies 0 retweets 7 likes -
Replying to @taviso @alexstamos and
Tavis, do you mean distributing the "targeted bugdoor" to all users but then only exercising it against the one target user? Or distributing it to just the targeted user?
1 reply 0 retweets 0 likes
Right, why not just distribute it to all users, and then exercise it against the target user? There is zero penalty if you're caught, you can just try again.
-
-
Replying to @taviso @alexstamos and
hm. Interesting argument. So basically you have to always maintain at least one bugdoor in your release version.
1 reply 0 retweets 0 likes -
Replying to @zooko @alexstamos and
You can also add a new one in a feature update or patch if you decide to become malicious later, or if your old one gets found. I don't really know of any way to defend against bugdoors, you have to trust your provider.
1 reply 0 retweets 3 likes - 8 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.