3 ms·
> 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 appr
by hiq 7y ago
> 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?
- CiPHPerCoder 7y ago> 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).
- hiq 7y agoI see, thanks a lot!