When using software that does encryption using shared secrets what are the recommended practices for changing the keys.

To be specific, this is a distributed software running in a cluster and the communication between the nodes is encrypted using a shared secret. The clustering software in this case uses the eventual consistency model and there is no designated leader.

There is an out of band mechanism for all the nodes to learn the key. I am considering an user option to designate one node to do the key change.

  • when using shared secrets is it a must to provide an option to do key-rotation ?

  • Assuming it is must, is it better to do it periodically (like once in 2 days) ? How often is too often for key rotation ?

1 Answer 1


If your shared secrets are of sufficient entropy there is no need to rotate the key to protect against brute force attacks. For example, if you're using AES-128 to encrypt the data in transit, then if you have a completely randomly generated 128 bit key this will be infeasible to ever brute force.

One area of concern could be your backup procedure. Is it guaranteed that any backups of your systems could expose the secrets to those that should not have access? For example, where are they physically stored and is logical access restricted by ACLs or encryption? This is one reason why key rotation might be useful - to prevent any old backup data that is discovered by an attacker from being used to attack the current system.

The other area of concern is your encryption algorithm isn't of high enough strength. An observer on the connection may be able to capture enough traffic to calculate the key. It would be recommended to use a strong, secure cipher though, rather than rotating keys.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .