4

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?

e-sushi
  • 17,891
  • 12
  • 83
  • 229
b degnan
  • 4,810
  • 1
  • 24
  • 48
  • 1
    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 – Richie Frame Jun 17 '16 at 01:24

1 Answers1

2

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

Community
  • 1
Makif
  • 820
  • 9
  • 16
  • 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. – b degnan Jun 17 '16 at 13:14
  • 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. – b degnan Jun 17 '16 at 23:19