Re: Fwd: Converting public part of 'EVP_PKEY' structure to 'unsigned char*' , and back.
We do the below for this operation:
1How we convert public part of 'EVP_PKEY' structure to 'unsigned char*
//Extract a public key from a PKEY struct.
ec_copy_public(EVP_PKEY *pKey, uint8_t *keybuf)
EC_KEY*pEcKey;
uint8_t encoded_key[MAX_KEYLEN_X962];
uint8_t *pMem;
int keylen = 0;
/* Get the EC_KEY struct pointer. */
pEcKey = (EC_KEY *)EVP_PKEY_get0(pKey);
/* Extract the private key from the EC key struct. */
if (pEcKey) {
pMem = encoded_key;
keylen = i2o_ECPublicKey(pEcKey, pMem);
/* Copy the decoded public key into the provided buffer. */
if (keylen) {
keylen = ipsec_ec_x962_decode(pEcKey, encoded_key, keylen, keybuf);
//fn defined in the end
}
}
}
2How we get the peerkey to pass to EVP_PKEY_derive_set_peer(pctx, peerkey);
//The below function takes a character string as input and converts it to a
public key.
Prototype:
EVP_PKEY *ec_create_static_public(uint8_t *public_key, int keylen, int curve)
EC_KEY*pEcKey = NULL;
EC_KEY*pEcKeyTemp;
uint8_t encoded_key[MAX_KEYLEN_X962];
const uint8_t *pMem;
EC_POINT *pEcPoint = NULL;
BIGNUM*pBignum = NULL;
EVP_PKEY *pKey = NULL;
switch(curve) {
case NID_secp384r1:
pEcKey = EC_KEY_new_by_curve_name(curve);
break;
default:
pEcKey = NULL;
}
/* Encode the public key string into X9.62 format. */ defined later
ec_x962_encode(pEcKey, public_key, keylen, encoded_key);
pMem = encoded_key;
pEcKeyTemp = pEcKey;
/* Place the encoded public key in the EC_KEY struct. */
pEcKeyTemp = o2i_ECPublicKey(pEcKeyTemp, pMem, keylen);
/* Allocate an EVP_PKEY struct for the EC_KEY. */
pKey = EVP_PKEY_new();
/* Assign the public key to the EVP_PKEY wrapper. */
EVP_PKEY_assign_EC_KEY(pKey, pEcKey);
pEcKey = NULL;
int
ec_x962_encode(EC_KEY *pEcKey, uint8_t *key, int keylen, uint8_t *conv)
{
point_conversion_form_t form;
/* Get the conversion format. */
form = EC_KEY_get_conv_form(pEcKey);
/* Make sure the format is supported. If so, the first byte of the encoded
data will be the format identifier. */
switch (form) {
case POINT_CONVERSION_UNCOMPRESSED:
conv[0] = POINT_CONVERSION_UNCOMPRESSED;
conv++;
break;
case POINT_CONVERSION_COMPRESSED:
case POINT_CONVERSION_HYBRID:
default:
keylen = 0;
break;
}
/* If the format is valid, copy the key into the destination buffer. */
if (keylen) {
memcpy(conv, key, keylen);
keylen++;
}
return(keylen);
}
Thanks,
Bala
On Sun, 6/29/14, pratyush parimal pratyush.pari...@gmail.com wrote:
Subject: Fwd: Converting public part of 'EVP_PKEY' structure to 'unsigned
char*' , and back.
To: openssl-users@openssl.org
Date: Sunday, June 29, 2014, 11:43 PM
Hi all,
Did anyone have any luck with this
one?
Thanks,Pratyush Parimal.
-- Forwarded
message --
From: pratyush
parimal pratyush.pari...@gmail.com
Date: Wed, Jun 25, 2014 at 10:43 AM
Subject: Converting public part of 'EVP_PKEY'
structure to 'unsigned char*' , and back.
To: openssl-users@openssl.org
Hi all,
I was trying to use ECDH (in OpenSSL v1.0.1f) for
a project, and after generating the EVP_PKEY structure, I
needed to extract its public key and send it over to the
other party. I was unable to find a straightforward way
which worked for me.
What I tried was this:
EVP_PKEY*extract_peerkey_3(EVP_PKEY*
EVP_PKEY_both) //'both' meaning it contains public +
private{ int len =
0;
len =
i2d_PUBKEY(EVP_PKEY_both, NULL); //find out required buffer
length unsigned char *buf,
*p;
buf = (unsigned
char*) malloc(len); //allocate p =
buf; len =
i2d_PUBKEY(EVP_PKEY_both, p);
const
unsigned char* p2 = buf; EVP_PKEY*
EVP_PKEY_public = d2i_PUBKEY(NULL, p2, len);
if
(EVP_PKEY_public == NULL) { handleCryptoError(d2i
failed, ERR_get_error());
}
return
EVP_PKEY_public;}
The function doesn't throw an error, but when
I pass the returned 'EVP_PKEY_public' structure to
the function 'EVP_PKEY_derive_set_peer', I get an
error message error:10071065:elliptic curve
Re: Converting public part of 'EVP_PKEY' structure to 'unsigned char*' , and back.
*Guessing the context that is sent to EVP_PKEY_derive_set_peer is
initialized/created with a pkey belonging to different group. *
*In other words, EC keys of both parties in DH are not of the same group. *
On Mon, Jun 30, 2014 at 10:13 AM, pratyush parimal
pratyush.pari...@gmail.com wrote:
Hi all,
Did anyone have any luck with this one?
Thanks,
Pratyush Parimal.
-- Forwarded message --
From: pratyush parimal pratyush.pari...@gmail.com
Date: Wed, Jun 25, 2014 at 10:43 AM
Subject: Converting public part of 'EVP_PKEY' structure to 'unsigned
char*' , and back.
To: openssl-users@openssl.org
Hi all,
I was trying to use ECDH (in OpenSSL v1.0.1f) for a project, and after
generating the EVP_PKEY structure, I needed to extract its public key and
send it over to the other party. I was unable to find a straightforward way
which worked for me.
What I tried was this:
EVP_PKEY*
extract_peerkey_3(EVP_PKEY* EVP_PKEY_both) //'both' meaning it contains
public + private
{
int len = 0;
len = i2d_PUBKEY(EVP_PKEY_both, NULL); //find out required buffer length
unsigned char *buf, *p;
buf = (unsigned char*) malloc(len); //allocate
p = buf;
len = i2d_PUBKEY(EVP_PKEY_both, p);
const unsigned char* p2 = buf;
EVP_PKEY* EVP_PKEY_public = d2i_PUBKEY(NULL, p2, len);
if (EVP_PKEY_public == NULL)
{
handleCryptoError(d2i failed, ERR_get_error());
}
return EVP_PKEY_public;
}
The function doesn't throw an error, but when I pass the returned
'EVP_PKEY_public' structure to the function 'EVP_PKEY_derive_set_peer', I
get an error message error:10071065:elliptic curve
routines:EC_POINT_cmp:incompatible objects.
I also tried to follow the steps given at
http://stackoverflow.com/questions/1819/how-does-one-access-the-raw-ecdh-public-key-private-key-and-params-inside-opens
.
When i reconstruct the EVP_PKEY using the steps EC_POINT_oct2point() -
EC_KEY_set_public_key()
- EVP_PKEY_set1_EC_KEY(), the resulting EVP_PKEY does work for me. In
fact I'm able to derive the same secret on both sides using this sequence,
but I feel it's too roundabout.
I also saw the following:
http://marc.info/?l=openssl-usersm=116474297608094w=2, which talks
about using 'i2d_PUBKEY', but I haven't been able to make it work so far.
Is my usage of d2i_PUBKEY or i2d_PUBKEY wrong in some way? Does anyone
know how to use them properly?
Any help will be appreciated.
Thanks!
Pratyush Parimal
Questions about ECDSA_METHOD in OpenSSL 1.0.2
Hi,
OpenSSL 1.0.2 has a new interface for creating a new ECDSA_METHOD.
Unlike the corresponding RSA_METHOD structure the ECDSA_METHOD structure
is privately defined in header file ecs_locl.h, and there are functions
like ECDSA_METHOD_set_sign() etc. to override members of the structure.
From header file ecs_locl.h:
struct ecdsa_method
{
const char *name;
ECDSA_SIG *(*ecdsa_do_sign)(const unsigned char *dgst, int dgst_len,
const BIGNUM *inv, const BIGNUM *rp, EC_KEY *eckey);
int (*ecdsa_sign_setup)(EC_KEY *eckey, BN_CTX *ctx, BIGNUM **kinv,
BIGNUM **r);
int (*ecdsa_do_verify)(const unsigned char *dgst, int dgst_len,
const ECDSA_SIG *sig, EC_KEY *eckey);
#if 0
int (*init)(EC_KEY *eckey);
int (*finish)(EC_KEY *eckey);
#endif
int flags;
char *app_data;
};
What seems to be missing is a function to set and get the app_data
member. Was that forgotten? If the application needs an app_data
pointer, it looks like one needs to copy the structure definition in
order to be able to get and set the app_data pointer.
--
Stephan
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Removal of Dual EC DRBG from the OpenSSL FIPS module
It took a couple of hours of code hacking followed by six long months of waiting, but at long last revision 2.0.6 of the OpenSSL FIPS Object Module v2.0 (validation certificate #1747) has finally been approved: https://www.openssl.org/source/openssl-fips-2.0.6.tar.gz https://www.openssl.org/source/openssl-fips-ecp-2.0.6.tar.gz Usually new revisions add support for new platforms; with 2.0.6 the Dual EC DRBG algorithm implementation is entirely removed from the module. This removal eliminates dead code that no one in their right mind would use deliberately, and also eliminates the accidental or malicious enabling of that algorithm. Revision 2.0.6 is a direct replacement for all previous revisions (2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5). Anyone concerned about the presence of the toxic and officially deprecated Dual EC DRBG algorithm is encouraged to upgrade to revision 2.0.6. Note that the formal paperwork for revision 2.0.7, with support for eleven new platforms, was submitted some time ago. As the removal of Dual EC DRBG was not approved at that time, that revision still includes the Dual EC DRBG implementation. We've put in a query asking if we will be permitted to retroactively remove Dual EC DRBG from that as well. If that approval is not given we'll be in the odd position of re-introducing Dual EC DRBG with revision 2.0.7 when that is eventually approved. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: BIO apis - bind to local ip address.
Ø Using BIO apis is there a way to specify the local ip address on which an application can bind to. No, you will have to open and bind the socket yourself and then create a BIO around that descriptor. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.memailto:rs...@jabber.me; Twitter: RichSalz
SSL_CTX_set_tmp_ecdh_callback() semantics in 1.0.1?
Because there is no documentation for SSL_CTX_set_tmp_ecdh_callback() in OpenSSL 1.0.1 and older, I am afraid I have to ask: 1. Is the EC_KEY* returned by the callback supposed to be allocated for each invocation or is it supposed to be a static shared by all invocations? If the latter (a common object), are there any threading issues when multiple threads are running SSL connections simultaneously? 2. What does the keylength parameter to the ECDH callback represent: A) An RSA/DH keylength (e.g. 2048 for 128 bit security) B) An EC keylength (e.g. 130 for 128 bit security) C) A symmetric keylength (e.g. 128 for 128 bit security) 3. Are there particular cut-off-points for the keylength parameter which correlates with the largest of the predefined EC groups likely to be supported by the client (e.g. according to the cipher suite collection offered). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, 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 Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_CTX_set_tmp_ecdh_callback() semantics in 1.0.1?
On Mon, Jun 30, 2014 at 4:32 PM, Jakob Bohm jb-open...@wisemo.com wrote: Because there is no documentation for SSL_CTX_set_tmp_ecdh_callback() in OpenSSL 1.0.1 and older, I am afraid I have to ask: 1. Is the EC_KEY* returned by the callback supposed to be allocated for each invocation or is it supposed to be a static shared by all invocations? Static is fine. If the latter (a common object), are there any threading issues when multiple threads are running SSL connections simultaneously? Well, there is a CRYPTO_LOCK_EC for the static lock. 2. What does the keylength parameter to the ECDH callback represent: A) An RSA/DH keylength (e.g. 2048 for 128 bit security) B) An EC keylength (e.g. 130 for 128 bit security) C) A symmetric keylength (e.g. 128 for 128 bit security) The keylength parameter is munged. You have to translate it from DH/RSA bit lengths. That is, a keylength of 1024 needs to be translated to a 160-bit curve (both have a 80-bit security level), a keylength of 2048 needs to be translated to a 224-bit curve (both have a 112-bit security level), and a keylength of 3072 needs to be translated to a 256-bit curve (both have a 128-bit security level), etc. 3. Are there particular cut-off-points for the keylength parameter which correlates with the largest of the predefined EC groups likely to be supported by the client (e.g. according to the cipher suite collection offered). I use N + 4. For example: if(keylength = 160 + 4) return ECSH160(); // Returns EC_KEY* else if(keylength = 192 + 4) return ECSH192(); // Returns EC_KEY* else if(keylength = 224 + 4) return ECSH224(); // Returns EC_KEY* ... But P-256 seems to be most popular for interop. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
