当前位置： 首页 > ops >正文

密码学——对称加密, 非对称加密和CA

ops 2025/8/22 7:32:57
  • 对称加密
  • 非对称加密
    • 客户端服务器端：公钥加密和私钥解密
    • CA证书颁发机构：私钥加密和公钥解密（私钥签名和公钥验签）
  • 数字证书

1. 对称加密

对称加密的核心：加密和解密使用相同的密钥。

1.1 基本原理

  1. 密钥（Key）：一个秘密的字符串或数字，是加密和解密过程的核心。通信双方必须预先安全地共享这个密钥。
  2. 加密（Encryption）：发送方使用密钥和加密算法将原始的明文（Plaintext）转换成不可读的密文（Ciphertext）。
  3. 解密（Decryption）：接收方使用同一个密钥和对应的解密算法将密文还原成原始的明文。

公式表示：

  • 加密：Ciphertext = Encrypt(Plaintext, Key)
  • 解密：Plaintext = Decrypt(Ciphertext, Key)

1.2 常见算法

  • DES
  • AES

1.3 缺点

对称加密要保证客户端和服务器拥有相同的密钥，然后，密钥在传输过程中，容易被黑客截获，这样子加密的信息也能被黑客解密。

2. 非对称加密

非对称加密，也称为公钥加密（Public Key Cryptography），是密码学中另一类核心加密技术。它的核心特点是：加密和解密使用一对不同的密钥——公钥（Public Key）和私钥（Private Key）。

