アカウント名:
パスワード:
TLSの暗号化そのものも「セッション鍵」という「ネゴシエートされたキー」を使って暗号化しますし、類似技術であるSIP+SRTPもINVITEリクエスト(もしくはそれに対する200 OKレスポンス)でSRTPの鍵をやりとりします(RFC-4568, INVITEそのものはTLSで暗号化します)。
どこらへんが「エンドツーエンド暗号化の要件には当てはまらない」んでしょうか?
参加者とZoomのサーバの間の暗号化(Zoomはこれをエンドツーエンド暗号化と呼んでる)はされてても参加者と参加者の間が全部通しで暗号化(The Interceptはこれをエンドツーエンド暗号化と呼んでる)されてるわけじゃない。好きな方の定義を選んで。
あと、SIP+SRTPでThe Interceptの言うエンドツーエンド暗号化された会議をやろうとするとメッシュ状に暗号化したセッションを張らなきゃいけないので大規模なのは大変。
なるほどサーバーとユーザーの間しか暗号化出来ていないってタレコミに書かなきゃ何を言いたいのか分からんよね
キミ以外は分かってるよ。
いやわかんなかったな。TLSはE2E暗号化だし何言ってんだコイツと思ったわ
全参加者でメッシュで通信なんか少し数増えたら現実的じゃないし想像してなかった富豪度が足りんなぁ
> 全参加者でメッシュで通信なんか少し数増えたら現実的じゃないし想像してなかった
会議用セッション鍵を開催者が生成し、個別参加者と 1:n で公開鍵暗号使った鍵交換すれば、全参加者でセッション鍵を共通しつつ、E2E暗号化が実現できるから、全然実現可能だと思う。
鍵の問題じゃなくて通信量の問題。
通信量に真っ先に気が行くのは老人なんですかね10人の会議なら10倍、100人なら倍ですよちょっとなぁ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
エンドツーエンド暗号化の要件には当てはまらない? (スコア:0)
TLSの暗号化そのものも「セッション鍵」という「ネゴシエートされたキー」を使って暗号化しますし、類似技術であるSIP+SRTPもINVITEリクエスト(もしくはそれに対する200 OKレスポンス)でSRTPの鍵をやりとりします(RFC-4568, INVITEそのものはTLSで暗号化します)。
どこらへんが「エンドツーエンド暗号化の要件には当てはまらない」んでしょうか?
Re: (スコア:4, 参考になる)
参加者とZoomのサーバの間の暗号化(Zoomはこれをエンドツーエンド暗号化と呼んでる)はされてても参加者と参加者の間が全部通しで暗号化(The Interceptはこれをエンドツーエンド暗号化と呼んでる)されてるわけじゃない。好きな方の定義を選んで。
あと、SIP+SRTPでThe Interceptの言うエンドツーエンド暗号化された会議をやろうとするとメッシュ状に暗号化したセッションを張らなきゃいけないので大規模なのは大変。
Re: (スコア:0)
なるほど
サーバーとユーザーの間しか暗号化出来ていないってタレコミに書かなきゃ何を言いたいのか分からんよね
Re: (スコア:-1)
キミ以外は分かってるよ。
Re: (スコア:0)
いやわかんなかったな。
TLSはE2E暗号化だし
何言ってんだコイツと思ったわ
全参加者でメッシュで通信なんか少し数増えたら現実的じゃないし想像してなかった
富豪度が足りんなぁ
Re: (スコア:1)
> 全参加者でメッシュで通信なんか少し数増えたら現実的じゃないし想像してなかった
会議用セッション鍵を開催者が生成し、個別参加者と 1:n で公開鍵暗号使った
鍵交換すれば、全参加者でセッション鍵を共通しつつ、E2E暗号化が実現できるから、
全然実現可能だと思う。
Re: (スコア:0)
鍵の問題じゃなくて通信量の問題。
Re:エンドツーエンド暗号化の要件には当てはまらない? (スコア:2)
通信量に真っ先に気が行くのは老人なんですかね
10人の会議なら10倍、100人なら倍ですよ
ちょっとなぁ