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):
ctx = EVP_PKEY_CTX_new(local_key, NULL);
EVP_PKEY_derive_init(ctx);
/* Set digest to be used to sha256 */
EVP_PKEY_CTX_ctrl(ctx, EVP_PKEY_EC,
EVP_PKEY_OP_DERIVE, EVP_PKEY_CTRL_MD, 0, (void *)EVP_sha256());
EVP_PKEY_derive_set_peer(ctx, remote_key);
/* Compute shared secret and apply sha256 to it to get a usable key */
EVP_PKEY_derive(ctx, result_key, &result_len);
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.
On Sat, Jun 27, 2015 at 7:55 PM, Reinier Torenbeek <
reinier.torenbeek at gmail.com> wrote:
> Hi again,
>
> After digging into the ECDH code a bit more, I (sort of) found an answer
> to my question.
>
> My reason to look at using the KDF is to apply a hash to the shared
> secret to compute a useable key within the derive function. There is a
> control value called EVP_PKEY_CTRL_MD which seems like it could be used
> for this purpose. However, for EC keys it looks like this control value
> only has a meaning for the signing functionality, not for the key
> derivation functionality. This looks like an omission to me. A small
> test showed that it would not be too hard to have the hash applied when
> doing key derivation as well.
>
> If the approach sketched above is not right or possible, then exposing
> the KDF function to the user of the EVP API seems a logical alternative.
> However, the KDF function prototype is rather limited, with only an in
> and out and no context at all. The latter would be required to make it
> useful.
>
> Since this functionality looks like it is a kind of half-finished to me,
> can anybody give some insight in its status or confirm/correct my
> conclusions?
>
> Thanks,
> Reinier
>
> On 6/19/15 4:23 PM, Reinier Torenbeek wrote:
> > Hi,
> >
> > My goal is to implement ECDH in my own engine. The snippet below shows
> > the struct that needs to be filled and set as the engine's ECDH method:
> >
> > struct ecdh_method {
> > const char *name;
> > int (*compute_key) (void *key, size_t outlen, const EC_POINT
> *pub_key,
> > EC_KEY *ecdh, void *(*KDF) (const void *in,
> > size_t inlen, void
> *out,
> > size_t *outlen));
> > # if 0
> > int (*init) (EC_KEY *eckey);
> > int (*finish) (EC_KEY *eckey);
> > # endif
> > int flags;
> > char *app_data;
> > };
> >
> > I intend to leverage the KDF mechanism, but it does not seem to be
> > exposed in the EVP API. Is that possible at all? If yes, how do I do
> > that? If no, what is the purpose of the KDF() parameter in compute_key?
> >
> > (By the way, struct ecdh_method is in crypto/ecdh/ech_locl.h, which
> > seems to be a private header file. Am I supposed/allowed to include it
> > anyway?)
> >
> > Thanks in advance,
> > Reinier
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150627/519b68cb/attachment.html>
