Is it possible to use AES to produce a private ECC key?

Michael Cooper

2/4/24, 9:07 PM

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?

1 + 0

aes

elliptic-curves

Score:3

Crypto

poncho

2/5/24, 3:13 AM

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.

+ 5

Michael Cooper

2/5/24, 4:28 PM

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.

poncho

2/5/24, 10:39 PM

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

Michael Cooper

2/6/24, 2:23 AM

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?

poncho

2/6/24, 3:15 AM

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

Michael Cooper

2/6/24, 3:22 PM

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.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Is it possible to use AES to produce a private ECC key?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.