几乎所有的 Solidity 合约都有这个安全问题

大部分Solidity合约存在一个安全问题,即映射类型可能导致冲突。由于keccak256函数的输出并非双射,冲突概率虽小但非零。合约的风险与用户输入控制、映射数量、输入范围和数据量有关。缓解措施包括使用盐值、独立资产管理及避免依赖冲突函数。解决方案包括使用恒等函数确保无冲突。
摘要由CSDN通过智能技术生成

几乎所有的 Solidity 合约都有这个安全问题

未标题-3

img

几乎所有的Solidity合约都有这个安全问题,有些合约比其他的更严重。这个问题是Solidity编译器固有的。考虑在Solidity中实现映射:

mapping(uint256 => bytes32) mapping1;

生成的存储地址总是在0` – 2**256-1范围内。没有数学上的保证可以确定其没有冲突。事实上,在这个范围内证明冲突的存在是很容易的。

Pseudo-Demonstration

考虑定义在N1范围内的keccak256函数k:从0到2**256-1的自然数。它在EVM中的输出也是N1。此外,N1中任何元素的输出都是有保证的,输出也不是微不足道的(否则就不能满足加密要求);因此k不是恒等函数。另外:输出尽可能接近于单射。因此,它尽可能的会接近于双射(在不破坏密码属性的情况下证明双射应该是不可能的)。(我称之为伪双射。)

这种伪双射函数几乎在所有时间都不同于恒等函数,保证每个参数值至少有一次冲突(除了是当函数给出与恒等函数相同的输出时)。对于任何其他没有冲突的情况,它们必须有相同数量的有多于一次冲突的情况)。换句话说:伪双射函数不是排列,平均每个输入值有 1 次冲突,并且很有可能超过1次。k函数有可能与另一个输入发生1/(2**256-1)冲突

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值