应用密码学与网络安全期末复习：密钥交换、TLS握手与高频考点解析

简介：这份资源是西安电子科技大学计算机科学与技术专业网络方向「应用密码学与网络安全」期末考试的复习要点整理，面向正在备考该课程的学生，尤其适合需要快速梳理考点、把握题型分布的学习者。内容紧扣PPT授课范围，覆盖选择题与大题两类题型，并系统归纳了计算题、问答题与应用题的常见考法。资源包内含1个PPT文件，大小约1.94MB，以课件形式集中呈现各章节重点。从内容预览看，要点涉及OSI安全框架、安全攻击类型与安全服务机制，DES、AES、Feistel结构、S盒与雪崩效应，双重DES的中间相遇攻击、分组密码工作模式，DH密钥交换与中间人攻击，Hash函数、消息认证码与数字签名，以及密钥分发、Kerberos认证、SSL握手、IPSec传输与隧道模式等核心章节。目前已有1048人学习下载，适合考前对照PPT逐章查漏补缺，快速建立知识框架并锁定高频考点。

1. 应用密码学与网络安全期末：从密钥交换到TLS握手，哪些考点年年绕不开

如果你正在准备应用密码学与网络安全的期末考试，大概率已经发现一个规律：这门课不像操作系统那样靠刷题量堆分数，也不像数据结构那样有固定套路。它考的是你对“安全机制为什么成立”的理解，以及“某个环节被替换后会发生什么”的推演能力。密钥交换、分组密码工作模式、消息认证码、数字签名、PKI证书链、TLS握手流程——这些名词在往年卷子里反复出现，但每次换一个角度问，就能筛掉一批只背了定义的人。

我带过几轮复习，也见过不少同学在这门课上翻车。最常见的误区是把密码学当成数学公式去记，结果遇到“为什么CBC模式需要IV而ECB不需要”这种题就卡住了。其实这门课的复习逻辑很清楚：先把安全目标（机密性、完整性、认证性、不可否认性）和对应机制（加密、MAC、签名、证书）的映射关系理清楚，再逐个攻破每个机制的核心参数和典型攻击场景。这篇笔记就按这个思路，把往年高频考点拆成可复现的复习路径，从对称加密到公钥基础设施，再到TLS握手抓包验证，每一步都给出具体操作和参数含义。

适合谁看？如果你已经上过一轮课但知识点还是散的，或者做题时总在“感觉见过但说不清楚”的状态，这篇内容能帮你把零散概念串成一条线。如果你基础不错，可以直接跳到第4章的避坑部分，那里列了几个往年卷子里反复出现的陷阱题。

2. 对称加密与分组模式：从DES到AES，工作模式怎么选怎么算

2.1 分组密码的核心参数：密钥长度、分组长度与轮数

复习对称加密，先抓住三个参数：密钥长度、分组长度、轮数。DES的密钥表面是64位，实际有效密钥56位（8位奇偶校验），分组64位，16轮Feistel结构。AES分组固定128位，密钥可选128/192/256位，轮数分别是10/12/14轮。考试里常考的点不是让你背轮数，而是问“为什么DES的56位密钥现在不安全”——答案要落到穷举空间2^56≈7.2×10^16，以现代算力可以暴力破解，而AES-128的2^128空间目前仍被认为安全。

Feistel结构的核心性质是加密和解密可以共用同一套电路，只要把子密钥顺序反过来。这个性质在简答题里经常出现，比如“说明Feistel结构为什么解密不需要单独设计算法”。答题时要把“左右两半交换后异或”这个操作讲清楚，而不是只写“因为对称”。

AES的S盒设计涉及有限域GF(2^8)上的乘法逆元和仿射变换，这部分如果课上没展开，考试一般不会深究数学推导，但可能考“S盒的作用是什么”——非线性替换，抵抗线性密码分析和差分密码分析。

2.2 工作模式对比：ECB、CBC、CFB、OFB、CTR的适用场景

工作模式是这门课最容易出计算题和对比题的地方。先看一张参数对比表：

ECB最大的问题是相同明文块产生相同密文块，经典例子是“ECB模式加密图片后仍能看出轮廓”。CBC通过前一块密文与当前明文异或来消除这个规律，但加密必须串行。CTR模式把分组密码变成流密码，可以并行，适合高吞吐场景。

考试里常考的计算题是CBC模式的加密过程。给一个简单例子：假设分组长度8位，密钥K，明文P1=10110001，P2=01101001，IV=00000000，加密函数E简化为按位取反。那么C1=E(P1⊕IV)=E(10110001)=01001110，C2=E(P2⊕C1)=E(01101001⊕01001110)=E(00100011)=11011100。这类题的关键是每一步都写清楚异或对象是谁。

