[Standards] OMEMO and Olm

Sam Whited sam at samwhited.com
Fri May 26 17:37:03 UTC 2017

On Fri, May 26, 2017 at 12:15 PM, Remko Tronçon <remko at el-tramo.be> wrote:
>> crypto is subtle, and it can be very easy to make mistakes that have
>> catastrophic consequences.
>> ...
>> I haven't finished or tested it yet
> This doesn't really give me much more confidence to be honest.

Fair enough; the point is that I got enough done to think that Andy is
right that the subtle crypto is handled for you; and XEdDSA is mostly
just plugging up ed25519 and curve25519 implementations. Of course,
doing *any* crypto comes with risks (distribution is a problem I'll
ignore because that's so specific to the ecosystem you're using and
isn't something we need to concern ourselves with, I think), but I
think the risks in this case are "your implementation will be broken",
not "your implementation will leak information or allow invalid
signatures". I may be wrong, of course, frankly, I have no business
analyzing or arguing about crypto, I'm just relating my experience
trying my hand at an implementation with enough knowledge of how to
write good crypto to hopefully not screw it up too badly.

The code base where I would add this if I did complete it is audited
periodically, so I'll see if they'd accept a patch in which case maybe
someone will tell me if there's more too it than I think.

>> If you already have an ed25519 imlementation
> Doesn't the spec say that you shouldn't rely on ed25519 implementations
> for verifying signatures?

Not that I see; it makes things a lot slower if your keys are
generally in montgomery format because you have to do the extra scalar
multiplication to convert the keys though, so you might not want to
entirely delegate and convert keys back and forth every time. For my
purposes this didn't matter because the API already uses all keys in
edwards format (so you'd just have to do the conversion when the key
came in over the wire or when you were sending an identity key back

> Ed25519 signature verification easier to grasp than X3DH.
> But maybe there's a  security implication that makes the latter better?

I'm not sure why it would be easier; they seem roughly the same to me,
but I'm not expert. As far as I'm aware there are no security
implications to using one over the other.
Using the same key (for me at least) is no more than a convenience;
certainly nothing I'd hold out or fight for, but it makes my libraries
API nicer (one type that the ECDH code and the sign/verify code can
take). It's not that big of a deal either way as far as I'm concerned.


More information about the Standards mailing list