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) wrote: On 18 December 2012 05:30, jeetendra gangele 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 Tue, Dec 18, 2012 at 3:24 AM, Matt Caswell (fr...@baggins.org) wrote: > > > On 18 December 2012 05:30, jeetendra gangele 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.
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) wrote: > > > On 18 December 2012 05:30, jeetendra gangele 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 18 December 2012 05:30, jeetendra gangele 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.
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 wrote: > On Mon, Dec 17, 2012 at 11:50 PM, jeetendra gangele > 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 wrote: >>> On Mon, Dec 17, 2012 at 11:16 PM, jeetendra gangele >>> 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
Re: Support for 448 bit hash value generation in opnessl.
On Mon, Dec 17, 2012 at 11:50 PM, jeetendra gangele 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 wrote: >> On Mon, Dec 17, 2012 at 11:16 PM, jeetendra gangele >> 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.
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 wrote: > On Mon, Dec 17, 2012 at 11:16 PM, jeetendra gangele > 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:16 PM, jeetendra gangele 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