PrivateDB是Hyperledger Fabric中的一种数据安全解决方案。不幸的是，这只是另一个严重的安全问题，不知不觉中，使用此功能的所有项目都处于危险之中。
令我惊讶的是，以前没有人提到这一点，所以我想我现在最好指出这一点，然后再承担更大的损害。
PrivatedDB背后的逻辑很简单，它将数据放入本地嵌入式数据存储中，并将该数据的哈希值放在区块链上。
问题是，加密哈希不是一种加密机制，任何使用相同哈希算法（也非常标准化）的任何人哈希相同的数据将始终获得相同的哈希！这正是哈希函数设计的目的，这就是为什么我们在数字签名中使用哈希来允许任何人验证签名数据的原因。
但是，这也意味着任何人都可以使用字典攻击来“解密”哈希后面的数据。
[哈希很便宜，普通笔记本cpu核心上的每个哈希的成本约为3微秒，基本上我可以在一小时内在单个笔记本cpu核心上创建10亿个候选哈希，并将它们与hyperledger fabric DLT上的哈希进行比较。
而且我只是在谈论在笔记本电脑上使用单核，甚至不是笔记本电脑的50％功耗
为什么有危险？因为如果攻击者连接到区块链系统，则攻击者会知道要散列的数据的范围（例如，交易ID，商品名称，银行名称，地址，手机号码），因此您可以轻松地创建字典攻击来获取散列后面的真实数据。
如何在要哈希的每个数据中加盐？好吧，这是Hyperledger Fabric没做的一件事。
为了捍卫自己的观点，超级账本未实施盐分，因为很难将盐分传递给对方。您不能使用DLT传递盐值，因为攻击者会看到它，因此您必须与对方建立另一个p2p连接。如果您需要与所有交易对手建立联系，那么首先使用区块链的意义何在？
令人恐惧的是，这么多人都在使用整个安全性。
当然，散列数据可能太大，以至于无法进行字典攻击（在使用此私有DB东西之前，您最好格外小心，但如果是这种情况，则应该只使用数字签名。
我需要区块链吗？我只是没有看到合理的理由；我所看到的只是一堆安全整体]
此帖子直接从公共可用的Hyperledger邮件列表中提取：
https://lists.hyperledger.org/g/fabric/topic/36315899#6979
并且正如上面线程中所指出的那样，这不是一个安全漏洞，而是一种设计选择，如线程中所引用。预计链码将在私有数据中包含一个盐字段，客户端将在其中生成并包含其自己的显着熵盐，这样就无法进行强力攻击，字典攻击...（在此处替换您自己的方法）攻击，就像与任何其他加密哈希方法一起使用。无论是好是坏（需要链码编写器注意此设计决定），都是为了方便和灵活而选择的。原始帖子似乎旨在引起人们的注意，而不是为主张提供基础。