Hello Jakob,
> How does this all compare to the EVP API for traditional
> DH?, I think this is a closer equivalent for API design
> than ECDSA.
Good point. For traditional DH, no Key Derivation Function is mentioned
anywhere. It has a larger associated set of methods (see below) than
ECDH, but the compute_key() function in particular is simpler.
So this does not look too good for my case...
Reinier
struct dh_method {
const char *name;
/* Methods here */
int (*generate_key) (DH *dh);
int (*compute_key) (unsigned char *key, const BIGNUM *pub_key, DH *dh);
/* Can be null */
int (*bn_mod_exp) (const DH *dh, BIGNUM *r, const BIGNUM *a,
const BIGNUM *p, const BIGNUM *m, BN_CTX *ctx,
BN_MONT_CTX *m_ctx);
int (*init) (DH *dh);
int (*finish) (DH *dh);
int flags;
char *app_data;
/* If this is non-NULL, it will be used to generate parameters */
int (*generate_params) (DH *dh, int prime_len, int generator,
BN_GENCB *cb);
};
On 6/30/15 11:48 AM, Jakob Bohm wrote:
> On 28/06/2015 04:55, Reinier Torenbeek 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?
> How does this all compare to the EVP API for traditional
> DH?, I think this is a closer equivalent for API design
> than ECDSA.
>>> (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?)
> Unfortunately, someone thinks that OpenSSL should be made
> as useless as possible, strangely, this all began shortly
> after the heartbleed backdoor was closed.
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150702/3d23dbdd/attachment-0001.html>
