Re: [openssl-users] How to provide KDF to ECDH key computation when using EVP API?
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
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to provide KDF to ECDH key computation when using EVP API?
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
Re: [openssl-users] How to provide KDF to ECDH key computation when using EVP API?
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.torenb...@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
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to provide KDF to ECDH key computation when using EVP API?
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
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
