<div dir="ltr"><div>Clarifying my intentions with a snippet of example code that I would like to end up with (omitting some lines as well as error checking for the sake of brevity):</div><div><br></div><div>    ctx = EVP_PKEY_CTX_new(local_key, NULL);</div><div>    EVP_PKEY_derive_init(ctx);</div><div>    /* Set digest to be used to sha256 */</div><div>    EVP_PKEY_CTX_ctrl(ctx, EVP_PKEY_EC,</div><div>        EVP_PKEY_OP_DERIVE, EVP_PKEY_CTRL_MD, 0, (void *)EVP_sha256());</div><div>    EVP_PKEY_derive_set_peer(ctx, remote_key);</div><div>    /* Compute shared secret and apply sha256 to it to get a usable key */</div><div>    EVP_PKEY_derive(ctx, result_key, &result_len);<br></div><div><br></div><div>This is all compilable and runnable code, but the EVP_PKEY_CTX_ctrl invocation is essentially ignored at this moment. Therefore the sha256 does not actually take place.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 27, 2015 at 7:55 PM, Reinier Torenbeek <span dir="ltr"><<a href="mailto:reinier.torenbeek@gmail.com" target="_blank">reinier.torenbeek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi again,<br>
<br>
After digging into the ECDH code a bit more, I (sort of) found an answer<br>
to my question.<br>
<br>
My reason to look at using the KDF is to apply a hash to the shared<br>
secret to compute a useable key within the derive function. There is a<br>
control value called EVP_PKEY_CTRL_MD which seems like it could be used<br>
for this purpose. However, for EC keys it looks like this control value<br>
only has a meaning for the signing functionality, not for the key<br>
derivation functionality. This looks like an omission to me. A small<br>
test showed that it would not be too hard to have the hash applied when<br>
doing key derivation as well.<br>
<br>
If the approach sketched above is not right or possible, then exposing<br>
the KDF function to the user of the EVP API seems a logical alternative.<br>
However, the KDF function prototype is rather limited, with only an in<br>
and out and no context at all. The latter would be required to make it<br>
useful.<br>
<br>
Since this functionality looks like it is a kind of half-finished to me,<br>
can anybody give some insight in its status or confirm/correct my<br>
conclusions?<br>
<br>
Thanks,<br>
Reinier<br>
<br>
On 6/19/15 4:23 PM, Reinier Torenbeek wrote:<br>
> Hi,<br>
><br>
> My goal is to implement ECDH in my own engine. The snippet below shows<br>
> the struct that needs to be filled and set as the engine's ECDH method:<br>
><br>
> struct ecdh_method {<br>
>     const char *name;<br>
>     int (*compute_key) (void *key, size_t outlen, const EC_POINT *pub_key,<br>
>                         EC_KEY *ecdh, void *(*KDF) (const void *in,<br>
>                                                     size_t inlen, void *out,<br>
>                                                     size_t *outlen));<br>
> # if 0<br>
>     int (*init) (EC_KEY *eckey);<br>
>     int (*finish) (EC_KEY *eckey);<br>
> # endif<br>
>     int flags;<br>
>     char *app_data;<br>
> };<br>
><br>
> I intend to leverage the KDF mechanism, but it does not seem to be<br>
> exposed in the EVP API. Is that possible at all? If yes, how do I do<br>
> that? If no, what is the purpose of the KDF() parameter in compute_key?<br>
><br>
> (By the way, struct ecdh_method is in crypto/ecdh/ech_locl.h, which<br>
> seems to be a private header file. Am I supposed/allowed to include it<br>
> anyway?)<br>
><br>
> Thanks in advance,<br>
> Reinier<br>
><br>
><br>
<br>
<br>
</blockquote></div><br></div>