使用系统时间(以纳米秒为单位)作为智能契约中熵的来源

Question

我正在制定一份智能合同，将部署在ETH链上。

我用的是神谕(不是公司！)从非链(区块链外)获取信息的系统。基本上，我们可以把oracle看作是一个API调用，它返回一个随机数。但是对于这个api调用，我需要一个随机种子。

问题：

1. 我可以使用系统时间的最后几位数(以纳米或毫秒计)作为种子吗？
2. 由于我并不真正相信oracle提供程序的随机性，所以我想再次将随机数的结果与系统时间相乘，

这有意义吗？这个数字的随机性能用来加密敏感数据吗？听起来是个好主意吗？

这个电话的频率将是每分钟10个左右。

Answer 1

我可以使用系统时间的最后几位数(以纳米或毫秒计)作为种子吗？

这不是个好主意：

• 很难判断一个对手能用什么样的准确性来了解你的系统时间。通常，开放的进程(例如https服务器或日志系统)会公开它。最佳做法是考虑到系统时间并非秘密。
• 以纳秒为单位获取系统时间的API通常具有更粗的粒度。例如，在我的Windows10机器上，_timespec64_get总是返回倍数为100 (因此 μS粒度为0.1)。这更接近最好的情况，而不是更糟的情况:通常是毫秒，有时是秒。
• 每个十进制数字包含< 3.33位信息，因此9位数字最多提供< 30位信息，这不足以满足键/质询/当前的要求。
• 根据环境的不同，获取熵的问题已经以更加健壮的方式得到了解决：/dev/urandom (Unix/Linux)、CryptGenRandom (Windows)、SecureRandom (Java)、secrets (Python)。

由于我并不真正相信oracle提供程序的随机性，所以我想再次将随机数的结果与系统时间相乘。

将几个熵源结合起来确实是有意义的，但必须谨慎行事。乘法是不合适的:例如，如果oracle提供程序返回零，那么将它与任何东西相乘仍然会产生常数0。独立输入的一个选项是使用组二进制操作，这样组合至少与两个输入一样好。组合独立熵源的最简单的组二进制运算是位排他性或。有更好的方法，包括适用于依赖的熵源，参见评论。

这个数字的随机性能用来加密敏感数据吗？

对于现代安全，对称加密密钥应该有128位熵，我们有理由相信我们缺少这种信息熵。更广泛地说，我担心这个问题表明没有足够的知识来设计一个需要加密的系统。