2.3 用Python验证CBC与CTR的加密差异

光看表格不够，动手跑一遍才能记住。下面用Python的cryptography库演示CBC和CTR对同一明文的不同输出：

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes from cryptography.hazmat.backends import default_backend import os key = os.urandom(16) # AES-128密钥 iv = os.urandom(16) # 初始化向量 plaintext = b"SecurityExam2024" # 16字节明文 # CBC模式 cipher_cbc = Cipher(algorithms.AES(key), modes.CBC(iv), backend=default_backend()) encryptor_cbc = cipher_cbc.encryptor() ct_cbc = encryptor_cbc.update(plaintext) + encryptor_cbc.finalize() print("CBC密文:", ct_cbc.hex()) # CTR模式 nonce = os.urandom(8) # CTR的nonce通常为8字节 cipher_ctr = Cipher(algorithms.AES(key), modes.CTR(nonce), backend=default_backend()) encryptor_ctr = cipher_ctr.encryptor() ct_ctr = encryptor_ctr.update(plaintext) + encryptor_ctr.finalize() print("CTR密文:", ct_ctr.hex())

这段代码的逻辑说明：CBC模式需要16字节IV，且IV必须随机且不可预测；CTR模式需要nonce，计数器从nonce开始递增。参数上，key长度决定AES变体，iv/nonce的长度必须与分组长度匹配（CTR的nonce加计数器总长等于分组长度）。运行后你会发现同一明文在两种模式下密文完全不同，而且CBC的密文长度必须是分组的整数倍，不足需要填充。

考试里如果问“为什么CTR模式不需要填充”，答案就是它本质上是流密码，逐位或逐字节异或，密文长度等于明文长度。

3. 消息认证与数字签名：HMAC、RSA签名与证书链验证

3.1 HMAC的构造与密钥长度选择

