A bit random, but I'd really like to manage video calls through a browser extension. Am I alone in this? Seems unnecessary to move in between apps, couldnt we be hopping in and out of rooms without leaving the browser?
Proof of concept: end-to-end encryption in Jitsi Meet
91–100 of 151 posts
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#92It's a nice tech demo, but it runs into the same problem that so many of these systems run into: individual users don't want to be arsed to self-manage their encryption keys. You can't solve the UX on that, and users will ignore your service in favor of one that doesn't require that of them. As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being…
So what you're saying is that all end to end encryption is futile and we might as well get rid of it? Let's not build this in, even opportunistically, for nobody because very few people use it? Because saying "individual users don't want to be arsed to self-manage their encryption keys" + that service providers could keep your keys but then you might as well not have e2ee in the first place + that the UX is "impossib…
I'm not saying precisely that (I don't think the UX is impossible to solve; merely hard), but you've just given the kind of argument a product manager would give on prioritizing feature sets for a commercial application: by the logic you've laid out, centralized key management provided by the service provider likely attracts more users and is the feature "we" should implement first.
... which is why we see a lot more people using Zoom than using something else, and we see few solutions available that offer any client-side e2e encryption support at all (and if they offer it, it's almost always in addition to their server-managed key options).
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#93Earlier quoted context omitted.
Yeah, it shouldn't be unsolvable; my key thought is that it's actually the hard part of the story now (encryption client-side is pretty well-understood) and is under-solved. Even still, having more options in the world is better than having fewer, so I'm excited about this demo.
I disagreed with "you can't solve the UX", but I definitely agree that it's a hard problem. Looking forward to seeing what they come up with.
I think my choice of words left me open to misinterpretation: the "you... and...." phrasing was meant as synonymous with "If you... then...", not as a categorical claim that I believe the UX is unsolvable.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#94It's a nice tech demo, but it runs into the same problem that so many of these systems run into: individual users don't want to be arsed to self-manage their encryption keys. You can't solve the UX on that, and users will ignore your service in favor of one that doesn't require that of them. As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being…
I don't understand where this problem of distributing encryption keys comes from in the context of this tech demo. Zoom uses "passwords" and people are more than happy to distribute them by email / WhatsApp / shouting from the rooftops. The important aspect is that the video conferencing provider and server do not know the key. I also disagree with your opinion that "you can't solve the UX on that". The tech demo her…
I think passing in a static key (password) via a url fragment is what their demo is doing already. However, I get the impression the intention is to verify the keys of who's actually in the room, rather than just trusting a static key which will inevitably leak. They're presumably also planning to re-key via a ratchet to avoid a single leaked key compromising the whole conference recording.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#95Earlier quoted context omitted.
If it's HMAC'd, there's no sidestepping of padding oracles needed. Error side channels are a consequence of chosen ciphertext attacks, not of padding. Switching to CTR would not "go a long way" towards shoring up the security of their protocol. I do not understand your "confused deputy" attack. Can you outline it in more detail?
Is it really HMAC’d? 8 bytes isn’t cryptographic protection. It may be secure, but the standard arguments don’t apply.
Write a sketch of how a padding oracle attack would work against a CBC-encrypted message authenticated with truncated HMAC.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#96This is huge for decoupling zoom clients from zoom backend servers.
In theory, using a fixed/trusted set of client assets (javascript+html, e.g. an electron wrapper) allows groups of users to choose a Jitsi "backend" provider that they don't even trust if the encryption key is never sent to the server (and can't be, i.e. it is never in the URL hash).
Since the video is e2e-encrypted and in theory the server never has to be given the key, this would allow people to purchase hosting services from untrusted providers or spin up a VM in a public cloud with the confidence that the content of their conversations is not available to the provider.
Yes, we could just argue that this is XMPP servers and Pidgin all over again (in fact, Jitsi uses an XMPP server internally), but the modern UI and the timing w.r.t. COVID-19 lockdowns and Zoom privacy issues is fantastic.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#97Sad to see this is dependent on an extension to WebRTC that’s (currently) Chrome / Chromium-only. It’s still a proposed API, and I don’t see when this will be supported by any other browsers.
Really, really sad. I’m not going to run Chrome for this one application.
I'm not sure if you are aware of the difference, but you can use Chromium instead of Chrome.
I am mainly a Firefox user on NixOS, but for running Chrom{e,ium} I find that Firejail [0] is a good option. For example, to run chromium in "store" mode and point it to the demo jitsi instance:
firejail --profile=chromium chromium --app="https://meet.jit.si"
nix-shell -p chromium --run "firejail --profile=chromium chromium --app=\"https://meet.jit.si\""
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#98Earlier quoted context omitted.
If they hook into Matrix's E2EE key management stuff, then they'll benefit from the huge amount of work we've put into letting individual users transparently self-manage their keys - c.f. https://youtu.be/APVp-20ATLk?t=6355 for a demo from last Wednesday. This stuff is due to ship in Matrix/Riot in the coming week. That said, agreed that it's a massive and (up to now?) unsolved problem for how to get mainstream users…
Off-the-Record (OTR) Messaging for Pidgin[1] provides this and hides the complexity from the user. Sadly, all of my Google Talk, AIM, QQ, and MSN contacts have moved to proprietary platforms like whatsapp, skype, and facebook. I miss the days of 1 messaging platform for all my work and personal chatting. For a solid decade Gaim/Pidgin handled all of this for me. [1] https://otr.cypherpunks.ca/
hm, OTRv3 has some pretty major shortcomings - off the top of my head; it's only for 1:1 chat; both users need to be online at the same time to initiate a session; limited to non-elliptic-curve DH; socialist millionaire's protocol for in-band key exchange (but relies on a secret being preshared out-of-band); etc. It was great back in the day, but Double Ratchet (a la Signal & Olm) has replaced it - just as MLS may replace the Double Ratchet in time.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#99Love Jitsi but dont try to run this on AWS EC2 -- the network charges quickly add up. I had set Jitsi videobridge for my kid's friends and their friends -- the network charges quickly added up before I shut it down.
Try a host that doesn't charge for bandwidth. Dedicated servers at Hetzner and/or OVH doesn't charge this imaginary fee so you can sleep well and just pay a static sum each month.
Precisely. Hetzner can provide a dedicated server with an Intel Core i7-2600, 16 GB RAM, and 2x3TB spinning disks for 29,00 €/month before tax with unlimited traffic via their server auction site for orphaned servers [0].
Other Hetzner and many OVH offerings have traffic caps, but these are in the region of ~10TB/month.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#100Earlier quoted context omitted.
I appreciate the context. It's probably wise to abandon Signal interop. My reasoning here is: Moxie isn't ever going to acquiesce on the points he's stubborn about, and Olm/Megolm could otherwise be a great cryptographic design with or without his approval. > What don't you like about the variable names at https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e... ? Confusion between ciphertext on line 85 and ou…
> I appreciate the context. It's probably wise to abandon Signal interop. > Olm/Megolm could otherwise be a great cryptographic design with or without his approval. Could you (or Arathorn) expand on why Olm should deviate from the Signal protocol, instead of trying to reproduce it as closely as possible? Which requirements are different? I understand that the Signal protocol is the state of the art in terms of E2EE f…
> Could you (or Arathorn) expand on why Olm should deviate from the Signal protocol, instead of trying to reproduce it as closely as possible?
Because the only premise for strictly adhering to the Signal protocol has been invalidated by Moxie's personality.
With a false premise, why maintain a true conclusion?
In my OP comment, I outlined some criticisms of what they're doing, and suggested ways to improve it. Some of these (dropping AES-CBC+HMAC for AES-CTR+HMAC) have meaningful gains but, strictly speaking, are not Signal-compat.
The change to the ratcheting protocol adds a layer of indirection in the forward secrecy, but that also deviates from Signal. (My proposed change would make it closer to what the Noise Protocol Framework does.)
> Which requirements are different?
The technical requirements aren't changed, but you can get better performance AND security on more platforms by using XChaCha20 instead of AES-CBC, so that's a meaningful security gain that Signal cannot boast (i.e. in the context of legacy Android devices).