Storing encrypted data on Walrus and wanting to update the keys? It sounds simple, but in practice, it's a big pitfall.

In traditional enterprise security standards, regular key rotation is a standard operation. But under the Walrus architecture, things become much more expensive. The core issue is straightforward—data is already encrypted and uploaded. Once you change the key, those old data slices become a pile of unrecoverable junk. Trying to directly modify the encryption algorithm on-chain? Forget it. The only way is to download the files, decrypt them with the new key, re-encrypt, and then re-upload them to the network as new files.

How wasteful is this process? Double bandwidth consumption, double computational resources, and the need to handle the transition between old and new data. If your data volume is in the TB range, the cost of a full key rotation could be beyond what the team can afford. As a result, many teams are forced to use outdated keys for a long time, gradually accumulating security risks.

So, what's the solution? The answer is to adopt **Envelope Encryption**. The logic isn't complicated: what you store on Walrus isn't the directly encrypted files, but files encrypted with a "Data Encryption Key (DEK)." Then, this DEK is encrypted again with a "Key Encryption Key (KEK)" and stored in a more easily updatable location—such as an on-chain object in Sui or an off-chain KMS system.

When a rotation is needed, you only need to re-encrypt that small DEK, leaving the large files on Walrus unchanged. This approach ensures security while significantly reducing storage costs. Frankly, this is a must-know lesson when designing security solutions on storage systems like Walrus.

If you're planning a system architecture based on Walrus, this approach should be incorporated into your early design considerations.