慢雾科技系统性梳理了Web3领域的密码学安全风险，涵盖私钥随机数生成、主流签名算法（如ECDSA、EdDSA、Schnorr、BLS、RSA）以及哈希和对称加密（AES）的典型漏洞与修复措施，旨在为项目方提供全面的安全防护指南。

本文经授权转载自慢雾科技，作者：慢雾安全团队，版权归原作者所有。

背景概述

密码学是Web3安全的根基，从私钥的生成、交易签名到数据传输的加密，每一环节都依赖于密码学组件的安全实现。然而，在实际开发中，开发团队常常专注于业务逻辑和性能优化，忽视了底层密码学实现的细节。使用不安全的随机数生成器、调用错误的密码学库或对算法特性理解偏差，都可能引入致命漏洞，导致私钥泄露、签名伪造，甚至资产失控。

虽然项目通常会依赖安全审计来发现风险，但审计只能在事后检测，难以覆盖整个生命周期。很多漏洞根植于设计和选型初期，若团队缺乏密码学基础，风险难以从根源被规避。因此，慢雾安全团队开源了关于Web3密码学风险的整理，希望将攻防实践中的典型案例和最佳实践沉淀出来，帮助项目团队在开发早期筑牢密码学安全，建立自主的安全编码能力。

0x01 私钥随机数安全

• 使用 JavaScript 的 Math.random() 或基于时间的种子生成随机数
• 严重性：高
• 描述：JavaScript 的 Math.random() 是一个伪随机，不能用于生成加密私钥等安全场景。其实现依赖浏览器或运行环境，种子和算法不透明，容易被预测或重现。使用 Math.random() 生成密钥、会话令牌或游戏随机事件，存在被猜测或重现的风险，可能导致私钥泄露或会话劫持。
• 建议：优先采用 Web Crypto API 的 crypto.getRandomValues()，以确保随机数的加密安全性，适合生成密钥或敏感令牌。
• 使用 Java 的不安全随机数生成方式生成私钥
• 严重性：高
• 描述：java.util.Random 或 ThreadLocalRandom 是非加密安全的伪随机生成器，易预测，熵不足。用它们生成私钥（如RSA、ECDSA密钥）极易被攻击者推测或重现。应改用 java.security.SecureRandom，它由专为安全设计的算法提供高熵输出。建议配合标准密钥生成工具（如 KeyPairGenerator）使用。
• Android 系统中 SecureRandom 初始化问题
• 严重性：高
• 描述：早期Android版本（如4.1-4.3）中，SecureRandom 未能正确初始化，导致随机数熵不足，可能使私钥预测成为可能。例如，生成比特币私钥时被破解，导致资产丢失。
• 建议：调用 SecureRandom.setSeed()，结合高熵来源（如用户输入、传感器信息）增强随机性。
• 私钥生成时存储随机数的变量空间过小
• 严重性：高
• 描述：用 32 位整数存储随机数将限制随机范围和熵，导致私钥强度不足。攻击者可利用范围受限的随机数，通过暴力或彩虹表攻击快速猜测私钥。例如，某些钱包地址模式被破解，数额巨大的资产被盗。
• 建议：使用256位以上的变量存储随机数，支持完整的密钥空间（如 secp256k1 的 2^256 范围）
• Libbitcoin Mersenne Twister 弱熵漏洞
• 严重性：高
• 描述：Libbitcoin Explorer中的 bx seed 使用 MT19937 生成钱包种子，其种子仅由 32 位系统时间初始化，仅有 2^32 的熵空间。攻击者可通过暴力破解复原种子，推导私钥，危及资金安全。此漏洞俗称“Milk Sad”，因为其短语开头即“milk sad”。
• 建议：替换为加密安全的随机数生成器（如 /dev/urandom，OpenSSL RAND_bytes）。
• OpenSSL 随机数生成器风险
• 严重性：高
• 描述：OpenSSL 的 RAND_pseudo_bytes() 存在设计缺陷，生成的伪随机字节可能具有唯一性但不保证不可预测。用于关键密钥时可能导致低熵泄露（如 LESLI 攻击）。建议全面切换到 RAND_bytes()，并检查返回值以确保随机性。

0x02 ECDSA 安全

