There should be the possibility to regenerate the master key and reencrypt everything.

Once the master key is compromised, the whole system stays compromised and can't be migrated to a secure repository with an other master key.

There are several reasons to change the master key:

• If a user was revoked from the key list, she can't decrypt the master key anymore. But she could have saved it when she was on the user list. Therefore, after a key remove, there should be a (automatic) master key rollover.
• A crypto algorithm has become insecure. From time to time, a crypto algorithm becomes insecure and has to be exchanged. This might also require a new master key (length). But at least it requires the same rollover as for a "simple" master key change.
• The master key was weak (I'm looking on you Debian)
• From time to time, the master key should simply be changed to make offline cracking harder (e.g. automatic/configurable rollover every three Month).

The rollover of a large repository could take up some time. Therefore it should not block the creation of new snapshots and should be interruptible and resumable at any moment. With those constraints, the rollover could be done by a cron job, which doesn't have to care much about running backups, or by an extra time limited phase after each backup (n minutes backup + 15 minutes rollover of the next part of blobs).

There are basically two methods to the rollover:

• For each newly encrypted blob, the old blob will be deleted instantly.
• The old files stay untouched until the whole rollover was successful.