ECDH, early capabilities, etc.

[Ian Jackson]

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.

-- 
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.