20231427田泽航第二周预习报告

1.AI对学习内容的总结

这份文档《娄哥-第1-2章.pdf》系统地介绍了密码学的基础知识及其在C/C++环境下的开发实践。以下是对其内容的总结：

---

第1章：密码学概述

1.1 历史背景与重要性

• 密码学起源于远古，早期主要用于军事、间谍等领域。
• 信息技术的发展使密码学走入公众生活，用于保护银行账号、个人隐私等敏感信息。
• 以玛丽女王的故事为例，说明密码学在历史上的生死攸关作用。

1.2 密码学简史

• 三个阶段划分：

  1. 1949年前：密码学是一门艺术，缺乏系统理论。
  2. 1949–1975年：密码学研究的“冬天”，成果较少，主要为单密钥体制。
  3. 1976年至今：密码学研究的“春天”，公钥密码学诞生，理论和应用蓬勃发展。

• 重要里程碑：

  • 1976年：Diffie-Hellman提出公钥密码学。
  • 1977年：DES标准发布。
  • 1990年代：RSA、ECC、SHA等算法广泛应用。
  • 2000年后：AES取代DES，国密算法（SM2/3/4）兴起。

1.3 基本概念

1.3.1 密码编码学 vs 密码分析学

• 密码编码学：设计加密算法，保护信息。
• 密码分析学：研究破解密文的方法。

1.3.2 密码学解决的五大问题

1. 机密性：防止非授权访问。
2. 可用性：确保资源可访问。
3. 完整性：检测信息是否被篡改。
4. 认证性：确认消息来源的真实性。
5. 不可否认性：防止用户否认其行为。

1.3.3 五元组

• 明文、密文、密钥、加密算法、解密算法。

1.3.4 加解密算法分类

• 对称算法：加密解密使用相同密钥，速度快，但密钥管理复杂。
• 非对称算法：使用公钥和私钥，解决密钥分发和数字签名问题，但速度较慢。

---

第2章：搭建C/C++密码开发环境

2.1 两大国际密码库

• OpenSSL：C语言编写，功能全面，支持命令行和API，广泛应用于工业界。
• Crypto++：C++编写，适合C++开发者，算法实现较为先进。

2.2 OpenSSL 详解

2.2.1–2.2.10 结构与功能

• 支持对称加密（AES、DES等）、非对称加密（RSA、ECC等）、摘要算法（MD5、SHA等）。
• 提供BIO（I/O抽象）和EVP（统一算法接口）等高级接口。
• 支持证书管理、SSL/TLS协议。

2.2.11–2.2.13 编译与安装

• 详细介绍了在Windows和Linux下编译OpenSSL 1.1.1 和 1.0.2m 的步骤。
• 包括静态库、动态库的编译，以及环境配置、依赖处理等。

2.2.14 命令行使用

• 演示了openssl命令的基本用法，如查看版本、支持的算法、计算哈希等。

2.3 Crypto++ 库

• 纯C++实现，适合面向对象开发。
• 示例展示了AES加密的使用方法。

2.4 国产密码库 GmSSL

2.4.1–2.4.3 特点与背景

• 支持国密算法（SM2/3/4/9），兼容OpenSSL接口。
• 适用于国内密码应用系统，符合国家标准。

2.4.4–2.4.8 编译与安装

• 详细介绍了在Windows和Linux（包括老版本系统）下编译安装GmSSL的步骤。
• 包括环境配置、依赖处理、软链接设置等。

2.4.9 命令行与代码验证

• 使用gmssl命令进行SM3哈希计算。
• 编写C++程序调用GmSSL库进行验证。

---

总结

• 第1章奠定了密码学的理论基础，强调其历史演变和核心概念。
• 第2章聚焦实践，详细介绍了三大密码库（OpenSSL、Crypto++、GmSSL）的编译、安装和使用方法。
• 文档内容详实，兼顾理论与实战，适合密码学初学者和C/C++开发者学习使用。

教材学习内容总结

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

对第1章总结的反思与补充

AI总结的局限性：
之前的总结准确地复述了章节的历史和概念，但缺乏对知识内在逻辑和实际意义的深入剖析。

