Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
posted by janrinok on Thursday May 07 2020, @10:10PM   Printer-friendly
from the all-your-keybase-are-belong-to-us dept.

Zoom Acquires Keybase to Bring End-to-End Encryption to Video Platform:

Popular communications platform provider Zoom Video announced on Thursday that it has acquired secure messaging and file-sharing service Keybase for an undisclosed sum. The move is the latest by the company as it attempts to bolster the security of its offerings and build in end-to-end encryption that can scale to the company's massive user base.

"There are en-to-end encrypted communications platforms. There are communications platforms with easily deployable security. There are enterprise-scale communications platforms. We believe that no current platform offers all of these. This is what Zoom plans to build, giving our users security, ease of use, and scale, all at once," Eric Yuan, CEO of Zoom, said in a statement.

Zoom said it would offer an end-to-end encrypted meeting mode to all paid accounts.

[...] "This acquisition marks a key step for Zoom as we attempt to accomplish the creation of a truly private video communications platform that can scale to hundreds of millions of participants, while also having the flexibility to support Zoom's wide variety of uses," Yuan wrote in a blog post. "Our goal is to provide the most privacy possible for every use case, while also balancing the needs of our users and our commitment to preventing harmful behavior on our platform. Keybase's experienced team will be a critical part of this mission."

Details on Zoom's encryption roadmap are available on the Zoom blog.

Previously:
(2020-04-21) This Open-Source Program Deepfakes You During Zoom Meetings, in Real Time
(2020-04-20) Every Security Issue Uncovered so far in the Zoom Video Chat App
(2020-04-17) Looking for Alternative, Self-Hosted Audio (or Video) Chat Services
(2020-04-15) Over 500,000 Zoom Accounts Sold on Hacker Forums, the Dark Web
(2020-04-13) Zoom Admits Data Got Routed Through China

Also at TechCrunch and The Verge.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by lentilla on Friday May 08 2020, @04:16AM (5 children)

    by lentilla (1770) on Friday May 08 2020, @04:16AM (#991550) Journal

    Firstly - a statement: surely it would have been both cheaper and easier to implement this feature using libre software? Cheaper because you don't have to pay for free software, and easier because you still have to bolt the pieces together and libre encryption software has been designed for just this purpose without the fees and time-lag associated with the vertical integration consultant mob.

    Cynically: my gut tells me this acquisition is pure spin. Implementing encryption does not require purchasing a whole company - but it does give the CEO a way to deflect bad press.

    Secondly - a question. I know how end-to-end encryption works person-to-person but I don't see how it works (efficiently) in a group chat. Assuming Alice, Bob and Charlie want to chat securely - the only ways I can see is for each client to connect peer-to-peer in three distinct streams (AB AC BC), or using hub-and-spoke solution (AH BH CH) where the hub aggregates and forwards. In both cases all parties need keys to decript all other parties' messages. Do other better solutions exist?

    Cynically: they won't implement it properly. Even if they manage to defeat Hanlon's Razor ("never attribute to malice that which is adequately explained by stupidity") they won't be allowed to do so and survive by various nation states.

    Starting Score:    1  point
    Moderation   +2  
       Insightful=2, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 1, Insightful) by Anonymous Coward on Friday May 08 2020, @05:14AM

    by Anonymous Coward on Friday May 08 2020, @05:14AM (#991563)

    If it was open source, the customers would either have reason to believe their marketing, or have proof that the marketed features don't work as advertised. Hmm.

    As for buying a company, they also just aquired a bunch of developers who have recent end-to-end encryption software on their resumes - probably a lot easier than finding them somewhere else.

  • (Score: 2) by deimtee on Friday May 08 2020, @06:35AM (3 children)

    by deimtee (3272) on Friday May 08 2020, @06:35AM (#991570) Journal

    Secondly - a question. I know how end-to-end encryption works person-to-person but I don't see how it works (efficiently) in a group chat. Assuming Alice, Bob and Charlie want to chat securely - the only ways I can see is for each client to connect peer-to-peer in three distinct streams (AB AC BC), or using hub-and-spoke solution (AH BH CH) where the hub aggregates and forwards. In both cases all parties need keys to decript all other parties' messages. Do other better solutions exist?

    One way I could see it working is if one participant was designated "the hub". You could have the clients negotiate amongst themselves to see which machine had the most spare compute capacity. Reduces the effective number of participants and streams by one.

    That way if say A was designated Hub, your AH - BH - CH system becomes HB-HC. If you were going to do this a lot, you would probably designate a powerful machine for it, and the system devolves into simply having a private hub.

    That's probably good enough anyway. Remember: "Three can keep a secret, if two are dead". If you have more than four or five participants stuff is probably going to leak even if the video chat security is perfect.
    ...
    I just thought of a useful improvement. Most of the video conferencing I have done has involved people spread over two or three sites, with maybe one or two connecting from outside. You could designate a hub at any site where you have a LAN. If you had two facilities, everyone at site A connects to Hub A and at site B to Hub B. The two hubs then talk to each other, and to external participants. Still heavy on the local network, but reduces the external traffic a lot. If you trust your internal network, you would only need encryption on the H-H and H-Ext links.

    --
    If you cough while drinking cheap red wine it really cleans out your sinuses.
    • (Score: 0) by Anonymous Coward on Friday May 08 2020, @09:12AM

      by Anonymous Coward on Friday May 08 2020, @09:12AM (#991603)

      They all get the same data from the other people. They could either use a broadcast key, where all participants in a particular call use the same key to talking to the whole group, or a multicast key, where each participant uses the same key to send their data to everyone else. For key security, it would be a per-session key, where a session is defined as a new person entering/exiting and it would roll over every X amount of time/data. The actual exchange would happen over public-key encryption using part of the account info to authenticate it. All the hub would have to do is relay the key exchanges, set up the UDP hole punching, and forward any firewalled user data.

      That is a rough sketch off the top of my head, there is probably a better way but it is hardly impossible.

    • (Score: 0) by Anonymous Coward on Saturday May 09 2020, @01:12PM (1 child)

      by Anonymous Coward on Saturday May 09 2020, @01:12PM (#992018)

      Quite a while ago i played with an e-mail encryption add-on whose name I no longer remember but I believe it used PGP. Anyhow, as I recall the technique for writing to several recipients was fairly straight-forward. A very big random encryption key was created and then used with an extremely fast *symmetric* encryption algorithm. The random key was then encrypted with the public key of each recipient. And the entire mess was then transmitted as the message to each recipient. Thus each recipient could decrypt the random key and use it to decrypt the actual message. In any case, this is how I would do it if I were Zuckerberg.

      • (Score: 0) by Anonymous Coward on Sunday May 10 2020, @03:38AM

        by Anonymous Coward on Sunday May 10 2020, @03:38AM (#992237)

        I was going to reply to my comment, but I'll respond to yours so you can see it too.

        There is already an RFC [ietf.org] for this. Interestingly, it was also written by Zimmermann, who was key to the invention of PGP. While a little out of date in the security department, the baseline is very solid. It also isn't a lot of work to extend that to support multiple users or broadcast situations with the same key.