Key management

In current version of Themis, key management is left at consideration of end-user. However, we've got some advice and helpful tips for those willing to do truly secure development. Doing highest level of cryptography is negligible if your keys are not protected well.

Generating keys

A good key should be as random as possible.

Do not "contruct" keys yourself or use "secret strings" as keys directly. If possible, use strong random number generator to generate keys. If you really need to use a secret password, pass it through a key derivation function (one-way hash function which will make it look like a random key).

The idealistic way to generate long-term keys (any key which is used more than once is considered a long-term key) is to use a dedicated machine or device which is located in a separate room, not connected to the network (even private or corporate) and allows only authorized personell to administer it. Of course, there will be some simplifications in a way you will do it.

If possible, verify your random number generator with some statistical test suite (currently we use NIST STS to check RNGs). While passing statistical tests does not guarantee that you RNG is good, failing them surely proves it is bad and predictable.

You can use our key generation function (derived from OpenSSL) to generate your keys.

Storing keys in your application

Generally we recommend to use ephemeral (one-time) keys for encryption whenever possible and only use signature keys as long-term keys. Regardless of the key type, applications must not store the keys in plaintext (as is) on persistent storage. While using well defined policy and operating system access control mechanisms to limit access to key files is a good (and absolutely necessary thing) to do, storing them in encrypted form makes overall security level of your solution much higher.

The simplest way, which requires little effort and no infrastructure, you can go is to use some kind of a master password to encrypt all your keys in the application. Master password can be passed as some parameter on application startup and you can use secure cell to protect all keys and other sensitive data.

Signature keys vs encryption keys

Do not use same asymmetric keys for signature and encryption (or key agreement). While mathematically they are same thing and you may be tempted to simplify your key management scheme, their purpose is what makes them different:

As you may see from above, contradicting use-cases and scenarios is what makes those keys different, so keep it in mind while designing your key hierarchy and key management scheme. Also, don't forget to store those keys in encrypted form regardless of key type.

Exchanging keys and transmitting keys over the network

The first recommendation may seem obvious: do not send the keys in plaintext over the network. Always encrypt them. But some usually forget about the second recommendation: even if you exchange public keys only, you should ensure their integrity and authentity, because if you do not - man-in-the-middle (MiTM) will take over all your communications.

Relying on integrity through encryption - is bad practice, so use a separate integrity mechanism.

Both secure message and secure session ensure confidentiality, integrity and authentity of the transmitted data, so they can be used to send/receive keys as well.