# Can I compress $192$ byte key into $16$ or $32$ bytes which can be later used in KDF to recover full key

I have a key $$k$$ which is $$192$$ bytes long. Is there a secure way to first compress this key into $$16$$ or $$32$$ bytes, but in such a way that later given those $$16$$ ($$32$$) bytes I can use a key derivation function in order to recover the full $$192$$ bytes $$k$$?

• Are you asking about creating a 192-byte key from 16 or 32 bytes information? If so you can, and it will be secure if the 16 and especially 32 byte is random bytes. Keep in mind that your entropy cannot exceed the input entropy for KDFs. Also, why 192 bytes?, AES has a 128,192, and 256-bit key sizes. – kelalaka Sep 4 at 16:07

No, there is no way (secure or otherwise) to compress a random $$192$$ byte value into something smaller; it is impossible to encode $$2^{8 \times 192}$$ bit possible settings in only 32 bytes (or $$191$$ bytes, for that matter...)

Some exceptions:

• If those 192 bytes were nonrandom, that is, the vast majority of those 192 bit settings were impossible, you may be able to encode which possible setting into 32 bytes; this would imply that, out of the $$2^{1536}$$ possible values of those 192 bytes, only $$2^{256}$$ were possible, then you could do it. The only plausible way I can think of where this might happen is if the 192 bytes were some sort of public or private key, derived from a much smaller 32 byte seed (and you just store the 32 byte seed, and rederive as necessary).

• If you don't mind a large probability of failure; if you don't mind a failure $$99.6\%$$ of the time, you could trim it down to $$191$$ bytes. However, this really doesn't scale to getting things down to the $$32$$ byte level you're interested in.

• If you don't care about the specific value of the $$192$$ bytes key (only that it was generated 'securely'), then what you can do is pick a $$32$$ byte secret seed, and use a KDF to expand it into the full $$192$$ bytes. This would work; however from your question, it doesn't sound like that's what you're asking about.

BTW: if you ask about a 'secure' method, you need to define what you mean by that. What operation(s) to do need to be difficult for an adversary? In this case, there is no method (and so the question is moot), however in other contexts, it would matter.