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