20231427田泽航第五周预习报告

1.AI对学习内容的总结

使用AI工具：DEEPSEEK
第7章主要介绍了数字签名技术的基本概念、原理、分类、安全性及其在实际中的应用。数字签名用于验证信息的完整性、身份认证和不可否认性。本章内容包括：

数字签名的基本概念：数字签名是用于验证信息发送者身份和信息完整性的技术，基于非对称加密算法（如RSA）实现。

数字签名的原理：发送方使用私钥对信息进行签名，接收方使用公钥验证签名。

数字签名的分类：包括直接数字签名、仲裁数字签名等。

数字签名的安全性：依赖于私钥的保密性和算法的强度。

RSA在数字签名中的应用：详细介绍了如何使用RSA算法进行数字签名和验证。

OpenSSL命令实现签名与验签：通过命令行工具演示数字签名的生成与验证。

基于OpenSSL的编程实现：

直接使用RSA函数进行签名与验签；

使用EVP系列函数进行签名与验签，提供了更高级、统一的接口。

教材学习内容总结

2.对AI总结的反思与补充

AI总结的局限性：

未详细说明数字签名的具体算法流程（如哈希与加密的顺序）；

未提及数字签名在实际系统（如PKI、SSL/TLS）中的集成方式；

缺乏对国密算法（如SM2）在数字签名中应用的介绍；

未强调数字签名与数字证书的关系。

自己的补充：

数字签名通常先对原始数据做哈希（如SHA256、SM3），再对哈希值用私钥加密；

在实际系统中，数字签名常与数字证书结合使用，由CA签发证书来绑定公钥与身份；

国密算法SM2也可用于数字签名，其实现方式与RSA类似但基于椭圆曲线；

OpenSSL的EVP接口支持多种算法（如RSA、ECDSA、SM2），适合开发跨算法兼容的系统。

3.学习思维导图

4.基于ai的学习

1. 关于数字签名与MAC区别
   我：AI，我最近学习了数字签名和消息认证码（MAC），它们好像都是用来保证消息完整性和真实性的。那我能不能说，数字签名就是一种用非对称密码实现的MAC呢？

AI：这是一个非常有趣的起点。让我们深入探讨一下。你能否先告诉我，当你使用MAC来验证一条消息时，验证方需要拥有什么？

我：验证方需要拥有和发送方相同的对称密钥。

AI：完全正确。那么，如果一条消息附带了有效的MAC，这证明了什么？

我：证明了这条消息是由拥有相同密钥的人创建和发送的。

AI：很好。现在，让我们考虑一个场景：你是一家公司的财务，收到一封来自“CEO”的邮件，内容是“请向XXX账户转账100万”，这封邮件带有有效的MAC。你能百分之百确定这封邮件是CEO本人发出的吗？

我：嗯……不能完全确定。因为任何拥有那个对称密钥的人都可以生成这个MAC。可能是CEO，也可能是能接触到密钥的IT管理员，甚至是窃取了密钥的黑客。在系统内部，我知道消息没被篡改，且来自“自己人”，但我无法向第三方证明它一定来自CEO。

AI：非常精彩的洞察！你触及了第一个核心区别。现在，我们转向数字签名。当接收方用发送方的公钥成功验证了一个数字签名时，这证明了什么？

我：这证明了签名是由与之对应的那个私钥创建的。

AI：那么，谁拥有这个私钥？

我：理论上，应该是私钥的唯一所有者，比如你刚才例子里的CEO。

AI：那么，基于这一点，在“转账100万”的例子中，如果邮件附带的是CEO的数字签名，并且验证通过了，你能得出什么在MAC情况下无法得出的结论？

我：我能得出，这封邮件几乎可以肯定是由CEO本人发出的，因为只有他拥有那个私钥。而且，我还可以把这个签名和邮件作为证据，出示给银行或法官，他们用CEO的公钥也能验证这一点。

AI：完美！你已经自己推导出了两个关键区别：“不可否认性”和“第三方可验证性”。现在，让我们再从另一个角度思考。为了保护一条消息，使用MAC和数字签名，哪种方式在计算上通常开销更大？

