Re: Support for 448 bit hash value generation in opnessl.
On 18 December 2012 05:30, jeetendra gangele gangele...@gmail.com wrote: Ok, can you expain me how ec_compute_key work and specially this last argument. Why its need hash value to calculate the secret key. I need to generate the 56 BYtes shred key. A KDF (Key Derivation Function) is typically used to generate a secret key from some other input which does not exhibit the properties necessary for direct cryptographic use, e.g. perhaps it would not pass statistical randomness tests. If you need 56 bytes then you could use a hash function that outputs at least that many bits, e.g. SHA512 Matt
Re: Support for 448 bit hash value generation in opnessl.
Yes I tried 64 bytes hash but I need 56 bytes only as I told.
see the below code I am trying with SHA512 but I need only 56 bytes not 64.
It looks like ECDH_compute_key trying to copy all 64 bytes into the
shared secret buffer?.
I want only 56 bytes,is there a way that I can get 56 bytes shared key
with sha512 or some other Hash function since sha448 not present in
opessl.
static void *KDF1_SHA1(const void *in, size_t inlen, void *out, size_t *outlen)
{
char buffer[1024] = {0};
char *outputBuffer = buffer;
#ifndef OPENSSL_NO_SHA
if (*outlen SHA512_DIGEST_LENGTH)
return NULL;
else
{
*outlen = SHA512_DIGEST_LENGTH;
return SHA512(in, inlen, out);
}
EC_KEY_generate_key(ecdh);
EC_KEY_generate_key(ecdh2);
alen = KDF1_SHA1_len;
abuf = (unsigned char *) OPENSSL_malloc (alen);
aout = ECDH_compute_key(abuf, 64, EC_KEY_get0_public_key(ecdh2),
ecdh, KDF1_SHA1);
On 18 December 2012 13:54, Matt Caswell (fr...@baggins.org)
fr...@baggins.org wrote:
On 18 December 2012 05:30, jeetendra gangele gangele...@gmail.com wrote:
Ok,
can you expain me how ec_compute_key work and specially this last
argument.
Why its need hash value to calculate the secret key.
I need to generate the 56 BYtes shred key.
A KDF (Key Derivation Function) is typically used to generate a secret key
from some other input which does not exhibit the properties necessary for
direct cryptographic use, e.g. perhaps it would not pass statistical
randomness tests.
If you need 56 bytes then you could use a hash function that outputs at
least that many bits, e.g. SHA512
Matt
--
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Support for 448 bit hash value generation in opnessl.
On Tue, Dec 18, 2012 at 3:24 AM, Matt Caswell (fr...@baggins.org) fr...@baggins.org wrote: On 18 December 2012 05:30, jeetendra gangele gangele...@gmail.com wrote: Ok, can you expain me how ec_compute_key work and specially this last argument. Why its need hash value to calculate the secret key. I need to generate the 56 BYtes shred key. A KDF (Key Derivation Function) is typically used to generate a secret key from some other input which does not exhibit the properties necessary for direct cryptographic use, e.g. perhaps it would not pass statistical randomness tests. If you need 56 bytes then you could use a hash function that outputs at least that many bits, e.g. SHA512 You actually have to be careful during the truncation. See, for example, Kelsey's presentation at csrc.nist.gov/groups/ST/hash/documents/Kelsey_Truncation.pdf. While collisions on truncated hashes are more of a concern for documents and signing, collisions on truncation in key derivation violate or betray the uniqueness that NIST is trying to impart into agreement protocols via domain parameters (see, for example, SP800-56). Rather than a simple hash, it might be better to use an HMAC where the truncated size is also fed into the HMAC. The HMAC acts more like a PRF (provably), and the length parameter helps remove Near Collisions and Related Hash Outputs. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Support for 448 bit hash value generation in opnessl.
On 12/18/2012 8:53 PM, Jeffrey Walton wrote: On Tue, Dec 18, 2012 at 3:24 AM, Matt Caswell (fr...@baggins.org) fr...@baggins.org wrote: On 18 December 2012 05:30, jeetendra gangele gangele...@gmail.com wrote: Ok, can you expain me how ec_compute_key work and specially this last argument. Why its need hash value to calculate the secret key. I need to generate the 56 BYtes shred key. A KDF (Key Derivation Function) is typically used to generate a secret key from some other input which does not exhibit the properties necessary for direct cryptographic use, e.g. perhaps it would not pass statistical randomness tests. If you need 56 bytes then you could use a hash function that outputs at least that many bits, e.g. SHA512 You actually have to be careful during the truncation. See, for example, Kelsey's presentation at csrc.nist.gov/groups/ST/hash/documents/Kelsey_Truncation.pdf. While collisions on truncated hashes are more of a concern for documents and signing, collisions on truncation in key derivation violate or betray the uniqueness that NIST is trying to impart into agreement protocols via domain parameters (see, for example, SP800-56). Rather than a simple hash, it might be better to use an HMAC where the truncated size is also fed into the HMAC. The HMAC acts more like a PRF (provably), and the length parameter helps remove Near Collisions and Related Hash Outputs. Another option, more in line with the FIPS/NIST requirements for use with DH and ECDH key agreement, is to use the new shortened variants of the SHA-2 algorithms, such as SHA-512/448 (or is it SHA-448/512). These use the algorithm from one of the existing SHA-2 base primitives (SHA-512 or SHA-256) but with different initial values before hashing the first input bit and different truncation of the resulting 256 or 512 bits to the desired length. While they are not yet included in OpenSSL 1.0.1c, it should be possible to generate them by abusing the low level APIs for SHA-256 and SHA-512. (This might not work with the FIPS certified module, which has not been validated for these new primitives). (Note, the above is from my fading memory, I may have gotten some details wrong). 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: Support for 448 bit hash value generation in opnessl.
On Mon, Dec 17, 2012 at 11:16 PM, jeetendra gangele gangele...@gmail.com wrote: Hi, Do we have support for 448 bit hash value generation in openssl.? I looked into the header file and I did not find functiobn related to that. Actually I need to compute shared key for ecdh and that should be 56 Bytes long. I could genearte the 20 byte 32 bytes but I need 56 bytes only. 448 bits is 56 bytes. You will have to use a smaller hash and iterate in a KDF-like fashion; or a larger hash and truncate. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Support for 448 bit hash value generation in opnessl.
U mean to say I can generate 64 bytes and then I can ignore last 8 bytes? so I will get 56 bytes. This value then I have to use as secret key for ECDH On 18 December 2012 09:57, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Dec 17, 2012 at 11:16 PM, jeetendra gangele gangele...@gmail.com wrote: Hi, Do we have support for 448 bit hash value generation in openssl.? I looked into the header file and I did not find functiobn related to that. Actually I need to compute shared key for ecdh and that should be 56 Bytes long. I could genearte the 20 byte 32 bytes but I need 56 bytes only. 448 bits is 56 bytes. You will have to use a smaller hash and iterate in a KDF-like fashion; or a larger hash and truncate. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Support for 448 bit hash value generation in opnessl.
On Mon, Dec 17, 2012 at 11:50 PM, jeetendra gangele gangele...@gmail.com wrote: U mean to say I can generate 64 bytes and then I can ignore last 8 bytes? so I will get 56 bytes. This value then I have to use as secret key for ECDH https://www.google.com/#q=truncated+hash Be careful of ECDH because its anonymous or non-authenticated. NIST Special Publication 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, might help guide you. Jeff On 18 December 2012 09:57, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Dec 17, 2012 at 11:16 PM, jeetendra gangele gangele...@gmail.com wrote: Hi, Do we have support for 448 bit hash value generation in openssl.? I looked into the header file and I did not find functiobn related to that. Actually I need to compute shared key for ecdh and that should be 56 Bytes long. I could genearte the 20 byte 32 bytes but I need 56 bytes only. 448 bits is 56 bytes. You will have to use a smaller hash and iterate in a KDF-like fashion; or a larger hash and truncate. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Support for 448 bit hash value generation in opnessl.
Ok, can you expain me how ec_compute_key work and specially this last argument. Why its need hash value to calculate the secret key. I need to generate the 56 BYtes shred key. On 18 December 2012 10:32, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Dec 17, 2012 at 11:50 PM, jeetendra gangele gangele...@gmail.com wrote: U mean to say I can generate 64 bytes and then I can ignore last 8 bytes? so I will get 56 bytes. This value then I have to use as secret key for ECDH https://www.google.com/#q=truncated+hash Be careful of ECDH because its anonymous or non-authenticated. NIST Special Publication 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, might help guide you. Jeff On 18 December 2012 09:57, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Dec 17, 2012 at 11:16 PM, jeetendra gangele gangele...@gmail.com wrote: Hi, Do we have support for 448 bit hash value generation in openssl.? I looked into the header file and I did not find functiobn related to that. Actually I need to compute shared key for ecdh and that should be 56 Bytes long. I could genearte the 20 byte 32 bytes but I need 56 bytes only. 448 bits is 56 bytes. You will have to use a smaller hash and iterate in a KDF-like fashion; or a larger hash and truncate. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
