📚 课程目录第1章 ML-DSA概述与开发环境搭建

1. ML-DSA概述与开发环境搭建

ML-DSA（Module-Lattice-Based Digital Signature Algorithm）是NIST后量子密码标准化项目中最终入选的数字签名算法，其前身即业界熟知的CRYSTALS-Dilithium。它基于模格上的困难问题（MLWE与MSIS），在量子计算机面前仍能保持安全性，同时签名与验签性能足以支撑绝大多数实际系统。对开发者而言，理解ML-DSA不仅要掌握其数学背景，更要能把它真正跑起来：生成密钥、签名、验签，并判断结果是否符合预期。

为什么需要ML-DSA

当前广泛使用的RSA与ECDSA依赖大整数分解和离散对数问题，Shor算法在足够规模的量子计算机上可以在多项式时间内求解这两类问题。这意味着一旦量子计算实用化，现有公钥签名体系将整体失效。NIST自2016年启动后量子密码标准化，2024年正式发布首批标准，其中FIPS 204即定义了ML-DSA。它的定位是替代RSA/ECDSA在数字签名场景中的角色，包括证书签名、代码签名、固件更新、文档签署与身份认证等。

ML-DSA的安全强度分为三个参数集：ML-DSA-44、ML-DSA-65、ML-DSA-87，分别对应NIST安全等级2、3、5。等级越高，公钥、私钥和签名越长，但抗攻击能力越强。开发者选型时需要在安全等级与传输/存储开销之间权衡。例如在带宽受限的物联网固件签名场景中，ML-DSA-44的签名约2420字节，而ML-DSA-87约4627字节，差异会直接影响升级包体积。

开发环境准备

本节采用Python作为主语言，配合成熟的参考实现快速建立可运行环境。推荐使用pqcrypto或dilithium-py这类封装了参考C实现的Python包，它们安装简单、接口清晰，适合教学与原型验证。若后续需要嵌入C/C++系统，可切换到官方参考实现或liboqs。

# 建议使用虚拟环境隔离依赖
python -m venv ml-dsa-env
source ml-dsa-env/bin/activate   # Windows 使用 ml-dsa-env\Scripts\activate

# 安装带 ML-DSA 支持的 Python 包
pip install pqcrypto

# 验证安装
python -c "from pqcrypto.sign import ml_dsa_44; print('ML-DSA-44 可用')"

除Python包外，建议准备两类辅助工具：一是十六进制查看工具（如xxd或Python的binascii.hexlify），用于观察密钥与签名的字节结构；二是测试向量来源，NIST与项目仓库通常提供已知答案测试（KAT）文件，可用于校验实现是否正确。C库方面，liboqs提供了统一的OQS_SIG接口，编译后可获得liboqs.so，适合在性能敏感或嵌入式环境中替换Python层。

教学环境中优先保证“能跑通、能观察、能对比”。不要一开始就追求高性能实现，先建立正确的密钥—签名—验签闭环，再考虑替换底层库。

第一个ML-DSA签名验证示例

下面给出一个完整的最小示例：生成ML-DSA-44密钥对，对一段消息签名，再验证签名。示例中的消息、密钥和签名均为运行时真实生成，输出长度可作为合理性判断依据。

from pqcrypto.sign import ml_dsa_44

message = b"ML-DSA demo: firmware v1.0.0"

# 1. 生成密钥对
public_key, secret_key = ml_dsa_44.generate_keypair()
print("公钥长度:", len(public_key))
print("私钥长度:", len(secret_key))

# 2. 签名
signature = ml_dsa_44.sign(secret_key, message)
print("签名长度:", len(signature))

# 3. 验签（正确消息）
assert ml_dsa_44.verify(public_key, message, signature) is not None
print("验签通过")

# 4. 篡改消息后验签应失败
tampered = b"ML-DSA demo: firmware v1.0.1"
try:
    ml_dsa_44.verify(public_key, tampered, signature)
    print("异常：篡改消息仍通过")
except Exception:
    print("篡改消息验签失败（符合预期）")

运行后应观察到：ML-DSA-44公钥约1312字节、私钥约2560字节、签名约2420字节（不同实现版本可能有少量差异，以实际输出为准）。验签函数在成功时返回恢复出的消息或非空值，失败时抛出异常或返回失败标志，具体行为取决于所用库的接口约定，开发时应以文档为准并统一封装。

这个示例揭示了几个工程要点。第一，签名绑定的是消息本身，任何字节改动都会导致验签失败，因此消息在签名前必须确定编码方式，避免因换行、编码差异造成“同一内容不同字节”。第二，私钥必须安全保存，示例中仅存在于内存；实际系统应使用密钥容器或硬件安全模块。第三，验签失败不应被静默忽略，应记录明确的失败原因并拒绝后续操作。

结果判读与常见问题

第一次跑通示例后，建议做三组对照实验来加深理解。其一，修改消息任意一个字节，验签必须失败，这验证了签名的完整性保护。其二，用另一对密钥的公钥去验签，必须失败，这验证了身份绑定。其三，重复签名同一消息，观察签名是否每次相同——ML-DSA是随机化签名方案（也可配置为确定性模式），默认情况下每次签名结果可能不同，但都能通过验签，这是正常现象，不应误判为错误。

常见环境问题包括：包名与接口不一致导致导入失败；虚拟环境未激活导致装到了系统Python；以及把验签失败当成程序异常而中断流程。工程上应把验签结果封装为明确的布尔值或错误码，并在日志中区分“格式错误”“长度不符”“验签不通过”三类情况，便于后续排障。