我：应该是数字签名吧。非对称加密解密（比如RSA）比对称加密（比如AES）或哈希（比如SHA256）要慢得多。

AI：是的，这是一个重要的工程考量。那么，为什么我们宁愿承受这个性能开销，也要在某些场景下使用数字签名呢？

我：就是因为刚才说的，在需要明确责任归属、需要向第三方证明消息来源的场景下，比如签合同、发数字证书，MAC就无能为力了，必须用数字签名。而在内部系统、API调用这种双方互信但怕消息被篡改的场景，用MAC更高效。

AI：总结得非常到位，你已经掌握了。

2. 关于OpenSSL生成一个RSA密钥对并对其进行数字签名
   我：AI，你刚才提到了用OpenSSL命令生成RSA密钥对并签名，我照着做了一遍，确实成功了。但我感觉我只是在输入命令，能不能帮我更深入地理解每一步在做什么？

AI：很高兴你愿意深入理解。让我们从头开始。你使用的第一个命令是 openssl genrsa -out private.key 2048。你认为这个命令在执行时，OpenSSL在幕后主要做了哪两件关键事情？

我：嗯...首先是生成一个RSA密钥对，然后把私钥保存到文件里。

AI：没错。但你知道RSA密钥对包含哪些部分吗？以及，这个命令生成的 private.key 文件里，是否只包含了私钥？

我：RSA密钥对包含公钥和私钥。私钥文件里...应该只有私钥吧？不然为什么叫私钥文件。

AI：这是一个非常常见的误解。让我们验证一下。你可以试着运行 openssl rsa -in private.key -pubout -out public.key 之后，再运行 openssl rsa -in private.key -text -noout 看看私钥文件里到底有什么。

我：（操作后）啊！我看到私钥文件里不仅包含了私钥参数（如private exponent），也包含了公钥参数（modulus和public exponent）！所以私钥文件其实是“密钥对”文件，它本身就包含了推导出公钥的全部信息。

AI：完全正确！所以你第二个命令 -pubout 所做的，正是从私钥文件中“提取”出公钥部分，并单独保存。现在，我们来到签名。你用的命令是 openssl dgst -sha256 -sign private.key ...。你认为这个 -sign 选项在幕后简化了哪几个关键步骤？

我：它应该是对数据先做哈希，然后用私钥加密这个哈希值。

AI：很好的直觉。但更准确的说法是“用私钥进行数学运算生成签名”，因为RSA的“加密”在签名语境下有特定含义。那么，为什么我们不直接用私钥加密整个原始数据，而是要先哈希呢？

我：是不是因为RSA能处理的数据长度有限制？而且加密整个数据会很慢。

AI：一针见血！这两点都非常关键。RSA算法本身能处理的数据长度不能超过密钥长度。对于2048位的密钥，最多只能加密245字节左右的数据。先哈希，就把任意长度的数据固定成了一个32字节（SHA256）的摘要，完美解决了长度问题。同时，哈希也极大地提升了性能。那么，验证签名 -verify 时，OpenSSL又做了哪两步操作呢？

我：它应该也是先对原始数据 data.txt 计算同样的SHA256哈希，然后用公钥去解密签名文件 signature.bin，得到另一个哈希值，最后比较这两个哈希值是否一致。

AI：非常棒！你的描述完全正确。总结一下，验证就是 “计算原始数据的哈希” 和 “用公钥解密签名得到预期哈希”，然后进行比对。如果一致，就证明了两点：1. 数据是完整的；2. 签名确实来自对应的私钥持有者。

5.学习实践过程遇到的问题与解决方式

问题一：在编译使用OpenSSL签名的程序时，链接错误提示“未找到EVP_PKEY_sign”等函数。
解决方法：确认使用的OpenSSL版本是否支持EVP_PKEY系列函数（1.1.0及以上），并在编译时链接libcrypto库：
gcc -o sign sign.c -lcrypto

问题二：使用RSA签名时，数据长度超过密钥长度导致签名失败。
解决方法：
RSA签名前应先对数据进行哈希处理，仅对哈希值进行签名。例如使用EVP_DigestSign函数自动处理哈希与签名。