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 List openssl-users@openssl.org Automated List Manager majord...@openssl.org
