# Is a hash function used to expand the key after ECC shared secret is complete?

I have designed an ECC engine in silicon that handles any curve in the form of $$y^2 = [ax^3 + bx^2 +cx + d] \mod(P)$$

The shared secret is then passed to symmetric encryption engine, which happens to be Simon. The system is asynchronous and simulates great, but there's an occasion situation where I can have a key underflow.

As an example, the shared secret is 160-bits, but my Simon 128/256 has a 256-bit key.

If the solution to the curve is longer than what I need, I can just truncate the value to fit into my symmetric key requirement; however, in the case that it's shorter, it doesn't make sense to have all of those bits be zero.

This hardware doesn't check for a sane user, so if you want to tell it to do a 4-bit ECC, it'll do that. For this reason (and because I'm doing the hardware), it seems like there'd be a hash that is used for the shared secret so it is expanded into the key bit width.

Is there a NIST standard or a paper that specifically describes how this situation should be handled?

• I believe it is pretty much standard practice to run the shared secret through a hash or key derivation function before use, and has been the case for every instance of non-ECC DH shared secret I have seen Jun 17 '16 at 1:24

For a standard way to handle this situation you can check the IEEE Std 1363-2000 document, particularly section 9.2.2 which show the steps of key agreement operation. The algorithm given in that document uses the shared secret as an input to a KDF function which generates the agreed key (could be the symmetric encryption key in your case).