ECDH, early capabilities, etc.

Ian Jackson ijackson at
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>   These opinions are my own.

If I emailed you from an address or, that is
a private address which bypasses my fierce spamfilter.

More information about the sgo-software-discuss mailing list