This seems to confirm my understanding so far.
I did have the impression you have a good understanding of this based on your previous messages, but I think your wording was misleading and wanted to make clear for everyone else too that X3DH is not based on XEdDSA as a primitive - it's just what the Signal Protocol does.
Right, but that would leave 2 keys to be managed and authenticated, wouldn't it? Which wouldn't be very nice from a usability POV.
I did not really think yet about whether just verifying the signing key is enough, but this can easily be solved by defining what the OMEMO fingerprint is. Right now there is just the convention of displaying the bytes, but it could easily be defined to concatenation and hashing, again resulting in a single string.
But as I said, this was just an "if all else fails" solution, as it would also require patching of existing, audited libraries. It just skips the conversion part altogether, which seems to be the central point of discussion and is not widely implemented in any direction (if we assume option 1 of your summary as undesirable as 3DH breaks forward secrecy).
Unfortunately, the public key conversion part relies on low level operations AFAICT, so you'd need support from a library for practical reasons, wouldn't you?
I might be completely wrong, but from a superficial look in the libsignal-protocol-c code it seems like they used the operations NaCl provides (which they copied into their source tree at least partially), and did not implement those low-level operations themselves either.
Not sure about languages that are not C though. Regards _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