消息认证码解决的是完整性和认证性，不解决机密性。HMAC的构造是H(K⊕opad || H(K⊕ipad || M))，其中opad=0x5c重复，ipad=0x36重复。考试常问“HMAC为什么要用两次哈希”——目的是防止长度扩展攻击。如果直接用H(K||M)，攻击者可以在不知道K的情况下构造H(K||M||padding||M')，因为哈希函数是迭代的。

密钥长度方面，HMAC的密钥如果短于哈希输出长度，安全性会降低。推荐密钥长度不小于哈希输出长度的一半。比如HMAC-SHA256，密钥至少128位。

3.2 RSA签名与验签的数学步骤

RSA签名的核心是私钥加密、公钥解密（实际上是用私钥做模幂运算）。步骤：选择两个大素数p和q，计算n=pq，φ(n)=(p-1)(q-1)，选择e满足1<e<φ(n)且gcd(e,φ(n))=1，计算d=e^(-1) mod φ(n)。签名时s=m^d mod n，验签时m'=s^e mod n，比较m'与m。

考试里常给一个小整数例子让你算。比如p=3，q=11，n=33，φ(n)=20，选e=3，则d=7（因为3×7=21≡1 mod 20）。签名m=5，s=5^7 mod 33。计算5^2=25，5^4=25^2=625 mod 33=625-18×33=625-594=31，5^7=5^4×5^2×5=31×25×5=3875 mod 33。3875÷33=117余14，所以s=14。验签14^3 mod 33=2744 mod 33=2744-83×33=2744-2739=5，与m一致。

这类题的关键是模幂运算不要算错，建议用平方-乘算法逐步算。

3.3 用OpenSSL验证证书链与签名

理论讲完，用OpenSSL实际验证一次证书链。假设你有一个服务器证书server.crt、中间证书intermediate.crt、根证书root.crt：

# 验证证书链 openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt # 查看证书签名算法 openssl x509 -in server.crt -noout -text | grep "Signature Algorithm" # 验证签名（用中间证书公钥验证服务器证书签名） openssl x509 -in server.crt -noout -pubkey > server_pub.pem openssl dgst -sha256 -verify server_pub.pem -signature <(openssl x509 -in server.crt -noout -text | grep -A1 "Signature Value" | tail -1 | xxd -r -p) <(openssl x509 -in server.crt -noout -text | sed -n '/TBSCertificate/,/Signature Value/p' | head -n -1)

上面第三条命令比较复杂，实际考试不会要求这么细。但你要理解证书链验证的逻辑：用上一级CA的公钥验证下一级证书的签名，直到根证书。根证书是自签名的，需要预先信任。

参数说明：-CAfile指定信任锚，-untrusted指定中间证书，-pubkey提取公钥。如果验证失败，常见原因是中间证书缺失或根证书不在信任列表。

4. 避坑与常见问题：往年卷子里最容易翻车的五个点

4.1 把“加密”和“认证”混为一谈

现象：题目问“如何保证消息既机密又完整”，有同学只写“用AES加密”。原因：加密只提供机密性，不提供完整性。攻击者可以在不知道密钥的情况下篡改密文，解密后得到乱码但系统可能不报错。解决：加密和MAC要组合使用，常见方案是Encrypt-then-MAC，即先加密再对密文计算HMAC。

4.2 CBC模式IV可预测导致选择明文攻击

现象：题目描述“IV按顺序递增”，问有什么风险。原因：CBC的IV如果可预测，攻击者可以构造明文让第一块密文与目标密文比较，从而逐字节猜测。解决：IV必须随机且不可预测，不需要保密但必须每次不同。

4.3 RSA签名忘记填充导致伪造

现象：题目问“RSA签名直接对消息哈希值签名有什么问题”。原因：没有填充的RSA签名存在可乘性，攻击者可以将两个签名相乘得到第三个有效签名。解决：使用PKCS#1 v1.5或PSS填充方案。

4.4 证书链验证忽略有效期和吊销状态

现象：验证通过但证书已过期。原因：openssl verify默认检查有效期，但有些手动验证脚本会跳过。解决：检查notBefore和notAfter字段，必要时查询CRL或OCSP。

4.5 TLS握手版本混淆

现象：题目问“TLS 1.2和TLS 1.3的握手有什么区别”，答不上来。原因：TLS 1.3把密钥交换和认证合并，减少了往返次数，且废除了RSA密钥交换。解决：记住TLS 1.3的1-RTT和0-RTT模式，以及它只支持前向安全的密钥交换。

5. 用Wireshark抓一次TLS握手：从ClientHello到ApplicationData

5.1 抓包环境准备与过滤规则

先在本机启动一个HTTPS服务，或者直接访问一个HTTPS网站。打开Wireshark，选择网卡，设置过滤规则tcp.port==443。为了只看到握手过程，可以再加过滤条件tls.handshake。如果你访问的是TLS 1.3，Wireshark可能显示为TLSv1.3，但握手记录类型仍然是ClientHello、ServerHello等。

注意：如果网站使用了TLS 1.3，ServerHello之后的证书等消息会被加密，Wireshark无法直接解析。这时可以设置环境变量SSLKEYLOGFILE让浏览器导出密钥，然后在Wireshark的TLS协议设置里指定该文件。

5.2 逐字段解读ClientHello与ServerHello

ClientHello里重点看：版本号（supported_versions扩展）、随机数（Random）、会话ID、密码套件列表（Cipher Suites）、扩展（Extensions）。密码套件格式是TLS_密钥交换_认证_加密_哈希，比如TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。

ServerHello里看：选定的版本、随机数、会话ID、选定的密码套件。如果服务器支持TLS 1.3，还会发送KeyShare扩展。

考试里常考“ClientHello的随机数作用是什么”——用于生成会话密钥，防止重放攻击。

5.3 从握手到应用数据的密钥推导路径

TLS 1.2的密钥推导：pre_master_secret由密钥交换算法生成（如ECDHE的共享密钥），然后通过PRF（伪随机函数）用client_random、server_random、pre_master_secret生成master_secret，再推导出会话密钥。TLS 1.3简化了这个过程，直接用HKDF从共享密钥和握手上下文推导。

验证方法：在Wireshark里找到Encrypted Handshake Message和Application Data，如果配置了SSLKEYLOGFILE，可以解密看到HTTP请求内容。

5.4 用tshark命令行提取握手关键字段

如果不想开图形界面，用tshark命令行：

# 提取ClientHello的密码套件列表 tshark -r capture.pcap -Y "tls.handshake.type == 1" -T fields -e tls.handshake.ciphersuite # 提取ServerHello选定的密码套件 tshark -r capture.pcap -Y "tls.handshake.type == 2" -T fields -e tls.handshake.ciphersuite # 统计TLS版本分布 tshark -r capture.pcap -Y "tls.handshake.type == 1" -T fields -e tls.handshake.version | sort | uniq -c

参数说明：-Y是显示过滤器，-T fields指定输出字段，-e指定字段名。这些命令在复习时可以用来快速验证你对握手字段的理解。

我自己的习惯是考前把TLS 1.2和1.3的握手流程图各画一遍，不看书，画完再对照RFC检查。画错的地方就是知识盲区。另外，密码学计算题一定要动手算，模幂运算和CBC加密至少各做五道，不然考场上容易在细节上丢分。希望帮到你。

本文还有配套的精品资源，点击获取