Comments 16
Я где-то в комментах предлагал такую идею: клиент кодирует несколько видеопотоков разного качества и шифрует их. Отдает на сервер зашифрованные потоки.
Остальные клиенты получают от сервера зашифрованные потоки требуемых участников. Запрашивают по отдельному каналу ключ для расшифровки.
Профит.
Правда смысла мало, так как клиент не опенсорсный (не проверить) и альтернативных имплементаций заведомо без слива ключа нет (или с уведомлением о том что кто-то запросил ключи).
несколько видеопотоков разного качества— если тут только разное качество, то это чисто для подстройки под ширину канала. А чтобы e2e было — нужно именно 9 копий потока — каждый шифровать открытым ключом клиента, кому он предназначается.
Разве есть какой-то другой вариант?
Правда, много вопросов возникает о передаче ключа (видимо и закрытого, и открытого). И еще, кажется, мы теряем аутентификацию — в персональном чате другой человек не может себя выдать за собеседника, т.к. у вас его открытая часть ключа — сообщения не расшифруются. А в случае шеринга ключа на несколько клиентов — любой может представляться любым.
А в случае шеринга ключа на несколько клиентов — любой может представляться любым.
Нет, если для шифрования и аутентификации используются разные ключи.
Если Вам действительно всё это интересно — почитайте доки Keybase. Там всё вполне наглядно описано. После этого никаких вопросов к надёжности шифрования обычно уже не остаётся.
Проблема только в том, что Keybase-то безопасен, а вот что именно реализовали в зуме — неясно. И очень сомнительно, что в зуме будет тот же уровень безопасности.
Сквозное шифрование в Zoom появится и на бесплатных тарифах