✍️ Gate 广场「创作者认证激励计划」进行中!
我们欢迎优质创作者积极创作,申请认证
赢取豪华代币奖池、Gate 精美周边、流量曝光等超 $10,000+ 丰厚奖励!
立即报名 👉 https://www.gate.com/questionnaire/7159
📕 认证申请步骤:
1️⃣ App 首页底部进入【广场】 → 点击右上角头像进入个人主页
2️⃣ 点击头像右下角【申请认证】进入认证页面,等待审核
让优质内容被更多人看到,一起共建创作者社区!
活动详情:https://www.gate.com/announcements/article/47889
存储在Walrus上的加密数据想要更新密钥?听起来简单,做起来是个大坑。
在传统的企业级安全规范里,定期轮换加密密钥是标配操作。但到了Walrus这套架构下,事情就变得昂贵得多。核心问题很直白——数据已经加密并上传了,你一旦换了密钥,那些旧的数据切片就成了一堆无法解密的垃圾。想在链上直接修改加密算法?别想了。唯一的办法就是把文件拽下来,用新密钥解密再重新加密,然后像全新文件一样重新上传到网络上。
这个过程有多浪费?双倍的带宽消耗、双倍的计算资源,还得处理新旧数据的衔接问题。如果你的数据量是TB级别,全量轮换密钥的成本可能高到团队根本承受不起。结果呢?很多团队被迫长期沿用老旧的密钥,慢慢地安全隐患就堆积起来了。
那怎么破局?答案是采用**信封加密**(Envelope Encryption)这套模式。逻辑其实不复杂:你在Walrus上存储的不是直接加密的文件,而是用"数据密钥(DEK)"加密过的文件。然后把这个DEK再用"密钥加密密钥(KEK)"加密,把它存在更容易更新的地方——比如Sui的链上对象或者链下的KMS系统。
真正需要轮换的时候,你只需要重新加密那个体积很小的DEK就行了,Walrus上那堆庞大的文件体保持原样不动。这样既保证了安全性,又大幅降低了存储成本。说白了,这是在Walrus这类存储系统上设计安全方案时的必修课。
如果你正在规划基于Walrus的系统架构,这个思路值得提前纳入设计阶段考虑。