简介围绕公钥、私钥、数字签名与数字证书展开的密码学学习总结面向刚接触信息安全、Web 开发或需要厘清加密体系基础概念的读者用于补齐单钥加密、双钥加密及证书验证之间的知识链路。正文从单钥与双钥加密的差异讲起说明密钥保存的重要性、公钥与私钥一一对应且难以反推的关系串联 DES、RSA 等典型算法并借鲍勃与苏珊的通信示例拆解 Hash 摘要、私钥签名、公钥验签以及 CA 颁发证书的完整流程最后落到 HTTPS 网页加密中的身份认证与完整性校验。压缩包内含 1 个 docx 文档大小约 310KB结构集中便于直接阅读、摘录笔记或按概念复盘。已有 627 人学习可作为理解公钥基础设施、数字签名应用和数字证书验证思路的入门材料也能帮助读者把抽象术语对应到具体通信场景形成较清晰的知识框架。1. 从一把钥匙到两把钥匙密码学知识地图先铺开公钥、私钥、数字签名、数字证书这四个词几乎撑起了密码学入门阶段的全部骨架也最容易被学成一团糨糊。反直觉的地方在于算法名字DES、RSA反而是最不容易记错的部分真正容易出错的是两件事——钥匙该往哪个方向用以及手里那把公钥到底是谁的。前者决定你把加密和签名做反没有后者决定 HTTPS 里那把小锁是不是真的可信。整条链路可以连成一条线单钥加密解决不了密钥分发于是有了双钥双钥解决了分发又冒出来公钥被掉包的问题于是有了数字签名和数字证书。顺着这条线复习每个概念都能找到它“为什么存在”的位置而不是背一堆孤立定义。这张地图适合两类人正在系统学密码学基础的和考前想快速把概念串一遍的。2. 单钥与双钥两套加密体系的对照两套体系的根本差异不在算法强弱而在钥匙怎么放。单钥把安全性全押在“钥匙不泄漏”上双钥把安全性押在“私钥推不出来”上。这个差别决定了后面所有的工程实践为什么对称加密快却难管为什么非对称加密慢却必须先握手为什么真实系统最后往往两套一起用。复习这部分重点不是记住 DES 和 RSA 两个缩写而是能说清每一套的适用边界和薄弱环节在哪。2.1 单钥加密一把钥匙的两头与密钥保管的软肋单钥加密也叫对称加密加密和解密用的是同一套密钥。历史上人类传统的加密方法基本都属于这一类早期机械式转子密码机靠每天更换转子初始位置来加密莫尔斯电码的替换表也可以看作一种私钥加密思路——严格说莫尔斯电码是编码而非加密教材里常拿它做类比理解时别把“编码”和“加密”混为一谈前者不含密钥后者一旦没有密钥就解不开。这种体系的结构极其简单一把钥匙锁门开门都用它。简单带来两个后果。好处是速度快、适合大批量数据坏处是密钥的保存变得异常关键一旦泄漏整套密码就等于被破解而且没有任何补救余地历史上有不少案例密钥一旦泄漏之前的全部密文都要重新加密。工程上更关键的是分发问题。密钥要送到通信对方手里这个“送”的过程本身就需要一条安全通道于是形成循环依赖为了安全通信先要安全地传密钥。再看规模n 个人两两之间都要通信需要的密钥数量是 n(n-1)/210 个人 45 把100 个人 4950 把1000 个人接近 50 万把。密钥管理很快就会变成灾难这也是双钥体系出现的直接动因。2.2 双钥加密公钥私钥的四条硬性质双钥加密也叫非对称加密密钥有两把一把公开的公钥一把不公开的私钥。它的全部安全性建立在四条性质上这四条是后面所有推论的源头值得逐条抠清楚。性质原始表述复习时要能推出的结论一一对应有一把公钥就必然有一把与之对应的、独一无二的私钥反之亦然公钥不能凭空捏造出第二个匹配的私钥身份绑定才有可能对所有唯一所有的公钥, 私钥对都是不同的不存在两对完全相同的密钥密钥空间足够大双向可解用公钥可以解开私钥加密的信息反之亦然加密和签名两个方向都依赖这一条也是最容易用反的地方生成容易、反推困难同时生成公私钥相对容易从公钥推算私钥很困难或不可能公钥可以放心公开安全性不依赖公钥保密第四条是整个体系的基石它依赖数学上的单向难题大整数分解、离散对数、椭圆曲线离散对数等。所谓“单向”是指正向计算很轻松反向求解在计算上不可行。复习时不要只背“反推困难”四个字要能说出它依赖哪类数学问题以及“困难”是相对当前计算能力而言的不是绝对不可能。还有一个常被忽略的细节四条性质里第三条写的是“互相可解”但两种“解”的目的完全不同。用公钥解私钥加密的内容得到的是签名验证结果用私钥解公钥加密的内容得到的是明文。这两个方向对应两种完全不同的使用场景混用会直接导致安全模型崩塌。2.3 DES 与 RSA两套体系的代表与时代坐标通用的单钥加密算法代表是 DES通用的双钥加密算法代表是 RSA两者都产生于上世纪 70 年代。这个时间点值得记它标志着加密从“手艺”变成“标准”也标志着非对称加密正式进入实用阶段。维度单钥对称双钥非对称密钥数量1 把2 把公钥、私钥密钥分发必须走安全通道否则全盘皆输公钥可公开传递私钥不出本机运算速度快慢通常比对称慢几个数量级代表算法DESRSA主要用途大批量数据加密密钥协商、数字签名主要短板密钥管理成本高计算开销大、公钥真实性无解DES 的 56 位密钥在今天看来偏短后来逐步被更强的对称算法替代但它作为“对称加密标准化”的起点考试和面试里出现的频率依然很高。RSA 则长期占据非对称加密的主流位置理解它的关键不是会算大数模幂而是理解“公钥公开、私钥自留”这个前提如何支撑起密钥分发和身份认证。2.4 密钥分发对比双钥到底解决了什么把两套体系放在一起看双钥真正解决的是密钥分发而不是“加密更强”。单钥体系里密钥本身就是秘密传递密钥等于传递秘密双钥体系里公钥可以贴在公告板上、写进网页里任何人都能拿到秘密只在私钥那一端。这样一来通信双方不需要预先共享秘密就能建立起加密通道。代价也很明显非对称运算慢。梳理下来会发现真实系统几乎不会用 RSA 去加密整段正文而是采用混合加密——先用非对称加密协商出一把临时的对称会话密钥之后的数据全部走对称加密。HTTPS 就是这个思路的典型握手阶段用非对称运算解决“密钥怎么安全地商量出来”正文传输阶段用对称运算解决“快不快”。提示很多图解材料为了讲清楚原理会说“服务器用私钥加密网页再发给客户端”这是教学简化。真实 TLS 握手里服务器的私钥主要用于对握手消息签名证明“我确实是证书上那个域名的主人”正文数据由协商出来的对称密钥加密。理解了这一层再看“为什么有了公钥还要证书”逻辑就顺了公钥可以公开但公开的公钥不一定属于你以为的那个人。3. 数字签名Hash 摘要、私钥签名与验签链路数字签名解决的是另一个问题——这段信息是不是你发的中途有没有被改过。它和加密是两套目标加密防的是“别人看见”签名防的是“别人冒充”和“内容被改”。把这两个目标分开是复习这一章最重要的一步因为绝大多数混淆都来自把它们当成同一件事。3.1 一次完整签名从 Hash 摘要到附信发送用 A发信方、B收信方、C冒充者三个角色把链路走一遍比背定义有效得多。A 生成一对公私钥把公钥交给 B 和朋友们每人一份。B 要给 A 写一封保密信用 A 的公钥加密正文A 收到后用私钥解密。只要 A 的私钥不泄漏这封信即使落在别人手里也解不开。A 回信时决定用数字签名。他先对信件正文做 Hash得到一个定长的摘要。A 用自己的私钥对这个摘要做运算得到签名值。A 把签名附在信件下面一起发给 B。B 收到后先取下签名用 A 的公钥还原出摘要。B 再对收到的信件正文做同样的 Hash把两个摘要对比。一致说明信确实是 A 发的且中途没有被改。这条链路里有三个容易记混的点。第一签名针对的是摘要不是正文第二签名用的是 A 的私钥不是 B 的公钥第三验签用的是 A 的公钥解出来的是摘要不是信件内容。把这三句话背下来比背七个步骤更管用。3.2 验签的两步先解签名再比对摘要验签的本质是两次比对缺一不可一次是“用公钥还原出的摘要”一次是“对正文重新算出的摘要”。两步都通过才说明来源可信且内容完整。import hashlib def make_digest(payload: bytes) - bytes: # 摘要算法把任意长度的正文压成固定长度输出 # 这里用 SHA-256输出恒为 32 字节 return hashlib.sha256(payload).digest() # 签名侧示意 # 1. 先对正文做摘要 # 2. 再用签名者私钥对摘要做签名运算 # signature sign_with_private_key(make_digest(payload)) # 验签侧示意 # 1. 用签名者公钥从签名中还原出摘要 # recovered verify_with_public_key(signature) # 2. 对收到的正文重新摘要再比对 # ok (recovered make_digest(received_payload))代码里hashlib.sha256是标准库调用负责摘要部分私钥签名和公钥验签用注释示意因为真实实现并不是“拿私钥把摘要加密一遍”这么简单——RSA 签名要带填充和编码教材为了讲原理才简化成“私钥加密摘要”。这个简化在理解方向时够用但别把它当成实现细节去写代码。参数上有两点要注意摘要算法的输出长度是固定的SHA-256 是 32 字节所以无论正文多大签名运算处理的数据量都一样签名值的长度由密钥长度和填充方案决定和正文长度无关。这也解释了为什么大文件也能高效签名。3.3 为什么先 Hash效率、定长与不可逆很多人会问既然私钥能签名为什么不直接对正文签名三个原因按重要性排序。效率。非对称运算慢对几十 MB 的正文直接做签名运算耗时会非常夸张。先压成 32 字节的摘要签名运算的开销就固定了和文件大小基本无关。定长。非对称算法一次能处理的数据块长度有限正文一长就必须分块分块之后还要处理块间顺序和边界复杂度陡增。摘要把任意长度输入变成固定长度输出一次性解决。安全。摘要不可逆签名值里不包含正文任何可直接还原的信息同时摘要对输入极度敏感正文改一个字节摘要就面目全非这就是所谓的雪崩效应。正因为如此篡改正文后想凑出一个相同的摘要计算上不可行。注意Hash 必须选抗碰撞性足够的算法。早期的一些摘要算法已经不再安全复习时记住一条底线——签名场景用 SHA-256 及以上不要拿过时算法凑数。3.4 签名能证明什么、不能证明什么这是考点密集区也是实际工作中最容易误解的地方。把“能”和“不能”列清楚比记流程更有价值。能证明不能证明完整性正文未被修改保密性签名不加密正文正文仍是明文来源认证签名者持有对应私钥签名者“自愿”私钥被盗用时代签无法区分不可否认性签名者事后难以抵赖时效性签名不说明什么时候签的需时间戳配合最容易错的是第一行右边那条数字签名不提供保密性。签名附在信件下面信件本身如果是明文任何人拿到都能读。需要保密时得先用对方的公钥加密正文再做签名两个机制叠加使用。顺序上一般建议先签名再加密这样接收方可以先确认来源再解密也能避免把签名暴露给中间人。还有一条常被忽略签名证明“私钥持有者签了这份摘要”但证明不了“这个人当时是清醒的、自愿的”。私钥保管不当导致的代签在密码学层面和本人签名无法区分这类问题只能靠密钥管理和审计去补不是算法能解决的。4. 数字证书与 CA公钥的身份证明与 HTTPS 校验签名解决了“内容有没有被改”但没解决“你手里的公钥是不是真的属于那个人”。第 3 章第 6 步里B 用 A 的公钥验签前提是这把公钥确实来自 A。如果这个前提被推翻整套签名机制就是空中楼阁。数字证书要处理的正是这个前提。4.1 中间人换公钥证书要堵的那个洞设想 C 想冒充 A 给 B 发信。C 有自己的公私钥但他没法让 B 相信那是 A 的。于是 C 找机会接触 B 的设备把 B 手里保存的“A 的公钥”替换成“C 的公钥”。B 并不知情仍然以为这是 A 的公钥。此后 C 用自己的私钥做签名B 用被替换过的公钥验签一路通过签名机制完全失效。这个场景的关键在于签名算法本身没有任何问题出问题的是公钥的来源。B 无法凭公钥本身判断它属于谁因为公钥只是一串数字没有任何身份信息。要堵这个洞必须引入一个双方都信任的第三方给公钥做背书。提示这类攻击在教材里叫中间人攻击核心不是破解算法而是替换信任锚点。复习时把“算法安全”和“密钥真实性”当成两个独立问题看很多困惑就解开了。4.2 CA 签发证书里装了什么证书颁发机构CA扮演的就是这个可信第三方。A 把自己的公钥和身份信息交给 CACA 核验之后用自己的私钥对“A 的公钥 相关信息”做签名生成数字证书。证书的本质是一张被 CA 签过名的公钥声明我CA证明这把公钥属于这个主体。一张典型证书里装着这些字段复习时按“谁签的、签了谁、签了什么、什么时候有效”四问去记字段作用校验时的意义主体信息证书持有者的标识核对是不是你要访问的对象公钥持有者的公钥后续加密或验签就用它颁发者签发这张证书的 CA决定用哪把公钥去验证书签名有效期起止时间过期即失效浏览器直接告警签名算法CA 签名用的算法决定验证方式签名值CA 私钥对上述内容的签名防止证书内容被篡改A 拿到证书后再给 B 发信时把签名和证书一起附上。B 收到后先用 CA 的公钥解开证书确认里面装的确实是 A 的公钥再用这把公钥验签。整条信任链从“我信任 CA”传递到“我信任这把公钥属于 A”。4.3 HTTPS 握手里的证书校验三步HTTPS 是数字证书最典型的落地场景。客户端和服务器建立连接时服务器会把证书一起发过来客户端要做的事情可以拆成三步验证书签名、查信任链、核对域名和有效期。def check_server_cert(cert, host, trusted_roots): # 第一步用签发者公钥验证证书上的签名 # 确认证书内容尤其是公钥和主体没有被篡改 if not verify_signature(cert.signature, cert.body, issuer_public_key(cert)): return 证书签名无效 # 第二步沿证书链向上追溯 # 直到命中本地“受信任的根证书”列表 if not chain_to_trusted_root(cert, trusted_roots): return 颁发者不在受信任列表 # 第三步核对证书记载的域名与当前访问域名是否一致 if not match_hostname(cert.subject_alt_name, host): return 域名不匹配 # 第四步核对有效期 if not within_validity(cert.not_before, cert.not_after): return 证书已过期或尚未生效 return 通过函数里四个参数分别对应四类检查cert是服务器发来的证书host是当前访问的域名trusted_roots是浏览器或操作系统内置的根证书列表。四步里任何一步失败连接都不应该继续。实际实现中还会有吊销检查、证书链长度限制、算法强度限制等附加项但主干就是这四步。这里有个细节值得注意客户端验证书签名用的是“签发者的公钥”而签发者公钥的可信度又来自上一级证书一层层往上追最终落到本地预置的根证书。这条链上任何一环出问题整条链都不可信。所以“受信任的根证书列表”本质上是信任的起点浏览器和操作系统更新它就是在更新信任锚点。4.4 三种典型告警过期、域名不匹配、颁发者不受信浏览器弹出的证书告警看起来都差不多背后的原因和排查方向完全不同。把这三类分清楚处理线上问题时能省很多时间。告警类型典型现象根本原因排查方向证书过期提示有效期已过续期流程没跑或系统时间异常查证书到期时间、查服务器时间域名不匹配提示证书名称与网站不符证书签给了别的域名或用了泛域名但层级不对核对证书里的域名列表与实际访问域名颁发者不受信提示证书不是受信任机构颁发自签名证书、根证书未预置、证书链不完整查证书链是否完整、根证书是否在信任列表排查顺序建议反过来先看域名再看有效期最后看颁发者。域名不匹配是最常见也最容易确认的有效期次之颁发者问题往往涉及证书链配置需要看服务器是否把中间证书一起发出来。缺了中间证书客户端可能无法把证书链接到根证书上表现出来的就是“颁发者不受信”。5. 易漏易错点五处最容易出错的地方这一章不铺新知识只把前面几章里最容易记反、记漏、记混的地方单独拎出来。每一条都按“易错点 → 为什么会错 → 怎么补”写复习时可以直接当自检清单用。5.1 密钥方向层面的两个混淆易错点一把加密和签名的方向用反。表现为以为“公钥加密、私钥解密”可以套用到签名场景写成“用公钥签名、用私钥验签”。为什么会错两把钥匙“互相可解”这条性质太顺口很多人只记住了“配对”没记住“谁持有私钥谁就是签名者”。怎么补记一句口令——公钥加密保机密私钥签名证身份。再往深一层想加密是“我希望只有你能看”所以用对方的公钥签名是“我要证明是我发的”所以用自己的私钥。把“目的”和“钥匙归属”绑在一起记比死记方向可靠。易错点二把“公钥能解私钥加密的内容”推广成“公钥能解密任何东西”。表现为认为签名验证就是“用公钥把签名解密成原文”。为什么会错教材为了简化常说“私钥加密摘要、公钥解密摘要”于是有人顺推出“公钥能还原正文”。实际上签名场景里公钥还原出来的是摘要正文从来没有被私钥加密过。怎么补在纸上画两条独立链路——加密链路是“公钥加密正文 → 私钥解出正文”签名链路是“私钥签摘要 → 公钥还原摘要 → 比对摘要”。两条链路的输入输出完全不同画一遍就分清了。5.2 签名与证书层面的三个盲区易错点三以为做了数字签名内容就保密了。表现为系统里加了签名机制就认为传输内容不会被偷看。为什么会错签名和加密是两个正交的目标签名只保证完整性和来源不改变正文的可见性。签名附在明文下面抓包就能读到全部内容。怎么补需要保密时加密和签名要叠加使用先用接收方公钥加密正文再对密文或明文做签名接收方先验签再解密。把“机密性靠加密、完整性靠签名”当成两条独立的检查项别指望一个机制干两件事。易错点四以为有证书就一定可信。表现为看到浏览器地址栏有小锁就放心输入敏感信息或者在自己的服务里信任了自签名证书。为什么会错证书只证明“这把公钥被某个 CA 签过”不证明“这个 CA 是你信任的”也不证明“证书里的域名就是你要访问的”。域名不匹配的证书、过期证书、由未知机构签发的证书都可能带着一张合法的签名。怎么补养成三步核对习惯——域名对不对、有效期在不在、颁发者在不在信任列表。自签名证书在测试环境可以用但绝不能进生产信任链。易错点五只验签名不比对摘要。表现为实现了“用公钥还原摘要”这一步就认为验签完成了漏掉了“对正文重新算摘要再比对”。为什么会错还原摘要这一步只证明签名本身有效如果正文被整体替换、签名也跟着替换单看还原结果发现不了问题。怎么补把验签固定成两步缺一不可——先还原摘要再重算摘要两者相等才通过。代码层面可以把这两步封成一个函数调用方只拿布尔结果避免有人只调一半。这五条里方向用反和“签名不等于保密”出现频率最高。血泪经验是面试里被问“数字签名流程”时能背出步骤的人不少能说清“签名不提供保密性”的人立刻少一半。复习时不妨拿这五条反过来考自己能逐条说清原因这一块基本就稳了。6. 复习清单一页纸自检与查漏补缺的走法复习到最后一章不建议再从头翻材料而是拿一张纸把下面这张表默写一遍写不出来的位置就是漏洞所在。概念一句话说清最常见的错单钥加密加解密同一把钥匙快但密钥难分发忽略密钥分发这个根本问题双钥加密公钥公开、私钥自留慢但解决分发把公钥也当秘密保护起来四条性质一一对应、对所有唯一、双向可解、反推困难只背“配对”说不出安全性依赖什么数字签名私钥签摘要公钥验摘要说成“私钥加密正文”数字证书CA 用自己的私钥给公钥背书以为有证书就等于可信HTTPS非对称协商会话密钥对称加密传数据说成“服务器用私钥加密整个网页”默写完表格再做五道自检题每题能在两分钟内说清楚就算过关为什么单钥体系里 100 个人两两通信需要 4950 把密钥而双钥体系只需要 100 对数字签名为什么先做 Hash 再签而不是直接签正文说出效率、定长、安全三个理由。用公钥验签解出来的到底是什么为什么不是正文中间人替换公钥之后签名机制为什么失效证书在哪一步把这条路堵死浏览器提示“证书颁发者不受信任”排查顺序是什么查漏补缺的走法是反着来先做题再回表最后回章节。哪道题卡住就回到对应章节看那一节的“为什么”而不是重读整章。比如第 3 题卡住说明签名链路里“摘要”和“正文”的边界没理清回到 3.2 节把验签两步重新画一遍比从头看一遍效率高得多。还有一个具体技巧把所有“方向”类的知识点画成一张双栏图左栏写“谁持有私钥”右栏写“用谁的钥匙做什么”。加密场景左栏是接收方右栏是“发送方用接收方公钥加密”签名场景左栏是发送方右栏是“发送方用自己的私钥签名”。两个场景的左栏主体不同这是全部混淆的根源。画完这张图再遇到“公钥加密还是私钥加密”这类问题先问“谁持有私钥”答案基本就出来了。从那以后我每次复习到密码学这部分都强制自己先默写这张双栏图再默写证书校验四步最后才去看算法细节。这个习惯让我在一次线上证书告警里少走了很多弯路——先看域名再看有效期最后查证书链十分钟定位到是中间证书没配全而不是证书本身有问题。希望这份清单也能帮到你下次遇到类似的题或者告警能顺着这张地图一步步走回去。本文还有配套的精品资源点击获取
