On Fri, May 26, 2017 at 12:15 PM, Remko Tronçon <[email protected]> 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 out). > 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. —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
