# Containers for secret key

What 'container' is used normally to store/transport secret keys (for symmetric algorithms)?

I have come across PKCS12 format where a public key certificate as well as a private key can be bundled together and stored in an archived file format.

Similarly how can an array of random bytes that can be used as a secret key be bundled/packed?

• Key pair cryptography! You have a basic knowledge of RSA and ECC, I'm sure. Both of these can be used to transport a secret key. Although there's plenty of other methods, too. I'd also argue the algorithm is the container. (In cryptography terms) – Iam Nick Jan 14 '16 at 6:37
• PKCS12 would NOT be the entire solution, by a long shot. – Iam Nick Jan 14 '16 at 6:40
• In principle there is also a SecretBag type in PKCS#12 which could be used to store symmetric keys. Not all implementations will support that however - compatability issues may arise. – Maarten Bodewes Jan 14 '16 at 14:12

## 2 Answers

well it probably varies on how you want to access the key, one of the most extreme version could be an HSM which should keep it really safe but is also rather expensive.

another way would be encrypting it with a key that just you know with plain AES and storing the base64 somewhere for example, that's what I do for some of them if you want to require entering a password you use use a key derivation function to create the key, but then you must make sure that you either use no salt or always the same.

when you want to do it for automatic access (like for needing the keys on a webserver) then you can either store the key somewhere in plaintext or you encrypt the key and save the encryption key somewhere ELSE, for example if your secret key is in a MySQL database, then store the encryption key somewhere deep in your Harddrive, even better if used with very strong permission management in there.

if you want automatic access you have to have direct access to the key which complicates it a lot.

by the way depending on how you set your HSM, you can use the key in an automated fashion, but not access the key itself.

essentially this means that you don't do the en/decryptions youself in your script/program/whatever but you send whatever needs to be crypted to the HSM which just does it for you (which also makes sure that you dont accidentially do bad things, which weaken the security drastically, because it can make it easier to use the crypto in the first place, because you just have your black box where you throw in your input and get the result).

of course it would still be annoying if someone broke in and got the ability to use your key as long as they are in, but as with HSMs you can usually not export the key at all, and even if you can, it's usually only if you supply extra permission credentials to do that. this means while the attacker can do a lot of stuff, as soon as he's removed from the machine, he cannot do crypto anymore because he didnt get the key.

Apologizes in advance for the lack of links /proper formating. I'm on a phone.

Ignore protocols, and look up FILL DEVICE. This is what the NSA /military use for key distribution. It's why one time pads can be used operationally. It partially solves the key distribution problem, and is a distant ancestor of quantum key distribution. The container is literally a metal box with an emergency erase function. Remember that when in theatre there is no internet to exchange keys. You need a man, a fill device and a jeep.