1
$\begingroup$

I am working with hardware that can store an AES key securely--the hardware can perform AES encryption/decryption using a stored key without revealing the key to the caller. However, I would like to use ECC in my application.

For a single ECC key, I think I can do this by encrypting the ECC key using AES, then storing the encrypted key and nonce in the open, and the AES key securely. Then, at runtime, I can decrypt the ECC key using the secure AES function.

However, I'm wondering, if I change the AES key in the field, but keep the same "encrypted key" and nonce, could I use the same procedure as above to generate a new ECC key?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
3
$\begingroup$

However, I'm wondering, if I change the AES key in the field, but keep the same "encrypted key" and nonce, could I use the same procedure as above to generate a new ECC key?

Let me restate this: you have a ciphertext (nonce + encrypted key) that decrypts with AES key A to one value (which you will use as an ECC private key). You are asking what happens if you switch to key B; will you decrypt to another value (that will be also be usable as an ECC private key).

Let's get the first concern out of the way: any integer can be used as an ECC private key. It's not like an RSA private key (whose representation usually has considerable structure), instead, the only values that don't work as private keys in ECC are values that happen to be a multiple of $q$ (the order of the generator of the curve), and the probability of picking one of those values randomly is miniscule.

On the other hand, depending on the AES mode of operation, you might not get an integer. Some modes of operation (for example, GCM) will (with high probability) result an error if you use the wrong key. Other modes of operation use padding; unless you turn that off, the decryption may result in a padding error (which will either give you no key, or possibly a smaller key than usual).

In this is a property that you want, you want a mode that avoids both those scenarios - that is, on any decryption, it always returns something (and doesn't truncate the result because of a misinterpreted padding). Counter mode is one obvious choice (as it can be used without padding), as is unpadded CBC. Actually, it strikes me that this is one of the rare cases that unpadded ECB mode would work.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thanks for your response. You've correctly restated the original question. What if I use encryption instead of decryption, i.e., in place of the nonce + encrypted key I simply use two random byte sequences, then use AES-GCM, for example, to encrypt? If I understand correctly, this should (almost always) give an integer that could be used as an ECC key, but I wonder if this integer will satisfy the randomness requirements to give good security. $\endgroup$
    – Michael Cooper
    Feb 5 at 16:28
  • 1
    $\begingroup$ @MichaelCooper well, if you make the AES nonce consistent (e.g. always 0 or always the first 12 bytes of your random byte sequence), then yes, that would work. The words of the result are essentially $AES_k(c_0) \oplus c_1$; for a random AES key $k$, this is effectively random. The one thing I would caution you would be if you attempt to use the key for something else; if you encrypt the wrong thing, you might end up leaking part of the private key (unlikely, but serious enough to merit consideration) $\endgroup$
    – poncho
    Feb 5 at 22:39
  • $\begingroup$ One more question, to clarify something I don't quite understand. If it's not always possible to decrypt a random sequence of bytes using AES-GCM, this suggests to me that the encryption process is not one-to-one--i.e., some encrypted outputs do not have a corresponding plaintext input. Does this mean that if I use AES-GCM to encrypt random bytes in order to get an ECC key, I am actually losing some randomness? Would it be better to use AES-CTR as you had originally suggested, but in the forward direction? $\endgroup$
    – Michael Cooper
    Feb 6 at 2:23
  • 1
    $\begingroup$ @MichaelCooper: I'm not sure what you mean by "losing randomness". Actually, what GCM does is generate a ciphertext that is 16 bytes longer than the plaintext it was given - these additional 16 bytes are essentially a check to make sure that the ciphertext was not modified by someone in the middle. That makes a great deal of sense in the use case that GCM is typically used - it's less useful here. $\endgroup$
    – poncho
    Feb 6 at 3:15
  • $\begingroup$ Ah, thank you. I didn't realize that AES-GCM produced ciphertext that's longer than the plaintext. That explains why it's not one-to-one. $\endgroup$
    – Michael Cooper
    Feb 6 at 15:22

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.