Proof of concept: end-to-end encryption in Jitsi Meet
jitsi.org
jitsi.org
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.
Which can be sometimes dangerous as more and more crypto is designed to be set-and-forget. It leaves the windows open for bad actors to exploit such simplicity and introduce backdoors when no-one was looking. Vigilance in managing keys (and integrity of the cryptosystem) is still required.
Cryptographic theory breaks down at the UX layer. If you try to improve security by cycling passwords too frequently, users start writing them on sticky notes tacked to their monitors. If you require users to keep their private keys in their own possession, users lose their private keys, get angry when you can't reconstitute those keys for them, and go use a service that can offer that feature.
I think there's a reason the entire ecosystem has moved in the direction of trusted actors who could, in theory, exploit that trust to know everything they can about the signal passing through their trusted zone (with those who trust nobody still operating independently as a fringe minority).
If it did, you can pretty much guarantee people would either stop using house keys completely and just leave the key in the lock all the time or would come up with schemes to make it impossible to lose the key (such as locking the key in a tiny box, and then that box is secured with a key that doesn't cause the box to burst into flames if the second key goes missing).
In non-digital life, we make the tradeoff of less-than-perfect security for convenience, backed by the law (i.e. any competent locksmith can break into your house, and the things that keep them from doing it are (a) a general societal understanding that cracking open someone's front door without consent is a really dick move, and (b) if you do it, you're trespassing and can go to jail).
Jitsi might have an additional challenge in that their URLs are often human-readable and user-picked, so not everybody might be used to copy-pasting the links, but then they have the advantage of encryption probably being optional. Or they might think of a whole other solution that provides good UX that doesn't require users to manage keys. (Which, again, might be optional anyway.)
Of course it's still better than the default, since your data sent at time t_A won't be compromised by an attacker compromising Mozilla's servers at time t_B with t_A < t_B (well, you try to retrieve your data and they steal your passphrase by serving some new JS code).
> 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.
I understood that you meant that Firefox Send solves this problem and does not handle users' keys. My point was that the trust model is still the same, so you might as well just stick to the current model where you already trust Jitsi. Firefox Send solves the UX problem because it doesn't completely address the encryption key handling problem.
To be fair, I still think Firefox Send is slightly better than traditional file hosting, just not significantly.
Note that I'm not saying that that's necessarily the best solution; just that I don't believe that
> You can't solve the UX on that
is true, i.e. that there's nothing particularly inherent to the problem that results in there being exactly 0 good solutions to it.
There's nothing technical to prevent Firefox Send from using a native client instead of a web page. The client could have the same trust model as everything else on your system, while still embedding the key into the final URL or link you share with other users.
It wouldn't even need to be complicated -- a wrapper around libsodium that pushed encrypted data to a couple of REST endpoints would do the job.
That said, agreed that it's a massive and (up to now?) unsolved problem for how to get mainstream users to manage their keys sensibly. Keybase could have gone there, but ended up being poweruser-only. It'll be interesting to see if we've solved it in Riot.
Docs (the first link is most relevant to your question):
https://github.com/matrix-org/matrix-doc/blob/master/specifi...
https://matrix.org/docs/guides/end-to-end-encryption-impleme...
https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/ol...
https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...
Personally I liked the flow of knowing a shared secret to a private channel back when people were doing blowfish in IRC was way better than this exponential key exchange thing.
Sure it's not as secure, but at least it's somehow humanly feasible.
Originally (in 2016) we let users verify the devices they're talking to by checking their Curve25519 public keys out of band - e.g. "s5jZ K5a/ 4iAN If7K L0PL XNNG h/4G 901H +dB6 YMB9 1H4". This is obviously completely unusable, and precisely the sort of terrible UX which made the great-grand-parent say "individual users don't want to be arsed to self-manage their encryption keys; You can't solve the UX on that".
Then, we improved things a bit (in Feb 2019) by adding the ability to verify devices by comparing a list of 7 emojis out of band - you calculate a shared secret via ECDH between the devices. This is specced in https://github.com/matrix-org/matrix-doc/issues/1267 and analysed in https://www.uhoreg.ca/blog/20190514-1146. This solved the problem of comparing ugly public keys and made verification actually fun (imagine people yelling 7 emoji at each other across a room, or over VoIP etc, to verify identity), but meant you still had to verify each new device manually, which gets very tedious very quickly.
We have finally fixed this over the last N months, which is what I was talking referring to in the previous post.
Firstly, when you sign into a new device, as part of login you have to verify that device's identity with an existing one (or enter a recovery code/passphrase) - a bit like 2FA. Then, every user who has verified you in the past will automatically trust this new device - you have effectively vouched for its veracity yourself. We call this cross-signing, and it's specced at https://github.com/matrix-org/matrix-doc/pull/1756.
Secondarily, we've added QR-code scan based verification (https://github.com/matrix-org/matrix-doc/pull/1544) - so the actual login process here ends up feeling similar to WhatsApp Web: the user just scans a QR code on their new device, and hey presto: all other users who have ever verified your identity in the past will magically trust your new device.
We're hoping that between QR/emoji-based verification and cross-signing we've ended up with a UX which will let non-technical users transparently manage their keys without really realising it (as it will boil down to "scan this code to log in" and "scan this code to check you're not being intercepted").
The expectation is to turn this on by default in Riot and launch it this Thursday (fingers crossed). And in future, Jitsi could use the same identity/key-management model to ensure that you're actually talking to the people you think you're talking to in their shiny new E2EE conferences.
https://github.com/uhoreg/matrix-doc/blob/cross-signing2/pro... has the details from the implementor's perspective.
See also https://github.com/uhoreg/matrix-doc/blob/cross-signing2/pro...
EDIT: in theory you could also rotate all keys from a client by creating a new master signing key and then re-publishing all your existing cross-signing signatures with the new keys. This sounds like quite a good way to grandfather in untrustworthy attestations though; it might be safer to start over. The current implementation doesn't support this.
This is just not true. The amount of passive listening is so much more than the amount of MITM, as most middle men don't want people to know that they are listening. It's just too easy to catch them if they do it on a massive scale, as long as just 0.1% of users verify the E2E keys. This way the remaining 99.9% gets a part of the security benefit as well.
My point was that to mitigate both attacks, it's vital to verify key identity out of band. I agree MITM is much less likely than passive listening via a ghost device: we haven't seen MITM in the field, but we have seen attackers try to add ghost devices to spy on accounts (by acquiring a login password, adding a new device, and hoping the victim doesn't notice they've sprouted a new E2E device and that nobody verifies devices).
Sure, MITM is possible, but it's easy to detect, at the same time the UX is easy to scale to billions of people.
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.
In the end it is all about making something that people will use because it provides what they need in a broad sense covering security, usability, video quality and a lot of other things.
I also disagree with your opinion that "you can't solve the UX on that". The tech demo here essentially gives the same UX as Zoom call + passwords, but with actual end-to-end encryption.
There is the notable caveat in this tech demo that client-side scripts can still read the key (we have to assume the javascript that can read the URL hash is friendly).
Really, though, this can be solved: provide a native(ish) app even if it's just an Electron wrapper of the existing static assets and javascript code, register a handler with the OS for `jitsi://`, and use links like `jitsi://server.name/room#e2ekey=foo`, so we only have to trust the code on our machine, not the server.
I really hope that it can be as simple as "share a password with someone"/"send an invite link to someone" because as the parent effectively said, this would be a complete UX nightmare.
However, it's not a hard requirement that the server delivers the javascript to us: it could be hosted locally, e.g. a trusted Electron wrapper around a set of HTML/CSS/JS stored on my computer, for some definition of trusted.
This is how a lot of other e2e-encrypted messaging app can be used, e.g. Signal, WhatsApp, Riot.im: a "trusted" set of client code over which the untrusted server has no control.
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 "impossible" to solve, is exactly that.
... 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).
But then doesn't the Jitsi web server have to access password when you enter it on their website/have it in the link? Nope! It looks like they're putting the password in an anchor fragment in the URL, which is not sent to the web server [1]. So all encryption/decryption is being done client side (and is therefore real end-to-end encryption).
Yes, it's possible the web server is sending you evil JavaScript that is extracting your password anyway, but at least that's something you can in principle check. For all end-to-end encryption to work, you have to know your client is not compromised.
The web already has the world's most widely used public key infrastructure. When I go to amazon.com, I can be confident that my browser is talking to a service operated by Amazon, with nobody spying on or modifying messages in flight.
However, I have zero guarantees regarding the HTML/CSS/JS that service returns. It can return code modified for me specifically, different from what any other user of that app is running. For traditional server side rendered web apps, this is normal and expected. SPAs often return identical app resources for every user, and all user specific data is later transmitted via API calls... but nothing in the web enforces this.
For decentralized or end-to-end encrypted apps, this is very bad. Most Ethereum apps today, for example, are used primarily via Metamask browser extension. Nothing stops an operator of such an app from just serving a different, malicious version to one specific user, based eg on IP. Such a compromise would be very hard to prove.
Similarly, Jitsi might like to give users confidence that they are running the same code as everyone else, and that the code is logged, versioned, and open to security analysis.
In principle, an approach similar to Certificate Transparency could provide this kind of assurance.
For this to really work well, they would also have to practice good dependency hygiene and ship unminified bundles.
--
This is an important web primitive that's currently missing. Do any browsers have a solution somewhere in the pipeline?
Maybe you mean to compare it to a copy that has already been audited by someone else? Then you might as well use the auditor's web server to get the client (and you can do this because Jitsi can be self-hosted). So I think it just comes down to connecting to web servers run by people you trust, since HTTPS already takes care of integrity checking.
1. Signing with an offline key, so an attacker can't make a release just by hacking the web server, and the key doesn't end up on however many hundred CDN web servers around the world.
2. Clear boundaries between releases, and a slow enough release schedule that third-party auditors can keep up.
3. Non-repudiation, so users know everyone else saw the same version they saw.
4. Reproducible builds from code in a public repo, so third-party auditors know what was released is what they reviewed.
5. An update process that verifies 1-3 before applying an update.
These requirements are fundamentally incompatible with webapps - where a no-questions-asked software update is only a press of F5 away, by design.
If by "webapps" you mean "applications that run inside a web browser" then I disagree, since it is possible to pin a specific (presumably third-party audited) version of a webapp by using a static local bookmarklet or saved file. See my other comment [1].
You're right, though, that this is not the typical user experience for a web app, and you might reasonably believe that all webapps should be visibly associated with a domain on the internet.
Personally I think it is acceptable if a high security webapp requires a slightly less convenient UX compared to normal webapps. Nevertheless, it should still be quicker and safer to "install" a bookmarklet than install a native application like the Tor Browser.
Agreed that it feels like there should be another mechanism to publish subresource integrity hashes for your own resources somewhere so that people can spot if your server or TLS gets compromised though (similar to CT). Sounds like someone else had the same idea at https://lists.w3.org/Archives/Public/public-webappsec/2014Ju... - I wonder why it didn't go anywhere?
Meanwhile, if you don't want to trust TLS or the host which originates the code, then for now you're probably better off using a desktop app (e.g. electron, although that comes with a whole different attack surface) or a browser extension which can be distributed as signed code.
The trick was discussed on Hacker News some time ago[1], but the basic idea is to use a bookmarklet (or saved local page) which contains a single <script> tag with an integrity hash baked into it. The loaded script (once the hash check passes) then acts as a bootloader for all the other resources that it pulls in, eval'ing them only if their hashes (or perhaps signatures) match a hardcoded list (or public key).
Of course there are some UX issues with this, such as the location bar not containing an actual domain (and reassuring padlock), although it might be possible to fix this depending on how the proposed <portal> tag[2] interacts with SRI. Also, the process of creating the bookmarklet is more awkward than just clicking a link, and it may have to be repeated every time a new version of the webapp is released (or rather, when the new version has been audited by one or more trusted entities).
https://www.reddit.com/r/crypto/comments/42kzx1/thoughts_on_...
Unfortunately it relied on the HPKP Suicide technique, since otherwise a compromised server could send a malicious update to the service worker code. Now that HPKP has been abandoned by browsers, WebSign is no longer viable (and it always required you to trust that the server really was throwing away its private keys).
As for the question of "why", it seems like you are asking either "Why would someone choose to write/use a webapp when they could just write/use a native app instead?" or "Why would a webapp developer/user care about the threat model of a web host being compromised?". Both of those questions have reasonable answers for at least some non-zero number of webapps.
1. Rather than simply prevent an attack, it shows a scary warning that compromised code will be run on the next reload, and
2. It relies on things that aren't intended as security features, and so is inherently more fragile than it was originally. In particular, if an attacker could fill up enough of a user's disk space, some browsers may just evict the WebSign instance.
We recommend that regular users of Cyph install the desktop and mobile apps, but it's at least a reasonably safe solution that significantly improves usability.
Otherwise, you'll want a way to ensure that only devices belonging to users you've explicitly invited are able to participate (and you'll want to keep the secret evolving for forward secrecy, as amusing as it'd be for you to invite your sysadmin to a conference, only for him to go and decrypt the conversation prior to him joining to find out what you were saying before he came in...) - and this require key management to track who's who and who's trusted.
However, I'm wondering if anyone on here has become, or works somewhere that has become, a customer of 8x8 [1], the company behind it [2]? They supposedly support Jitsi primarily to 1) get contributions that also make their product better and 2) to advertise their product. I'm somewhat worried about whether 2 is working, and hence whether Jitsi will continue to receive their support.
(I'm not affiliated or anything btw, just a happy Jitsi user.)
https://github.com/jitsi/jitsi-meet/wiki/Jitsi-Meet-Instance...
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\""
I don’t even install anything derived from Chrome in my computer, and I’m not going to change that policy.
Please be aware that aside from E2E demoed here, there is allegedly a Firefox-specific bug regarding WebRTC which degrades performance for all participants in a call: https://community.jitsi.org/t/software-unusable-on-firefox-w...
Yes, our Firefox support has not been great, but we are working on making it better: https://github.com/jitsi/jitsi-meet/issues/4758
> Desktop sharing? Chrome plugin.
This was a browser limiation, which is no longer needed since about 2 years ago.
> Desktop client? Chromium/Electron.
You need to ue it! Use the browser, or the mobile apps.
You're right that screen sharing does seem to work in Firefox! Thanks for pointing that out. It looks like FF on my Linux box is blocking it, but I guess that's a permission issue I need to fix locally.
The ability to do E2EE is kind of a big deal, even though insertable streams can be used for other things, so we hope other browser vendors join the effort.
There have been other approaches in the past such as PERC [0] and ongoing related ones like MLS [1], this is a relevant topic these days.
[0]: https://datatracker.ietf.org/group/perc/documents/ [1]: https://datatracker.ietf.org/wg/mls/about/
Other Hetzner and many OVH offerings have traffic caps, but these are in the region of ~10TB/month.
It seems clear that there has to be a single key, rather than separate keys for each pair of participants, since in a large meeting we need all video streams running through a server and everyone receiving the same streams, for manageable upload bandwidth. Also, many participants often cannot peer directly due to NAT etc.
But therefore... as long as you're trusting the server with key distribution/management in the first place... don't you necessarily have to simply trust that the server isn't peeking? That by necessity, since anyone else can join the call and get the decryption key from any of the peers... that the server can too, whether by MITM attack, a "fake participant" that joins for a millisecond but doesn't appear in UX, etc.?
That unless you actually have the capability of auditing the server and the code it's running, E2EE doesn't actually give you any concrete guarantees whatsoever? You've just got to trust? Which at the end of the day, is no different from trusting them not to peek at transport encryption?
Of course you can run your own Jitsi server. But if you've already got control over your servers then you might as well just be using transport encryption anyways, since you trust yourself -- right?
(Obviously if you come up with your own keys and send them to participants via a separate channel of communication then it's fine -- but obviously that's not something regular users are ever going to do.)
Would love to know if I'm misunderstanding something here -- if the newfound significance of E2EE in videoconferencing is just due to Zoom falsely advertising it, or if it's actually a realistic goal.
Upload bandwidth isn't so much of a problem with the number of participants, as you of course wouldn't encrypt the whole data stream separately for each peer. Instead, you would encrypt it with a rotating symmetrical key that you can then safely exchange with all peers (at negligible bandwidth cost). You would still depend on the server to replicate your encrypted stream (and do NAT traversal etc), but it wouldn't be able to peek inside.
A separate problem is that you usually want your server to actually create reencoded video of your stream for participants with bad internet. There's potentially some ways to do that without server involvement with some clever video encoding (so that instead of reencoding you can just throw away some chunks), but afaik there's nothing production ready for video codecs here.
Why is this the case? Watching streams on Twitch or YouTube with HTTPS are all encrypted individually for each connection. It's not like TV or radio where you have to broadcast the same thing to everyone.
> But therefore... as long as you're trusting the server with key distribution/management in the first place... don't you necessarily have to simply trust that the server isn't peeking?
I think you're right that you'll need to trust key distribution. Some companies might actually have PKI set up properly and can do this. Other individuals who are particularly privacy conscious may also have this. Just because verifiable E2EE might not be applicable to a mass market doesn't mean it's not incredibly useful for those who do need it.
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.
* How do you handle non-encrypted participants (e.g. people dialling in from the PSTN?)
* Up until this week, you haven't been able to intercept WebRTC streams for doing E2EE if running in-browser. (Zoom however doesn't use WebRTC, so they don't have this excuse).
* Do you have a safe place to store the keys, and manage user identity?
If all you have is the URL, then the server sees the encryption key.
Video conferencing also rarely has users register. So there isn't a way to validate users either. And even if they did register and users didn't care about the extra friction, multiple devices means either the server stores your private key, or you have many keys which is much harder to verify.
E2EE is much easier on phones, which is why Signal is so good. The identity is your phone number, and you can only have one key associate with your number. That key never leaves your device. Conceptually easy.
Video conferencing has none of those advantages, and I don't know how you would make it conceptually easy for users without reducing the security.
> If all you have is the URL, then the server sees the encryption key.
Not necessarily. It's possible to put the key after a "#" in the URL, which allows client-side code to use it without sending it to the server. This technique is used at ZeroBin, among other places. (Edit: This is actually done in the video in the OP as well.)
So perhaps you just give up on persistent identity: just have an unencrypted waiting room, the organizer and their delegates can approve people in the waiting room to enter the encrypted conference.
On the face of it, this could work quite well for most people.
However, over time people who built WebRTC systems (like jitsi or zoom) realized that end to end encryption makes multi-party chats hard. The basic issue is that you don't want to burden end points with sending the video streams to all users. Think about tens or thousands of users.
So the way they used WebRTC was changed. The mandatory end to end encryption was circumvented by connecting to a central server. This entity then could forward streams to as many people as you want. Also, most times people don't need a HD video of someone. A small thumbnail is enough, think of a screen filled with 10 thumbnails of your users. The downsampling of the video stream can happen on that central box. The downsampling was enabled with simulcast mode, but even then it still requires more bandwidth, while insertable streams will enable WebRTC applications to put a second layer of encryption over the encryption provided by the user angent. That second layer can then reach to the actual other end of the communication, as key management is exposed to the entities.
The sad twist in this story is that the desire to make the encryption very inflexible so that it's surely not circumvented made it impossible for people to amend it so that SFUs work... leading to people disabling it altogether.
Dumb question: Can't you choose one video encryption key K, use ten thousand individual secure connections (with different keys) to share K with all the other users, then encrypt your video with K and let central servers mirror it all they like? (Could even have other clients do some mirroring, bittorrent-style.) Regarding downsampling: if the client has only enough CPU and bandwidth to put out one stream, then, yeah, that doesn't work very well, but otherwise you could put out multiple streams (all encrypted with K) of different quality.
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...
The primitives can be changed though once there's enough evidence to do so, and Matrix supports pluggable E2EE algorithms as per https://matrix.org/docs/spec/client_server/r0.6.0#messaging-... - so I'm not convinced this is a "massive legacy support and backwards compatibility trap" that we've set for ourselves.
What don't you like about the variable names at https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e... ?
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 output on line 89 made me have to reread the function twice to figure out what was going on.
Yup, indeed. https://signal.org/blog/the-ecosystem-is-moving/ was written after I mailed him to ask if they'd consider interop. (https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom was our overdue response)
https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03
It's fast and constant-time even on mobile devices (where AES is often variable-time or slow due to a lack of AES-NI).
> 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 for 1:1 conversations (and small groups). I understand how Matrix wants to address big groups and thus need Megolm. Where does this leave Olm?
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).
I do not understand your "confused deputy" attack. Can you outline it in more detail?
(a.k.a. isn't happening)
I'm literally referring to "the iMessage attack".
If you recall, iMessage did ECDSA(AES(m, ek), sk) without an intermediary HMAC. Libolm does have an (albeit truncated) HMAC, so the attack doesn't apply at all here. But it's still a design smell.
If I could extend their construction (which looks like the setup to the iMessage attack, without the punchline) into a real attack, I would have just disclosed it to them and not commented publicly.
How the attack I envision would work if their HMAC suddenly got erased from the protocol: Establish a multi-device setup, flip bits in ciphertext you want to decrypt, sign with Ed25519, observe padding oracle.
(A truncated HMAC does prevent that in the real world, but at a 32-bit security level rather than a 128-bit security level.)
These are (somewhat nitpicky) design critiques, not security vulnerabilities. :)
Edit to add: Also, the iMessage attack had some other weirdness that isn't relevant for what I'm describing, but was very relevant for iMessage being broken.
(N.b. I don't expect my specific suggestions to be adopted. However, I view complaining without offering solutions to be poor form, so I offered some alongside my complaints.)
Of course, any deviation from Signal's design can and should be vetted by the same experts that vetted Signal's. And if they're unavailable to vet the derivations, the conservative thing to do is grit your teeth and bear Signal's legacy until they become available.
However, if Signal still targets Android 4.4 phones in 2020, there's a lot of devices without AES-NI and thus improving upon their AES-CBC design decision is worth probing at least.
I was an 8x8 customer for about 10 years as a small/medium business. I would never buy from them again. I now use Zoom, but am considering switching given the recent privacy revelations.
Here was my 8x8 customer journey. Stick around - at the end I highlight their shifty auto-renewal contracting practices and dark patterns to force you to stay.
2011-2015:
Around 2015 or so through about 2019:
2019 Q1 thru Q3 Porting phone numbers to Zoom was really easy. It requires about 1-2 weeks of paperwork and processing time (no matter who you are porting numbers with I think this is the default). However - 8x8 tried to block the transfer for about 20% of our numbers, saying that the information we provided was incorrect. After days of back and forth, all the while our numbers were unavailable for use and causing operational problems, the case was escalated and resolved, simply because a new person read the original forms we submitted and processed it correctly.
On the 8x8 contract & account management dark patterns:
Multiple times in 2018 I requested my account manager offer new pricing, as our rates had doubled from $25/number to $50/number in just 1 year. The cost was out of control. They never did offer pricing, but continually played the Car Salesman move of "Let me see what I can get my finance department to approve", come back with a meager 5% discount, rinse, repeat... The account manager would passively threaten that they will take my account to month to month, "but the pricing controls will no longer be in place and your rates could rise". Big deal, I thought, my rates are already skyrocketing!
Multiple times in 2016-2018 I wrote to them asking if I had an auto-renewal. They would not answer this question over email, but instead forced me to call in.
When I called in ("...to a recorded line, for quality assurance purposes..."), they would tell me I did have an auto renewal in August each year for 12 months. I would tell them over the phone to mark that I wish to cancel my auto renewal and continue on a month to month basis. I would follow up with my 8x8 Account Manager that I was told over the phone by the 8x8 Billing Representative that my company did not have an auto renewal. My account manager never acknowledge these messages.
2019 Q3:
I've come to expect garbage contract patterns from legacy companies. However... THE WORST PART ABOUT THIS in my opinion was that calls 1 through 11 to 8x8 customer support and billing to resolve this were not successful, in my opinion, because I was being very nice and understanding to the support person on the other line. ONLY when I started threatening legal action, "I do not care what the script is telling you to say, I must talk to a manager", etc, did I get someone to waive these cancellation fees and allow me to transfer my numbers.
I have done customer service oriented work, I understand the drain it can have on people. I try to be overly nice to anyone I have to call into because so many people are abusive to the support agents trying to assist them. But at the end of the day, wether its Apple or 8x8, the only success I've had at getting what I need in situations where the company is clearly playing hide-the-ball, is to be threatening to the minimum wage worker on the other end of the line.
And that is my take away - you can tell a lot about a company from how they arm (or bind & toss overboard) their front-line support agents to deal with a terminating customer contract.
Jitsi is the same project it was when it was run by an independdent company. It's the same project it was when Atlassian acquired it, and continues to be the same project now at 8x8.
It's Apache 2 licensed, and you are more than welcome to use it without dealing with 8x8 at all.
Disclaimer: I'm a Fellow Jitster at 8x8.
Yes, it's convenient.
But to tout that as what a well designed encryption scheme should look like? Nah.
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.
> 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.
After about an hour the audio completely fails. No audio in. No audio out. I can't really tell if it's something with the app or if it's my terrible little dsl router/nat box dropping the audio stream. I don't have this problem on the desktop or laptop clients, just the iPad, so I'm guessing it's the app...but it could be that it works differently on the network.
Anyone see similar?