Hi Remko,
So, I'm wondering whether it wouldn't make more sense to not carry the Signal legacy around in OMEMO, use Ed25519 keys as identity keys, and adapt X3DH to use these for creating an initial shared secret (with the same properties). The rest of the protocol can stay the same, since these keys can be converted to Curve25519.
You raise a valid point. I agree that this construction seems cleaner from a purely theoretical standpoint. However, I expect that implementors will want to use signal-protocol implementations for the cryptographic heavy lifting anyway. In fact several aspects of OMEMO are designed with this in mind, and to make reusing their code as easy as possible. All current implementations of OMEMO that I'm aware of are using signal protocol code. In that sense, changing this would actually make implementation quite a bit harder and probably less secure, because then people would have to reach down into the guts of the library and start patching things.
It can be done, but it's not a small undertaking, and I'm not sure it's worth it. Implementations of the signal protocol are available for many platforms, and they work really well. Both the signal protocol and OMEMO have undergone audits. I really don't want to change things here unless there are *very* good reasons to do so, and I don't currently see how this quirk would seriously hinder actual implementations.
Not to mention that doing this would make the migration to the new version significantly more painful, as all of our users would have to generate new keys.
Cheers, Andy _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