• secp256r1 后门疑云
• 严重性：中
• 描述：secp256r1（即NIST P-256）参数由NSA提供，缺乏透明验证，可能内含后门或弱点，攻击者利用可计算私钥或预测随机数，危及TLS、比特币、SSH等系统的安全。考虑迁移至 Ed25519 或 Secp256k1，采用更透明安全的参数。
• secp256k1中 k 值弱随机导致私钥泄露
• 严重性：高
• 描述：签名时使用的随机数（k，即nonce）若由低熵或不安全的PRNG产生，攻击者可分析签名（r,s）和消息哈希，推算k，从而求出私钥。例如，虚拟机或早期钱包未用确定性k，曾被破解。建议采用RFC 6979标准的确定性k生成方法，确保每次签名用唯一、不可预测的k值。
• secP256k1中k值重用致私钥泄露
• 严重性：高
• 描述：若在多次签名中重复使用同一k值（nonce），可利用两个签名的(java r,s)和消息哈希推导出私钥。建议使用RFC 6979标准的确定性签名方法，避免重用k。
• ECDSA签名的可锻造性
• 严重性：中
• 描述：ECDSA签名(r,s)具有数学上的可锻造性，即可以通过特定算法生成等价签名（如(r, -s mod n)），若未使用低s值或规范化签名，可能引发交易篡改（交易可塑性）和绕过验证等问题。建议强制低s值，参照BIP-66标准处理签名参数，确保唯一性。
• 共同用k值（k）导致私钥泄露
• 严重性：高
• 描述：在ECDSA及Schnorr签名中，共用相同的k值会让攻击者通过签名的数学关系推断私钥。建议采用RFC 6979的确定性k生成方案，避免重用风险。
• 签名时未提供原始消息（m）可伪造签名
• 严重性：低
• 描述：验证时只提供消息哈希而非原文，可被攻击者利用生成伪造签名。应当要求验证时提供完整消息（m）以确保安全。
• 签名中的 Nonce（k）侧信道泄漏漏洞
• 严重性：高
• 描述：在特定实现中（如OpenSSL旧版本），通过时间分析可部分推断k的高位，比特泄露率虽低（如97-99%），但攻击者可通过分析大量签名数据恢复私钥。建议采用恒定时间算法与坐标随机化等防护措施。

0x03 EdDSA 安全

• Ed25519私钥提取漏洞
• 严重性：高
• 描述：某些库（如未验证公钥匹配、接口设计不当）允许利用相同私钥、不同公钥签名同一消息，从而逆推出完整私钥。建议只提供私钥签名接口（如 sign(privateKey, message)），由内部计算对应公钥，避免接口混用导致的安全风险。
• WolfSSL中的侧信道漏洞
• 严重性：高
• 描述：WolfSSL实现的Ed25519由于采用完全确定性签名，存在DPA等物理侧信道攻击，攻击者只需收集几千次签名电力轨迹即可完全恢复私钥。建议在临时密钥生成中引入随机元素，提高抗侧信道能力。

• 严重性：高
• 描述：Edwards25519曲线的余因子为8，可能导致Key Image等机制被绕过，造成双花或多花攻击。应在验证过程中，加入子群成员检查，确保Key Image属于大素数阶子群。

• 严重性：中
• 描述：某些旧的Ed25519实现未限制签名标量s，攻击者可构造不同消息的伪签名，破坏系统的唯一性标识。建议在验证时检查签名中的s值是否小于群阶（l），确保签名唯一可信。

0x04 Schnorr 安全

• Schnorr Nonce 重用或弱随机数
• 严重性：高
• 描述：Schnorr签名高度依赖随机nonce的唯一与强随机性，若多次使用相同nonce，则可能暴露私钥。建议使用RFC 6979等确定性nonce生成方案，避免随机性差导致的风险。
• Schnorr相关密钥攻击
• 严重性：低
• 描述：存在理论上的密钥操控攻击（RKA），可通过篡改密钥生成或签名过程实现恶意伪造。建议引入额外验证和抗RKA措施。
• Schnorr的侧信道攻击
• 严重性：低
• 描述：学术界有关于偏差或时间侧信道的潜在风险，但目前未见实际攻击发生。建议使用恒定时间算法及抗侧信道硬件。

0x05 BLS安全

• Filecoin BLS签名验证的可延展性漏洞
• 严重性：高
• 描述：在Lotus实现中发现，BLS签名的不同编码格式（序列化与压缩）能被验证通过，但因验证中未将签名格式标准化，可能导致区块被误判为不同，从而引发分叉或双花攻击。建议在验证前统一签名编码格式，确保一致性。
• 零值相关漏洞与“零值分裂”攻击
• 严重性：高
• 描述：多个BLS库和标准草案中出现对零值（0）处理的严重漏洞，包括验证绕过、私钥泄露、程序崩溃等，尤其在聚合签名场景。建议明确零值处理策略，增强边界条件检测，避免漏洞利用。
• 多重签名中的流氓密钥攻击（Rogue Key Attack）
• 严重性：高
• 描述：攻击者可创建“流氓密钥”通过特殊构造抵消其他签名者的贡献。建议引入Proof-of-Possession等机制防止此类攻击，并使用非线性聚合方法。

0x06 RSA安全

