Proof of concept: end-to-end encryption in Jitsi Meet
1–10 of 151 posts
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#2>GET parameter
Yes, it's convenient.
But to tout that as what a well designed encryption scheme should look like? Nah.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#3This is insanely cool - insertable webrtc streams only just landed in canary (https://www.chromestatus.com/feature/6321945865879552). Also very cool they’re looking to use Matrix’s libolm Double Ratchet implementation for key exchange, which hopefully will make it easier to integrate Matrix’s e2ee with Jitsi’s in future :)
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#4Jitsi was the one Jabber client I used a few years back that I liked. I didn't find as many people on Jabber back then as I've seen elsewhere however. I believe you could use OTR alongside it, so you don't even need to trust them, just their implementation / version of OTR (a few more layers to consider I suppose).
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#5>GET parameter Yes, it's convenient. But to tout that as what a well designed encryption scheme should look like? Nah.
What is your alternative suggestion? In a browser-based video chat scenario you are ultimately assuming some level of browser security and that the clients are trusted.
What they propose is an E2E encryption, e.g. Zoom / MS Teams are unable to decrypt your conversations. Obviously, if you choose a weak key, they can just store the stream and crack it later.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#6>GET parameter Yes, it's convenient. But to tout that as what a well designed encryption scheme should look like? Nah.
It was a hash mark, only the client got that value (specifically JavaScript). Note how his page did not reload when he hit enter. Had it been a GET request, it would of refreshed.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#7>GET parameter Yes, it's convenient. But to tout that as what a well designed encryption scheme should look like? Nah.
From the link:
> In order to enable quick demos of the feature we allowed for e2ee keys to be passed to Jitsi Meet via a URL parameter.
> IMPORTANT NOTE: This is a demo of an e2e encrypted call and the feature is NOT YET intended for general availability, so play with it all you want, but, for now, in matters where security is paramount we still recommend deploying your own Jitsi Meet instance.
> As we already pointed out, passing keys as URL parameters is a demo thing only. Aside from being impractical it also carries risks given that URL params are stored in browser history.
> Our next step is therefore to work out exactly how key management and exchange would work. We expect we will be using The Double Ratchet Algorithm through libolm but the details are still to be ironed out.
They're not touting passing the keys in a URL parameter as a "well designed encryption scheme." They're presenting it as a proof of concept, and planning for the future work that they acknowledge is necessary.
Your comment is ill-informed and misleading.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#8Jitsi was the one Jabber client I used a few years back that I liked. I didn't find as many people on Jabber back then as I've seen elsewhere however. I believe you could use OTR alongside it, so you don't even need to trust them, just their implementation / version of OTR (a few more layers to consider I suppose).
I don’t think this is anything to do with the legacy jitsi xmpp/sip client, but the “jitsi meet” video conferencing app.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#9It'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 MITM on encryption? Especially since if you have their keys you already could.
Still, very cool technical demo, even if the odds of it displacing something like Zoom are near nil.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#10Ah, I they see they're using libolm, as is the Matrix project!
I have a number of critiques of libolm that I haven't developed into a practical attack, but are simple enough to fix (if you ignore the massive legacy support and backwards compatibility t̵r̵a̵p̵ ̵t̵h̵e̵y̵'̵v̵e̵ ̵s̵e̵t̵ ̵f̵o̵r̵ ̵t̵h̵e̵m̵s̵e̵l̵v̵e̵s̵ EDIT: see Arathorn's comment below).
Libolm is encrypting with AES-CBC [1]. In addition to side-stepping entire classes of attack (i.e. padding oracles), CTR would allow better performance: You can parallelize both encryption and decryption with CTR mode. With CBC mode, you can only parallelize decryption (but not encryption) since the IV for all but the first block is the previous block of ciphertext, which means you'll know the correct IV when decrypting but not when encrypting (since you have to calculate it sequentially).
Yes, they HMAC the ciphertext [2]. However, their variable name choice doesn't inspire confidence in its correctness.
Furthermore, they truncate the HMAC to 8 byes and attempt to justify the truncation by appending an Ed25519 signature, but that sort of configuration is just begging for a confused deputy scenario, like an old iMessage vulnerability [3]. It's no where near as bad (iMessage eschewed MACs entirely, this still uses a MAC, so it's not exploitable), but it's something that probably would make anyone working in cryptography (and any adjacent fields) give a confused puppy head tilt when they read it.
Regarding their ratcheting protocol [4]: Instead of feeding HMAC-SHA256 back into itself at each ratchet step, I'd feel way more comfortable if the protocol did HMAC-SHA512 and used one half of the output to derive encryption/authentication keys and the other half the ratcheting-forward key (instead of one HMAC-SHA256 for both purposes).
Using two distinct 256-bit secrets (even if they're generated from the same input at i=0) instead of reusing a secret strengthens the forward secrecy of the entire protocol.
HMAC-SHA256: One ring to rule them all (at any given ratchet step).
HMAC-SHA512-split: If you (against all odds) guess one of the keys, that doesn't give you the ratchet-forward key too, since they're two distinct keys (albeit generated deterministically from the same input).
Nothing I said above is exploitable, otherwise I'd be emailing their security team instead of posting on HN. :)
That being said, if the Libolm devs want to shore up the security of their protocol in a future revision, the following changes would go a long way:
1. Use HMAC-SHA-512 and split it in half for the ratcheting step of Olm/Megolm
2. Use AES-CTR instead of AES-CBC
3. Stop truncating MACs
[1]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...
[2]: https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e...
[3]: https://blog.cryptographyengineering.com/2016/03/21/attack-o...
[4]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...