【问题标题】:Why can't `blake2_256` prevent the "first key pair" in a StorageDoubleMap from being compromised when using decl_storage?为什么在使用 decl_storage 时 `blake2_256` 不能防止 StorageDoubleMap 中的“第一个密钥对”被破坏?
【发布时间】:2019-05-21 11:15:37
【问题描述】:

decl_storage! 是一个“过程宏”,用于存储数据以使其在后续块中可用。

它表示如果用户能够在double_map 中设置第一个密钥对,那么我们就不能信任该密钥对,因此我们必须使用加密哈希,例如 blake2_256以防止“所有存储项目的其他值受到损害”。

接着说如果用户能够在double_map 中设置第二个密钥对,那么我们就不能信任那个密钥对,因此我们必须使用加密哈希例如blake2_256,以防止“存储中具有相同第一个密钥的其他项目被泄露”。

关于第一个密钥对,为什么说它只是为了防止“所有存储项的其他值被泄露”blake2_256 不是也用来防止第一个密钥对本身被泄露(而不仅仅是“其他值”)吗?

【问题讨论】:

  • 这是您在大约 4 小时内提出的第四个问题。尽管我们很高兴在 SO 上提供帮助,但我认为(这是我个人的看法),您应该多处理一下这个话题,而不是一个接一个地问问题。看来,你还没有理解这个话题(至少对)。如果我错了,请纠正我。
  • 谢谢。作为适用于多种存储类型的问题之一,我重新审视了该问题并将其调整为仅关注一个问题
  • 我现在还删除了那些作为有用的背景上下文(即使是对我未来的自己),这是我通常的做法,以及任何与“品牌”相关的词,因为一些用户认为它是垃圾邮件/促销。抱歉,我没有意识到它会被这样看待。

标签: hash rust substrate


【解决方案1】:

假设module1.someValue 的哈希是0x12345678

module2.doubleMapValue.firstKey(value1) 的哈希是0x1234

module2.doubleMapValue.secondKey(value2) 的哈希是0x5678

这意味着module2.doubleMapValue.fullKey(value1, value2)module1.someValue 具有相同的哈希值。即值存储在同一个地方。

如果用户能够控制module2.doubleMapValue 的两个键并计算出value1value2 的值,那么他们将能够覆盖module1.someValue 的值并导致安全问题。

如果值由用户控制,这就是为什么双映射的 key1 的哈希函数需要是加密哈希的原因。否则,用户可能会制作value1,使其与所有其他模块的存储发生冲突,从而危及它们。

如果用户不控制key2,双映射提供了一个清除所有带有hash(key1)前缀的键的功能,也可能被劫持造成麻烦。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-03-05
    • 1970-01-01
    • 1970-01-01
    • 2014-04-05
    • 2014-05-26
    • 2014-01-09
    相关资源
    最近更新 更多