尽量举办了详尽审查，可是我们没未发明任何安详问题。
详细陈诉如下。没有发明任何重大问题。对所发明问题的评论如下:
· 不安详处理惩罚超长或超短的输入
· 按照类型正确地实现证明与验证成果，最重要的是确保没有无效语句可以或许乐成通过验 证。
· 从生成的随机位中生成一个 BIP39，其可以被视作一个熵位的编码。回收暗码可选的尺度 BIP39 逻辑。
· 钱包对奥秘的安详存储
要像解锁一个已经建设的钱包，用户提供暗码，钱包将实验解密所存储的数据。
为了从 BIP39 口令规复现有帐户，需要执行一个雷同于初始化的流程，只不外钱包将从 助记符中，而非从随机助记符中得到种子。
· 缺少对暗码长度的查抄:由于钱包实在磁盘上存储奥秘，既然暗码足以会见种子，从理 论来讲，暗码的熵至少该当与助记符沟通，而在实际上应该很难破解。因此，我们发起 回收最小的暗码长度，如 16 个字符。
摘要
西格玛协议证明
主要的相关文件是 AutolykosPowScheme，其他重要操纵在诸如 HeadersProcessor 和 ModifierValidator 中实施。
该逻辑主要在 ErgoWalletActor 中举办界说，有关奥秘存储的一个主要构件是 JsonSecretStorage。
协议的逻辑和内部机制是较量巨大的，我们认为最大的风险在于对质明举办阐明与验 证。然而，为了操作这些裂痕，进攻者必需建设一个在某种水平上会令本身受益的语义 正确剧本，而且在不该通过验证的时候通过了验证。
在软件安详方面，Scala 消除某些类此外缺陷，可是由于 Scala 的特定行为或未处理惩罚的错 误，Scala 代码大概依然会受到缺陷的困扰。
· 不符合的变量范例
我们在此确定的两种风险包罗:
尔格协议依赖于尔格剧本，其是一种支持西格玛语句的剧本语言，可以通过非交互式的 常识证明来举办证明以及验证。
实施进程中的挑战包罗:
· 竞态条件
% 尔格安详性评估% Jean-Philippe Aumasson % 2019 年 12 月日
· 生成作为初始熵的 settings.walletSettings.seedStrengthBits 随机位。在默认环境下 ，生成 160 位。
在先前查抄奥托吕克斯共鸣协议事情量证明安详性之后，我们举办了另一轮查抄，重点 存眷其最新的验证逻辑，出格是在理睬 eb0f85a 中所做的变动。
· 不安详利用 Scala 范例和布局
· 断言 k 和 n 为正值，因为当前的负值(称作 Ints)将通报 assert 语句。
· 逻辑缺陷
我们对这两个方面举办了回首，按照存储库 sigmastate-interpreter中的代码和尔格剧本报 告，对(附录 A 中的)预期行为与实际所采纳的行为举办仔细较量。
这份简报先容了我们的评估，并说明白我们所发明的问题以及应对法子发起。
我们想公布尔格已经乐成通过某些(最要害的)部门的安详审查。此次审查由 Jean- Philipee Aumasson 认真完成(也叫 veorq, https://aumasson.jp/ )。
· 缺陷输入的不安详处理惩罚这些证明是一个雷同于树的语句和/或阈值条件，其树叶是离散对数问题的常识证明。
· 对k 和 n 举办更严格的验证:固然类强制执行 k<=32 (办理方案中的元素数量)和 n<31 (元素总数的 log2 值)，但依然可以从授权的参数中建设弱区块。因此，validate()函数可 能需要举办特另外验证，确认 n 和 k 是否便是预期的值。
尔格团队邀请我们对其尔格平台的几个组件举办安详性评估
共享沟通内存地点空间的另一历程或用户大概会规复这些奥秘，而且他们也大概呈此刻 瓦解转储中。据我们所知，在纯 Scala 中没有有效的缓解。
事情量证明的验证
该逻辑在尔格剧本陈诉中有具体说明，而且具体的证明与验证流程在其附录 A 中有介 绍。
钱包
· 在钱包软件执行后，奥秘值(暗码、种子和派生私钥)的副本大概会留在内存中，其是 诸如 Scala 等垃圾收集语言的内涵范围性。
· 界说安详高效证明的编码，而且实现老是乐成处理惩罚有效输入的序列化，以及老是无法处 理无效输入的反序列化。
· 回收一个随机数，，通过 AES-GCM 将该种子加密到磁盘，利用拥有 128000 次迭代的 PBKDF2-HMAC-SHA256，并操作一个随机盐从暗码中发生出一个密钥。
我们查抄所实施的验证逻辑与奥托吕克斯共鸣协议类型中所划定的验证逻辑是否一致， 而且其已被妥善整合进区块头的验证逻辑。
首次建设钱包时，InitWallet 呼吁执行以下操纵
1. 关于钱包暗码，我们将在下一版协议节点中提供发起。不确定暗码法的法律力度会 到何种水平，但我们会对此做更多的咨询。
因此，尔格钱包功使其用户可以或许用磁盘存储与规复奥秘，而且在初次利用的时候，可以 用一个新的种子对钱包举办初始化操纵。
我们会重点审议来自 SigSerializer、Interpreter 的代码以及 ProverInterpreter 特征和方针。
· 建设与验证西格玛协议证明
我们主要寻找来自以下种别中的妨碍:
我们认为应办理以下问题:
西格玛语句证明长短交互式的，这应归功于 Fiat-Shamir 的转换
· 事情量证明验证
2. 只有在启动新网络时修改”n”和”k”参数才有意义。修改挖掘节点中的这些参数将使 所生成的区块对其他节点来说无效。修改协议节点的该项参数意味着呈现另一个分 叉(来自厚道协议参加者的区块将被拒绝)。所以大概不需要举办特别核验，因为 那些启动新网络的人会正确配置”n”和”k”的参数。
3. 今朝尔格节点(以及我们所知道的其他协议节点和钱包，以及我们正在利用 的加密库)无法提供防备当地运行的侧通道进攻的掩护(如恶意软件或病毒所提倡 的时序进攻或内存查抄)。所以，请掩护好运行你钱包的设备!
· 大树深度或递归级时的行为
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
