On Sat, May 27, 2017 at 3:41 PM, Remko Tronçon <[email protected]> wrote: > And you got all this just by looking at the XEdDSA spec? Maybe to you this > is trivial, but I don't understand how parts of the pseudocode in the spec map > to the code you wrote (e.g. the ScCMove bit is pure magic to me, I would > never have come up with that). I still consider this way out of the comfort > zone > of mere mortal developers like me.
Oh pardon me, that was a poor choice of words, I didn't mean to suggest that it's not tricky (it took me several readings to understand what was going on, and I was very confused and had to ask Andy for advice several times). I wanted to show that if you already have a crypto library that implements ed25519, doing the key conversion is only a few extra lines of code and isn't an insurmountable barrier (though it does certainly help to know a bit about the underlying operations; eg. CMov is an operation that copies data if some condition is true, but without actually branching, which makes things a lot faster). If I can dig in and get a working implementation in a day or two, someone who really knows what they're doing could have done it much quicker without taking so much time to study the spec (this is the sense in which it's "trivial"). The important thing is that, I think (again, we'll see what the review looks like), this shows that if XEdDSA is used that new implementations can be created under whatever license without a huge amount of hassle; now we can try to make up our minds about which is a better alternative without worrying about licensing (I hope). Personally, I've gone from more or less in the middle to leaning towards Andy's line of thinking: implementing the key conversion is a minor pain compared to transitioning existing clients to the Olm based version of the spec. I see no technical benefits to either approach that sway me as much as the amount of work that I suspect it would be to move the two Pidgin plugins, Conversations, Gajim, the existing work on ChatSecure or ZOM (or whatever it's called now), Dino, and maybe others over to a new spec. I'd love to be proven wrong though; I'd much rather be be deciding based on purely technical arguments about which is faster/safer/etc. Maybe someone should try to port one of the complete implementations over and see how difficult it is? —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