1.1 基本原理

  1. 密钥对（Key Pair）：

    • 公钥（Public Key）：可以完全公开，分发给任何人。用于加密数据或验证数字签名。
    • 私钥（Private Key）：必须由所有者严格保密，绝不泄露。用于解密数据或生成数字签名。
    • 公钥和私钥在数学上是成对生成的，它们之间存在一种特殊的单向函数关系：用公钥加密的数据，只能用对应的私钥解密；反之，用私钥签名的数据，可以用对应的公钥验证。

  2. 加密与解密过程：

    • 加密：发送方（A）想要安全地发送消息给接收方（B）。A获取B的公钥，并用它来加密明文。
    • 解密：B收到密文后，使用自己持有的私钥进行解密，得到原始明文。
    • 公式表示：
      • 加密：Ciphertext = Encrypt(Plaintext, B's Public Key)
      • 解密：Plaintext = Decrypt(Ciphertext, B's Private Key)

  3. 数字签名（Digital Signature）（非对称加密的另一重要应用）：

    • 签名：发送方（A）用自己的私钥对消息的摘要（Hash）进行加密，生成数字签名。
    • 验证：接收方（B）用A的公钥去解密这个签名，得到摘要值，再自己计算消息的摘要。如果两个摘要值一致，则证明消息确实来自A（身份认证）且未被篡改（完整性）。

关键点：即使攻击者截获了公钥和密文，由于没有对应的私钥，也无法解密出明文。这从根本上解决了对称加密中密钥分发的难题。

1.2 常见算法

  1. RSA (Rivest-Shamir-Adleman)

    • 原理：基于大整数分解的数学难题（将一个大合数分解为其质因数的乘积非常困难）。
    • 应用：最广泛使用的非对称算法之一。常用于SSL/TLS握手、数字签名、密钥交换。密钥长度通常为2048位或4096位。
    • 特点：既能用于加密，也能用于签名。

  2. ECC (Elliptic Curve Cryptography - 椭圆曲线加密)

    • 原理：基于椭圆曲线上的离散对数问题。
    • 应用：在移动设备、物联网（IoT）等资源受限的环境中越来越受欢迎。也广泛用于现代TLS、比特币等。
    • 特点：在提供相同安全级别的前提下，所需的密钥长度远小于RSA（例如，256位的ECC密钥 ≈ 3072位的RSA密钥），因此计算更快、占用资源更少、带宽消耗更低。

  3. DSA (Digital Signature Algorithm)

    • 原理：基于离散对数问题。
    • 应用：主要用于数字签名，不能用于加密。
    • 现状：曾经是标准，但现在更多被ECDSA（ECC的签名版本）取代。

  4. Diffie-Hellman (DH) / Elliptic Curve Diffie-Hellman (ECDH)

    • 原理：基于离散对数或椭圆曲线离散对数问题。
    • 应用：密钥交换协议。允许双方在不安全的信道上协商出一个共享的对称密钥，而无需提前共享任何秘密。这是SSL/TLS建立安全连接的关键步骤。
    • 特点：它本身不直接加密消息，而是用于安全地建立对称加密所需的会话密钥。

1.3 缺点

  1. 速度慢：非对称加密算法的数学运算非常复杂（如大数模幂运算、椭圆曲线点乘），其加密和解密速度远慢于对称加密算法（通常慢几个数量级）。因此，不适合直接加密大量数据。

  2. 公钥信任问题（中间人攻击）：虽然公钥可以公开，但如何确保你拿到的公钥确实属于你想要通信的那个人？如果攻击者（Man-in-the-Middle）在你获取公钥时将其替换为自己的公钥，他就可以拦截并解密你的消息（用他的私钥），再用真正的接收方公钥加密后转发，从而实现窃听。解决这个问题需要公钥基础设施（PKI） 和数字证书（Digital Certificate） 来验证公钥的真实性。

3. 数字证书

为了解决非对称加密中的公钥信任问题（即如何确认你拿到的公钥确实属于你想要通信的实体，而非攻击者伪造的），数字证书（Digital Certificate） 和 公钥基础设施（PKI, Public Key Infrastructure） 应运而生。它们共同构建了一个可信的公钥分发和验证体系。

核心思想：引入可信的第三方——证书颁发机构（CA）

数字证书的核心是引入一个或多个被广泛信任的第三方权威机构，称为证书颁发机构（Certificate Authority, CA）。CA的角色类似于现实世界中的“公证处”或“身份证签发机构”。

1. 数字证书是什么？

一个数字证书（Digital Certificate）本质上是一个电子文档，它将一个实体（个人、组织、服务器、设备等）的身份信息与其公钥安全地绑定在一起。这个文档由CA进行数字签名以确保证书内容的真实性和完整性。

一个典型的X.509数字证书（最常用的格式）包含以下关键信息：

  • 证书持有者的身份信息：如域名（www.example.com）、组织名称、所在地等。
  • 证书持有者的公钥：这是证书最核心的部分，将公钥与身份信息绑定。
  • 证书的有效期：证书的生效日期和过期日期。
  • 颁发者（Issuer）：签发该证书的CA的名称。
  • CA的数字签名：CA使用自己的私钥对整个证书内容（包括持有者信息和公钥）进行加密生成的签名。这是信任链的根基。

2. 数字证书如何解决公钥信任问题？

信任链（Chain of Trust）

过程如下：

步骤1：证书申请与签发
  1. 一个实体（比如 www.example.com 的服务器）生成自己的密钥对（公钥 + 私钥）。
  2. 服务器向一个受信任的CA 提交一个证书签名请求（CSR, Certificate Signing Request）。CSR中包含其身份信息和公钥。
  3. CA进行身份验证：CA会通过一系列严格的流程（如验证域名所有权、公司注册信息等）来确认申请者确实是该域名或组织的合法所有者。
  4. 验证通过后，CA使用自己的私钥对包含服务器公钥和身份信息的证书内容进行数字签名，生成数字证书，并将其颁发给服务器。
步骤2：证书分发与验证

当客户端（如你的浏览器）想要访问 https://www.example.com 时：

  1. 获取证书：服务器在建立SSL/TLS连接时，会将自己的数字证书发送给客户端。
  2. 验证证书：
    • 检查颁发者：客户端查看证书的“颁发者”是谁（比如“DigiCert Inc”）。
    • 查找CA公钥：客户端操作系统或浏览器内置了一个受信任的根CA证书列表。这个列表包含了全球公认的、可信的CA的根证书（包含CA自己的公钥）。
    • 验证CA签名：客户端使用它内置的、对应CA的公钥（来自根证书），去解密服务器证书中的CA签名，得到一个摘要值。
    • 计算并比对摘要：客户端自己使用相同的哈希算法（如SHA-256）对收到的服务器证书内容（身份信息+公钥）进行计算，得到另一个摘要值。
    • 验证结果：如果两个摘要值完全一致，则证明：
      • 证书内容在传输过程中未被篡改（完整性）。
      • 证书确实是由该CA签发的（真实性）。
      • 证书中包含的公钥确实属于证书中声明的实体（www.example.com）。
  3. 建立信任：通过验证CA的签名，客户端信任了该服务器的公钥。后续的通信就可以使用这个公钥来加密信息（用于密钥交换）或验证服务器的签名。
信任链（Chain of Trust）的延伸
  • 根CA证书：位于信任链顶端，是自签名的（用自己的私钥签自己的证书），被操作系统/浏览器预先信任。
  • 中间CA证书：为了安全和管理方便，根CA通常不会直接签发最终用户证书，而是签发给“中间CA”。中间CA再用其私钥签发最终用户的证书。
  • 验证过程：客户端需要验证从最终用户证书到根CA证书的完整信任链。服务器通常会发送完整的证书链（用户证书 + 中间CA证书），客户端逐级验证签名，直到找到一个它信任的根CA。

3. 数字证书如何有效防止中间人攻击（MitM）？

假设攻击者（Mallory）试图拦截 www.example.com 的通信：

  1. Mallory可以拦截服务器发来的证书，但她无法伪造一个有效的证书。
  2. 如果Mallory用自己的密钥对生成一个假证书（声称自己是 www.example.com），当客户端收到这个假证书时：
    • 客户端会尝试用内置的受信任CA列表中的公钥来验证假证书上的签名。
    • 由于假证书的签名是用Mallory的私钥生成的，而Mallory的公钥不在客户端的受信任CA列表中，因此验证会失败。
    • 客户端（浏览器）会立即弹出安全警告（如“此网站的安全证书有问题”），提示用户连接不安全，从而阻止了攻击。

总结

数字证书通过以下机制解决了公钥信任问题：

  1. 身份绑定：将实体的身份信息与其公钥在证书中明确关联。
  2. CA背书：由受信任的第三方权威机构（CA）对这种绑定关系进行数字签名，提供可信证明。
  3. 信任链验证：客户端通过内置的受信任根CA列表，逐级验证证书链上的签名，确保整个链条的可信度。
  4. 防篡改：CA的数字签名保证了证书内容的完整性，任何篡改都会导致验证失败。

http://www.xdnf.cn/news/18322.html

相关文章：

  • 基于SpringBoot的流浪动物领养管理系统【2026最新】
  • 常见的端口扫描
  • 常德二院全栈国产化信创项目：开启医疗新质生产力的“头雁”之旅
  • Android 定位技术全解析：从基础实现到精准优化
  • 数据大屏全链路质量保障测试
  • 消息中间件（RocketMQ+RabbitMQ+Kafka）
  • C++手撕LRU
  • RocketMQ 消息消费 单个消费和批量消费配置实现对比(Springboot)，完整实现示例对比
  • 链表-143.重排链表-力扣(LeetCode)
  • SQL视图、存储过程和触发器
  • npm全局安装后，cmd命令行可以访问，vscode访问报错
  • Django REST框架核心：GenericAPIView详解
  • GitHub Push 认证失败 fatal Authentication failed
  • OceanBase 分区裁剪（Partition Pruning）原理解读
  • Binlog Server守护MySQL数据0丢失
  • 基于Pytochvideo训练自己的的视频分类模型
  • python中view把矩阵维度降低的时候是什么一个排序顺序
  • 机器学习——数据清洗
  • 【论文阅读】Multi-metrics adaptively identifies backdoors in Federated Learning
  • Linux 文本处理与 Shell 编程笔记：正则表达式、sed、awk 与变量脚本
  • 本地文件上传到gitee仓库的详细步骤
  • Excel表格复制到word中格式错乱
  • Nginx 的完整配置文件结构、配置语法以及模块详解
  • 【学习笔记】大话设计模式——一些心得及各设计模式思想记录
  • Vue3全局配置Loading的完整指南：从基础到实战
  • PyTorch API 4
  • Mac 4步 安装 Jenv 管理多版本JDK
  • Linux Capability 解析
  • strncpy 函数使用及其模拟实现
  • 为什么我的UI界面会突然卡顿，失去响应