Hi, I don't think this has much impact on the current discussion, but I'd like to come back to this for the record (and it may be relevant as an upgrade path):
On 31 May 2017 at 01:40, Chris Ballinger <[email protected]> wrote: > I don't have opposition to using Olm for any other reason than it will be > costly to rewrite all of the existing clients. Thinking about this a bit more, I don't think switching libsignal-based clients to use Olm (the algorithm) with split identity keypairs would cause a rewrite, or even lose any current identity keys. In fact, it would probably even less work than my first proposal for a key agreement compromise. I think the choice of terminology was making this sound worse than it was. What Olm (and the PR) calls the 'fingerprint key' and 'identity key' correspond in libSignal terms to 'identity key' (long-standing key, authenticated, never changes) and 'signed prekey' (a key that is signed by the authenticated key, and changed from time to time). With this terminology change, switching LibSignal-based clients to use Olm would require 3 local changes: - LibSignal's internal Curve25519 identity keys are converted to Ed25519 before publishing. (same as in my key agreement proposal). This is 1 extra call to a function (of which the code is already in libsignal) right before publishing the identity key, outside libsignal. - Signature verification is changed to use EdDSA instead of XEdDSA (same as in my key agreement proposal). This is a matter of changing one function call to another in libsignal (this function is already in libsignal) - Shared secrets are computed using 3DH on (signedPreKey, oneTimeKey_a, oneTimeKey_b) instead of X3DH on (identityKey, signedPreKey, oneTimeKey_a, oneTimeKey_b). This requires deleting 1 function call in libsignal. Applying these local changes should be enough to change any existing libsignal-based client into an Olm-compatible client. The difference with my first key agreement proposal is that this brings us back to a reviewed protocol (instead of a slightly modified libsignal one), and does not require adding the Ed2Curve conversion function to libsignal (all the required functions are already there). Remko
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