• RSA密钥长度过小
• 严重性：中
• 描述：密钥长度（如512、1024位）不足时，因子分解变得轻易，建议至少使用2048位，甚至更高（如3072或4096位）。
• 靠近质数的模数p,q漏洞
• 严重性：高
• 描述：若p,q非常接近，因式分解效率提升，威胁RSA安全。应确保p,q差异大于安全门限（如>2^(n/2-100)）。
• 模数重用漏洞
• 严重性：极高
• 描述：多次使用相同模数n会允许攻击者通过多个密钥推导出私钥。每次生成新密钥都应确保模数唯一，不复用。
• 极小的公钥指数(e)
• 严重性：高
• 描述：选择过小的e（如3）会导致数学攻击（如解三次方根、Håstad、Coppersmith攻击）风险增加。一般推荐使用e=65537。
• 极小的私钥指数(d)
• 严重性：高
• 描述：d过小会使Wiener等攻击变得可行，建议使用较大随机d值，避免刻意选小，确保d接近φ(n)的大小。
• 短消息未加安全填充
• 严重性：高
• 描述：直接用RSA加密非常小的消息会因小于n而导致安全隐患，推荐采用OAEP等带随机的填充方案提升安全性。
• 填充预言机攻击
• 严重性：高
• 描述：使用PKCS#1 v1.5填充时，若系统返回特定错误信息，攻击者可构造密文逐步还原明文。建议采用防止信息泄露的处理机制，使用常量时间验证。
• 计时攻击
• 严重性：高
• 描述：RSA签名或解密的时间差可被侧信道分析收集，通过多次测量恢复私钥。应使用常量时间实现技术确保防御。
• 乘法延展性攻击
• 严重性：高
• 描述：RSA的乘法特性允许攻击者在无解密错误的情况下操控密文。例如，将密文乘以2^e，使解密后变为原消息的乘2，建议与签名结合验证确保完整性，避免单纯加密带来此风险。

0x07 哈希安全

• 哈希碰撞生日攻击
• 严重性：高
• 描述：利用生日悖论，在哈希输出长度n比特的情况下，可用约2^{n/2}次尝试找到两个不同输入产生相同哈希值（碰撞）。弱哈希（如MD5、SHA-1）已被实证破解，建议采用SHA-256、SHA-3或BLAKE2等安全哈希算法，避免使用已受破坏的算法。
• 哈希长度扩展攻击
• 严重性：高
• 描述：针对Merkle-Damgård结构的哈希（MD5、SHA-1、SHA-256等），攻击者可利用已知H(message)和消息长度，构造H(message||padding||extension)，无需知道原始消息。这在验证机制和协议中非常危险。建议采用不易受长度扩展攻击的算法，如SHA-3或BLAKE2。

0x08 AES安全

• AES密钥长度不足
• 严重性：高
• 描述：低于128位的密钥（如56位）极易被暴力破解，建议最低采用128位密钥，优先考虑256位以确保安全。
• IV/Nonce重用引发的攻击
• 严重性：高
• 描述：重复使用IV或Nonce在CTR、GCM、CBC模式中严重破坏安全。攻击者可以通过密文XOR得到明文XOR、伪造数据或泄露密文信息。务必保证每次加密的IV/Nonce唯一、随机，切勿复用或采用可预测的值。
• ECB模式的弱点
• 严重性：高
• 描述：ECB模式不考虑块之间的关系，相同明文块总是产生相同密文，泄露数据结构特征，强烈建议避免在大规模数据或结构化数据中使用。推荐使用CBC、GCM或ChaCha20-Poly1305等模式。
• CBC模式的密文填充攻击
• 严重性：高
• 描述：利用填充错误信息泄露或响应时间差，攻击者能逐字节恢复密文对应的明文。推荐采用AEAD（如GCM或ChaCha20-Poly1305）模式以提供完整的保证。

0x09 其它密码学协议

• 弱Fiat-Shamir变换
• 严重性：高
• 描述：若在零知识证明的Fiat-Shamir变换中，只对部分参数散列而未覆盖所有公共输入，可能被攻击者预计算伪造证明，造成验证失效。确保在实现中，将所有公开信息都加入到散列中，避免此漏洞。
• GG18和GG20的Paillier密钥漏洞
• 严重性：高
• 描述：协议未验证Paillier模数的安全性（如包含小因子、非素数模数），攻击者可利用该漏洞获取秘密分片，窃取主密钥。建议实现中加入模数检测，确保为大素数双素数结构。

慢雾安全团队开源的区块链密码学风险整理，旨在系统揭示私钥生成、签名、哈希及加密中存在的高危安全隐患。Web3开发者应深入理解漏洞原理、利用场景和修复措施，规避常见实现陷阱，提升系统整体的安全防护水平，保障资产安全。

相关推荐：闪崩测试中的市场韧性：ADL机制如何保障资金安全