4
$\begingroup$

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?

Improve this question
$\endgroup$
1
  • 1
    $\begingroup$ 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 $\endgroup$
    – Richie Frame
    Jun 17, 2016 at 1:24

1 Answer 1

Reset to default
2
$\begingroup$

First of all, you would probably want to put the shared secret into a KDF even if you have enough bits to use it in a symmetric encryption algorithm. Check these two related posts: Key Derivation Function (KDF): Can a key derived from KDF be considered as a secure key? and How to derive a symmetric key from ECDH shared secret?

So, the question: Is there a NIST standard or a paper that specifically describes how this situation should be handled?

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).

Improve this answer
$\endgroup$
2
  • $\begingroup$ Excellent answer, I'm going to see if there's anything else before I accept it. Also, from the "hardware" point of view, the current practices are expensive and inefficient. SHA-x takes more resources than the complete ECC/SIMON hardware that I have. I might have to come up with some else. $\endgroup$
    – b degnan
    Jun 17, 2016 at 13:14
  • $\begingroup$ Just a note, from the perspective of power, most hashes are really amazingly power hungry. I spent the day looking at SHA-x and they really use up a lot of transistors. There's probably something nice that can be done that's a combination of the ECC engine and the symmetric implementation. So, I will indeed have to come up with something else. $\endgroup$
    – b degnan
    Jun 17, 2016 at 23:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.