ECDH, early capabilities, etc.
ijackson at chiark.greenend.org.uk
Mon May 1 16:40:14 BST 2017
Mark Wooding writes ("Re: ECDH, early capabilities, etc."):
> Some notes of my own.
> * The `@@@' commits are for my own use, and not intended for upsteam.
> I planned to filter them out before sending a formal pull request.
> That said, if anything in there looked interesting, I'd be happy to
> tidy it up.
I'm happy to have ad-hoc testery in tree, if anyone else is likely to
be able to run it (perhaps after a bit of hacking).
> * You didn't remark on the binary-safe DH public transmission. I'd
> ordered this somewhat oddly, so as to allow either (a) hex
> transmission only, or (b) binary transmission for the new DH groups.
> In the latter case, I could undo the factoring out of the hex
> encode/decode functions (but I think that's worth having anyway).
> If you prefer (b), then I'll sink it below the XDH integration.
I'm not sure I follow. You mean
Adjust the DH closure protocol to handle public values as raw binary
That seems to move the hexification and nul-termination into the dh
... oh wait. I didn't read far enough.
I see no reason to offer hex-encoding of the new groups. I don't
think it's worth doing the work to get rid of hex-encoding for Zp
groups in a compatible way.
So yes I think that patch would be better off earlier in the series,
and the parts that affect xdh squashed into
xdh.c: New module defining elliptic curve Diffie--Hellman functions
Is that what you mean ?
Ian Jackson <ijackson at chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
More information about the sgo-software-discuss