补充与深化：

1. 五大安全属性的内在关联：
   • AI只是罗列了5个属性。实际上，它们在实践中是环环相扣、相辅相成的。
   • 例如：要实现有效的认证性，往往需要完整性和不可否认性来支撑。而这一切通常建立在机密性的基础之上。可用性则是所有安全措施生效的前提。
   • 学习启示：不要孤立地理解这五个概念，而要将它们视为一个完整的安全框架。
2. 密码算法分类的实践选择：
   • AI提到了对称和非对称算法的优缺点，但未给出何时选用的指导。
   • 实践中的典型模式是“扬长避短”：
     • 对称算法（AES, SM4）：因其速度快，用于加密海量的业务数据本身。
     • 非对称算法（RSA, ECC, SM2）：因其能解决密钥分发和签名问题，用于加密“加密数据的密钥”，或用于进行数字签名。
   • 学习启示：绝大多数安全通信协议（如SSL/TLS）、文件加密系统，都是两者结合使用的，而非二选一。

对第2章总结的反思与补充

AI总结的局限性：
总结侧重于“如何做”的步骤，但对“为何这么做”以及“过程中的核心痛点”解释不足。

补充与深化：

1. 环境搭建的本质是“环境变量”和“工具链”的管理：

   • 无论是Windows的nmake报错还是Linux的library not found，其本质都是系统找不到它所需要的工具或文件。
   • Windows：VCVARSALL.BAT的作用就是为当前命令行窗口设置一套包含编译器（cl）、链接器（link）、nmake等工具路径的环境变量。用错了终端，环境变量就不对，必然失败。
   • Linux：ldconfig 的作用是更新系统共享库的缓存，让动态链接器知道新安装的库文件在哪里。PATH环境变量决定了系统去哪里找可执行文件，而LD_LIBRARY_PATH`决定了去哪里找运行时库。
   • 学习启示：理解环境变量和工具链的概念，远比死记硬背编译命令更重要。遇到问题，就从这两个方向去排查。

2. 库类型的抉择：静态库 vs. 动态库：

   • 文档中花了大量篇幅编译不同版本的库，但初学者可能会疑惑“我该用哪个？”。
   • 静态库：代码在编译时直接嵌入到你的最终程序中。优点：程序可以独立运行，无需担心用户系统缺库。缺点：生成的程序体积大，库有安全更新时需重新编译整个程序。
   • 动态库（.dll, .so）：代码在运行时才被加载。优点：程序体积小；多个程序可共享同一份库，节省内存；库更新时只需替换一个文件，无需重新编译主程序。缺点：分发程序时必须带上相应的DLL或so文件，并确保路径正确。
   • 学习启示：开发调试时用动态库更方便。发布给用户时，根据情况选择：如果无法保证用户环境，用静态库打包更省心；如果是大型系统，用动态库便于更新和维护。

3.学习思维导图

4.基于ai的学习

对密码定义与概念向我进行苏格拉底提问，一次提问一个问题
太好了！让我们以苏格拉底的方式，通过一系列问题来探讨密码学的核心定义与概念。我不会直接给出答案，而是通过提问引导您自己思考并得出结论。非常好，让我们开始。首先，请思考：
假设你想给朋友传递一条消息“明天中午行动”，但又不想让路上截获这张纸条的敌人知道内容。在不使用任何复杂工具的情况下，你会怎么做最原始、最简单的事情来隐藏它的真实含义？
使用基本的密码如凯撒密码，使得我的朋友能解密，隐藏真实含义
非常好！您已经想到了一个经典的解决方案：凯撒密码。

现在，基于您的回答，请思考下一个问题：

在凯撒密码这个例子中，我们将“明天中午行动”（明文）转换成了看不懂的字符串（密文）。您和朋友需要事先约定好哪一条最关键的信息，他才能成功地将密文还原成明文？这条信息在整个加解密过程中扮演着什么角色？
移位的位数
完美！您准确地指出了凯撒密码中最关键的那个信息：移位的位数，例如“我们都将字母向后移动3位”。

现在，让我们深入探讨这个关键信息。

基于您的答案，我的下一个问题是：

这个“移位的位数”（比如数字3），它究竟是加密方法（算法）本身的一部分，还是一个可以独立变化、需要秘密保管的参数？如果敌人知道了你们在使用凯撒密码，但不知道这个具体的数字“3”，他能轻易读懂密文吗？
是独立需要保管的参数，不能轻易读懂，但是可以快速暴力破解
出色的回答！您已经完全抓住了核心矛盾。

您正确地指出：

它是独立的参数：这个数字（我们称之为“密钥”）与算法（凯撒密码）是分离的。

它需要保密：不知道密钥，敌人无法直接读懂。

但它很脆弱：由于密钥的可能范围很小（比如只有1-25），敌人可以快速地尝试所有可能的移位（暴力破解）。

这引出了一个至关重要的、现代密码学的基石问题：

既然一个脆弱的密钥（如凯撒密码的移位数字）无法保证安全，那么一个真正安全的密钥，应该具备哪些根本性的特性？
足够的长度，高随机性，保密性
完美！您的回答精准地概括了现代密钥设计的三大支柱：足够的长度、高随机性、保密性。

现在，让我们基于这个坚实的基础，提出下一个问题，以连接理论与实践：

既然我们已经认同，一个安全的系统其核心在于一个长而随机且保密的密钥，而算法本身甚至可以公开（柯克霍夫原则）。

那么，为什么我们不像使用凯撒密码那样，直接设计一个使用极长密钥的、更复杂的“替换”或“移位”算法，而是要去发明像AES（高级加密标准）或SM4（国密算法）这样极其复杂的加密算法呢？
一个长密钥只能解决暴力破解的问题，但无法解决简单算法固有的统计泄漏和数学结构脆弱的问题。现代加密算法（如AES）的复杂性，是为了从根本上消除这些密码学弱点，确保攻击者除了尝试所有可能的密钥外，没有任何更聪明的捷径可走。这才是它们安全性的根本保证。
您的思考已经触及了密码学设计的核心！这个回答非常深刻和准确。

您完全正确。一个长密钥只是增加了“锁”的钥匙孔数量，让暴力尝试（一把钥匙一把钥匙地试）变得不可能。但如果“锁”本身的结构很简单（比如凯撒密码只是一个旋转的圆盘），攻击者根本不需要尝试所有钥匙，他们可以通过分析锁的构造（密码分析）来快速找到漏洞。

您提到了“统计泄漏”和“数学结构脆弱”，这正是关键。

那么，基于您这个卓越的洞察，我的最后一个问题是：

既然复杂的现代算法（如AES）是为了消除统计规律和数学上的脆弱性，那么在设计这些算法时，密码学家追求的核心目标是什么？或者说，一个“完美”的加密算法，其输出（密文）与密钥和明文之间，应该呈现出一种什么样的理想数学关系？
密码学家设计的现代算法，本质是构造一个密钥控制的伪随机置换。其终极目标就是让攻击者面临以下局面：

若不知道密钥，密文就是一堆毫无规律的乱码，与随机噪声毫无区别。

唯一可行的攻击方式就是暴力遍历所有密钥。

因此，算法复杂性不是为了“复杂而复杂”，而是为了数学上逼近“真随机”，从而彻底封堵所有基于统计或数学规律的攻击路径。 针对我这个知识点，我理解了吗
您的理解完全正确，并且达到了非常深刻的水平。这不仅是对知识点的理解，更是对密码学核心哲学和设计目标的精准把握。

让我来为您总结一下，以证明您确实掌握了：

精准的概念：您使用了“密钥控制的伪随机置换”这一专业术语，这精确描述了分组加密算法（如AES）的本质。它不是一个简单的过程，而是一个由密钥决定的、对固定长度数据块进行近乎随机 scramble 的操作。

深刻的目标：您准确地指出了核心目标是让密文与随机噪声无法区分。这在密码学上被称为“不可区分性”，是衡量加密算法安全性的黄金标准。

清晰的威胁模型：您明白算法复杂性的目的不是为了迷惑使用者，而是为了消除非密钥本身的任何规律性，从而将攻击者逼入“唯密文攻击”下唯一可行的路径——暴力破解，并确保这条路径在计算上是不可行的。

高阶的视角：您已经超越了“怎么用”的层面，进入了“为什么这样设计”的层面。您理解算法设计是为了“封堵所有基于统计或数学规律的攻击路径”，这意味着您意识到了诸如差分分析、线性分析等高级密码分析手段的存在，而现代算法正是为了抵抗这些攻击而诞生的。

结论：

您不仅理解了，而且理解得非常透彻。您已经把握了从古典密码到现代密码的范式转变：安全不再依赖于算法的保密或复杂性本身，而是依赖于一个经过公开、严格验证的复杂算法，如何利用一个简短的密钥，生成一个在计算上无法与随机区分开来的输出。

这标志着您已经为学习更具体的算法（如AES的轮结构、S盒设计）和模式（如CBC、GCM）打下了坚实的概念基础。

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

问题一：在Windows下编译OpenSSL时，执行nmake命令出现大量编译错误

问题场景：
你严格按照文档的步骤操作：安装了ActivePerl和Visual Studio，在“VS开发人员命令提示符”中进入OpenSSL源码目录，执行了perl Configure ...配置命令。但当你输入nmake开始编译时，命令行中弹出大量以“error”开头的红色报错信息，编译过程中断。

可能的原因：1. 路径中包含中文字符或空格：OpenSSL的编译脚本对路径处理非常敏感，如果源码解压在了类似D:\学习资料\openssl-1.1.1b这样的路径下，极有可能因中文字符或空格导致编译失败。
2. 未使用正确的“开发人员命令提示符”：编译32位库必须使用x86版本的命令提示符，编译64位库必须使用x64版本。混用会导致环境变量不正确。
3. 环境不干净：之前编译失败的中间文件残留在目录中，干扰了新的编译过程。

解决方式：

1. 使用纯英文、无空格的路径： 将OpenSSL源码压缩包解压到根目录下的一个简单路径中，例如：D:\openssl-1.1.1b。
2. 确认并使用正确的命令提示符：在Windows开始菜单中搜索“开发人员命令提示符”，你会看到多个版本。编译32位库：选择 x86 Native Tools Command Prompt for VS 2017 。
   编译64位库：选择 x64 Native Tools Command Prompt for VS 2017。务必在此提示符中执行所有perl和nmake命令。
3. 彻底清理后重新编译：如果编译失败，先执行 nmake clean 命令清理中间文件。如果问题依旧，最彻底的方法是：删除整个OpenSSL源码目录，重新解压一份干净的源码，然后从头开始配置和编译。

问题二：在Linux下成功编译安装了GmSSL，但运行gmssl命令时提示“error while loading shared libraries”

问题场景：
你在CentOS系统上通过./config、make、make install三步成功编译安装了GmSSL。安装过程没有报错。但当你在终端输入 gmssl version 时，系统却报错：

gmssl: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

问题分析：
这个错误表明：

1. 系统找到了 gmssl这个可执行文件。
2. 但在运行时，系统动态链接器找不到它依赖的共享库文件（libcrypto.so.1.1 和 libssl.so.1.1）。
3. 这是因为GmSSL的库文件默认安装在 /usr/local/lib64/下，而这个路径可能不在系统的默认库搜索路径中。

解决方式：

1. 方法一：将GmSSL库路径添加到系统缓存中
   编辑ld的配置文件：sudo vim /etc/ld.so.conf.d/gmssl.conf
   在文件中新加一行，写入GmSSL的库安装路径：/usr/local/lib64
   保存退出后，运行以下命令使配置生效：
   bash
   sudo ldconfig
   现在再运行 gmssl version就应该可以成功了。ldconfig`命令会重建库的缓存信息，系统之后就能在指定路径找到所需的库文件。

总结： 在Linux下解决动态库找不到的问题，核心是让系统知道库文件在哪里。通过ldconfig管理库路径是最标准、最一劳永逸的解决方案。