Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 output on line 89 made me have to reread the function twice to figure out what was going on.



> Moxie isn't ever going to acquiesce on the points he's stubborn about

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)


If you're open to changing the protocol, might I also recommend XChaCha20-Poly1305? :)

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


His eponymous talk on 36C3 was similarly disappointing, mostly defending stubborn choices. Glad I didn't decide to spend the time watching it in person and got to see another talk by watching this one back instead.


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


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


I see, thanks a lot!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: