Сквозное шифрование в Zoom появится и на бесплатных тарифах

[AtachiShadow]

Сквозное шифрование в Zoom — звучит как оксюморон

[seregazh]

Ну не такой уж и оксюморон. OMEMO частично решает проблему, разве нет ?!

[mixsture]

Мне вот тоже интересно. E2E шифрование вроде существует только между 2мя клиентами. Если в конференции 10 участников, то по E2E принципу надо их разбить на возможное число пар и в каждой паре пускать шифрованный трафик, но тогда как доставлять один и тот же кадр конференции всем? получается его условно 10 раз придется прокачивать по-разному зашифрованным.

[myz0ne]

Я где-то в комментах предлагал такую идею: клиент кодирует несколько видеопотоков разного качества и шифрует их. Отдает на сервер зашифрованные потоки.
Остальные клиенты получают от сервера зашифрованные потоки требуемых участников. Запрашивают по отдельному каналу ключ для расшифровки.
Профит.
Правда смысла мало, так как клиент не опенсорсный (не проверить) и альтернативных имплементаций заведомо без слива ключа нет (или с уведомлением о том что кто-то запросил ключи).

[mixsture]

Пока не понял.

несколько видеопотоков разного качества

— если тут только разное качество, то это чисто для подстройки под ширину канала. А чтобы e2e было — нужно именно 9 копий потока — каждый шифровать открытым ключом клиента, кому он предназначается.
Разве есть какой-то другой вариант?

[Ivanq]

10 участников могу сгенерировать общий ключ для симметричного шифрования. Не совсем классический end-to-end, но условие, что сервер не может расшифровать данные, сохраняется.

[chupasaurus]

В Keybase для групповых чатов ротировался общий ключ при добавлении/удалении юзера, доки.

[mixsture]

Насколько я знаю, когда есть какой-то «общий» на несколько человек ключ — это уже точно не e2e. Т.к. идея e2e именно в том, чтобы зашифровать у одного клиента ключом другого и в конечной точке расшифровать.

[AC130]

Эм? e2e — End-to-End, т.е. данные шифруются и расшифровываются на оконечных устройствах, а не на промежуточной инфраструктуре, она отвечает только за передачу зашифрованных данных. Если получится сделать три оконечных устройства, которые шерят один ключ, так, чтобы промежуточный сервер этот ключ не знал, то данные могут быть зашифрованы и расшифрованы только на оконечных устройствах. То что при этом ключ знает больше двух оконечных устройств, это вполне ок, в групповых чатах именно такой сценарий использования.

[mixsture]

Хм. Не знал. Да, похоже, что так можно.
Правда, много вопросов возникает о передаче ключа (видимо и закрытого, и открытого). И еще, кажется, мы теряем аутентификацию — в персональном чате другой человек не может себя выдать за собеседника, т.к. у вас его открытая часть ключа — сообщения не расшифруются. А в случае шеринга ключа на несколько клиентов — любой может представляться любым.

[Ivanq]

А в случае шеринга ключа на несколько клиентов — любой может представляться любым.

Нет, если для шифрования и аутентификации используются разные ключи.

[powerman]

Если Вам действительно всё это интересно — почитайте доки Keybase. Там всё вполне наглядно описано. После этого никаких вопросов к надёжности шифрования обычно уже не остаётся.

Проблема только в том, что Keybase-то безопасен, а вот что именно реализовали в зуме — неясно. И очень сомнительно, что в зуме будет тот же уровень безопасности.

[KanuTaH]

github.com/zoom/zoom-e2e-whitepaper

[powerman]

Спасибо, это любопытно. Но Вы же понимаете, пока клиент зума не станет опенсорсным — ответа на вопрос "что именно реализовали в зуме" не будет получено. А я что-то очень сомневаюсь, что он станет опенсорсным.

[seregazh]

В мае была новость что Zoom приобрел Keybase. Надеюсь что они возьмут на вооружение лучшие решения.

[powerman]

Я на это не очень надеюсь, но надеюсь что они хотя бы не убьют keybase.