Which KEK can wrap AES, RSA and ECDSA keys securely?

Question

If I have AES256, RSA4K and ECDSA-512 keys as CEKs, which I need to securely store, what KEK can I use to securely wrap these without reducing the bit strength? I am aware that an AES256 key can wrap RSA4K without reducing the bit-strength (RFC 3394 and 5649). Can an AES256 key wrap another AES256 securely? Is the same true for AES ECDSA-512 wrap as well? Is there an RFC standard?

Answer 1

Keys are not so special that they need special ways of encrypting them. Any key that's secure enough to encrypt data for your needs is secure enough if that data happens to be, or include, another key.

Compliance is another matter. Compliance rules sometimes require a key encryption to be at least as strong as the wrapped key, even if you don't need the result to be that strong. But if such rules apply to you, you have to look up their definition of strength, because there's no universal definition. https://www.keylength.com/ lists a few.

For example, RSA-4096 is usually estimated at somewhat over 128 bits, because it would take a little somewhat more computation effort to brute-force an RSA-4096 key than an AES-128 key. In terms of security, the exact number is irrelevant because it's more than what even the largest nation-state can do even given physically-realistic but economically-unrealistic power. That's as long as there are no game-changing advances such as one that quantum computers may bring, but if there are game-changing advances, they'll affect different key types differently anyway, so the relative scale of the numbers would be completely different. So in terms of security, it's perfectly fine to encrypt an RSA-4096 key with an AES-128 key. But in terms of compliance, if you do this, depending on the compliance framework, you may either find that it caps your system's security at 128 bits (which is fine, you couldn't expect anything more) or that it's forbidden because RSA-4096 is somehow too strong for AES-128.

AES-256 should be fine to encrypt anything, even in the strictest compliance frameworks (apart from the ones that don't accept AES, e.g. that want Russian or Chinese algorithms instead). It's not as if there was anything that's stronger on paper.