Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proof of concept: end-to-end encryption in Jitsi Meet

jitsi.org

Post reply on HN
Print view View original

101–110 of 151 posts

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#101

Post by sigwinch28 »

Arathorn wrote: post #94
sigwinch28 wrote: post #64

Earlier quoted context omitted.

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.

Yes, my comment w.r.t. the hash is that it's inherently a bad final implementation because it's visible to the server via malicious Javascript.

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.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#102

Post by CiPHPerCoder »

tptacek wrote: post #73
CiPHPerCoder wrote: post #10

Ah, 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 e…

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?

> I do not understand your "confused deputy" attack. Can you outline it in more detail?

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.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#103

Post by tptacek »

CiPHPerCoder wrote: post #102
tptacek wrote: post #73

Earlier 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?

> I do not understand your "confused deputy" attack. Can you outline it in more detail? 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 atta…

Isn't it a little weird to tell people to do major surgery on a crypto design, especially in ways that depart from the well-regarded design they derived it from, on account of attacks that don't work against that design?

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#104

Post by CiPHPerCoder »

tptacek wrote: post #103
CiPHPerCoder wrote: post #102

Earlier quoted context omitted.

> I do not understand your "confused deputy" attack. Can you outline it in more detail? 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 atta…

Isn't it a little weird to tell people to do major surgery on a crypto design, especially in ways that depart from the well-regarded design they derived it from, on account of attacks that don't work against that design?

It's only weird if you put Signal's specific design decisions from 2013 on a pedestal and declare it perfect and incapable of being improved.

(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.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#105

Post by CiPHPerCoder »

tptacek wrote: post #95
garmaine wrote: post #77

Earlier quoted context omitted.

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.

It's like a standard padding oracle attack, but 4 billion times slower (on average) and requires 4 billion times more CPU work and bandwidth, and you have to be able to distinguish between a HMAC failure and a padding error.

(a.k.a. isn't happening)

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#106

Post by upofadown »

xiphias2 wrote: post #82
Arathorn wrote: post #58

Earlier quoted context omitted.

So E2EE key management has been a (very) long time coming in Matrix. Firstly: E2EE is pretty useless if you don't verify the identity of keys, as you could be just talking to a MITM (e.g. a malicious server admin could add a 'ghost' device onto your account in order to sniff the messages people are sending you). Originally (in 2016) we let users verify the devices they're talking to by checking their Curve25519 publi…

,, E2EE is pretty useless if you don't verify the identity of keys, as you could be just talking to a MITM (e.g. a malicious server admin could add a 'ghost' device onto your account in order to sniff the messages people are sending you).'' 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…

Perhaps it would be more illuminating to say that E2EE is mostly pointless if you don't verify keys. Then all you have to do is encrypt on the network links to get the same level of security for a lot of these things that claim E2EE as they have the power to do trivial MITM.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#107

Post by tptacek »

CiPHPerCoder wrote: post #104
tptacek wrote: post #103

Earlier quoted context omitted.

Isn't it a little weird to tell people to do major surgery on a crypto design, especially in ways that depart from the well-regarded design they derived it from, on account of attacks that don't work against that design?

It's only weird if you put Signal's specific design decisions from 2013 on a pedestal and declare it perfect and incapable of being improved. (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…

In addition to my previous comments, I also have a thing about reflexively suggesting that people eliminate CBC from their designs. Depending on circumstances, CBC can be a safer choice than CTR (and CTR-derived modes like the AEAD stream ciphers); different failure modes.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#108

Post by hiq »

CiPHPerCoder wrote: post #100
hiq wrote: post #66

Earlier quoted context omitted.

> 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 o…

I see, thanks a lot!

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#109

Post by xiphias2 »

upofadown wrote: post #106
xiphias2 wrote: post #82

Earlier quoted context omitted.

,, E2EE is pretty useless if you don't verify the identity of keys, as you could be just talking to a MITM (e.g. a malicious server admin could add a 'ghost' device onto your account in order to sniff the messages people are sending you).'' 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…

Perhaps it would be more illuminating to say that E2EE is mostly pointless if you don't verify keys. Then all you have to do is encrypt on the network links to get the same level of security for a lot of these things that claim E2EE as they have the power to do trivial MITM.

The point is that instead of requiring end users to verify public keys, it's better UX to give them the ability if they want, but not require. I remember an email standard that sent public keys inside the emails, and the replies are encrypted with that public key.

Sure, MITM is possible, but it's easy to detect, at the same time the UX is easy to scale to billions of people.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#110

Post by barbs »

sigwinch28 wrote: post #97
garmaine wrote: post #76

Earlier quoted context omitted.

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" In reality, I combine this with `nix-shell` and set it as a shell a…

Or you can download the Electron app here

https://github.com/jitsi/jitsi-meet-electron

Post reply on HN