网络安全课程设计加密技术报告与可运行源码解析

简介这份网络安全课程设计资料围绕加密技术展开面向计算机与网络安全相关专业学生及需要完成课程设计、实验报告的人群可用于理解 RSA 等公钥加密算法的原理、实现流程与报告撰写框架。压缩包共 2 个文件包含 1 个 doc 课程设计报告和 1 个 c 语言源代码文件整体约 596KB报告与代码相互对应便于对照阅读算法说明、模块设计与程序实现。已有 562 人学习下载具备一定的参考与交流价值。读者可从中获取课程设计选题组织、加密算法关键步骤梳理、RSA 程序实现思路以及实验结论与文档排版参考适合用作课程作业撰写、代码复现和答辩准备时的辅助材料也能为后续深入学习密码学与安全编程提供入门参照。1. 打开压缩包先看什么一份能跑通的网络安全课程设计长什么样“网络安全课程设计加密技术报告及源代码”这个名字乍看像期末作业打包拆开才会发现里面是两套东西一套讲原理的文档一套把原理跑起来的代码。同类资源最常见的毛病不是算法写错而是文档和代码互相对不上——报告里画满 AES 轮函数答辩时被问一句“密钥怎么从口令派生出来”就接不上。这份资源包的价值在于两边能对上号对称加密、非对称加密、消息摘要、数字签名四条线每条都有可执行的 Demo报告里的流程能在源码里找到对应函数。它适合正在做安全方向课程设计、需要当场演示的学生也适合写过业务代码、第一次把加密原语落到文件读写上的开发者。下面按“结构—模块—跑通—改造”的次序拆。2. 资源包结构拆解报告、源码与测试数据怎么分工拿到一个带文档的资源包先不要急着打开报告。我的习惯是先看目录树因为目录结构直接暴露了作者对项目的理解程度公共逻辑有没有单独抽出来测试数据是不是齐全入口文件是否清晰。这套资源的组织方式偏工程化docs、src、tests三层分开源码里也没有把四个算法全塞进一个main.py这在课程设计里算比较讲究的写法。2.1 目录树先认清哪几个文件是入口crypto-course-design/ ├── docs/ │ ├── report.docx # 课程设计报告正文 │ ├── report.pdf # 导出稿答辩打印用 │ └── defense.pptx # 答辩幻灯片 ├── src/ │ ├── crypto_utils.py # 密钥派生、填充、哈希等公共函数 │ ├── aes_file.py # 对称加密文件加解密入口 │ ├── rsa_sign.py # 非对称密钥对生成、签名、验签 │ ├── hash_check.py # 摘要单文件/批量校验 │ └── hybrid_demo.py # 混合加密RSA 包会话密钥 AES 加密数据 ├── tests/ │ ├── sample.txt # 小文本快速验证 │ ├── sample.bin # 二进制样本验证分块边界 │ └── run_all.sh # 一键跑完四个模块 ├── requirements.txt └── README.md真正需要先读的是crypto_utils.py四个模块都依赖它填充规则、密钥派生参数、文件头格式都定义在这里。如果这一层没统一后面四个 Demo 很容易出现“A 文件加密的结果 B 文件解不开”的尴尬情况这在课程设计验收时非常常见。tests/sample.bin是用来验证分块边界的文件大小接近 64KB正好能触发“最后一块是否需要填充”的分支不要跳过它直接用文本文件测试。2.2 技术选型Python pycryptodome 的取舍实现语言是 Python 3依赖集中在requirements.txt核心库是pycryptodome。安装方式很直接# 建议先建虚拟环境避免和系统 Python 的包打架 python -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate pip install -r requirements.txt为什么选它而不是cryptography两个原因。第一pycryptodome的接口更贴近教材AES.new(key, AES.MODE_CBC, iv)这一行和报告里“分组密码 工作模式 初始向量”的描述几乎一一对应答辩时对照着讲很顺cryptography的高层封装更工程化但把细节藏得深反而不利于讲清原理。第二RSA 签名部分用的是 PKCS#1 v1.5 填充pycryptodome提供了pkcs1_15这个独立模块签名、验签各一行学生能看懂每一步在做什么。提示如果报告里明确要求“自行实现 AES 算法”不要在文件加密主链路里用纯 Python 手写版。手写实现适合放在附录里跑 NIST 测试向量证明正确性性能和边界处理都撑不住真实文件容易在演示环节暴露问题。还有一种常见误用是把hashlib和pycryptodome的哈希接口混着用比如一边用hashlib.sha256()算摘要一边用Crypto.Hash.SHA256验签。两者输出一致但对象类型不同传给pkcs1_15.verify()时会报类型错误。资源包里统一用Crypto.Hash.SHA256就是为了避开这个坑。2.3 报告骨架验收时会被追问的六个章节文档部分不是凑页数的它的结构和源码是映射关系。下面这张表是我整理出来的对应关系改代码时最好同步改报告不然答辩现场对不上很难看报告章节要写清的内容对应源码需求分析威胁模型保护什么、不保护什么README 使用说明算法原理AES 分组与轮函数、RSA 数学基础、SHA-256 压缩函数docs 附录方案设计文件格式、密钥管理、模块划分crypto_utils.py核心实现关键函数签名与调用流程aes_file.py、rsa_sign.py测试与结果功能用例、性能数据、异常用例tests/run_all.sh安全性分析已知攻击面与方案局限报告正文最容易写空的是“安全性分析”这一节。合格的写法不是罗列“AES 很安全”而是说清楚这套方案防住了什么、没防住什么它能防住文件被直接读取但防不住口令被键盘记录CBC 模式保证了密文块之间有关联但没有完整性认证攻击者翻转密文比特仍能造成明文可预测的变化。把局限写出来比堆十页原理更能体现你真的想过。3. 对称加密模块AES-CBC 从口令派生到分块写盘的完整链路对称加密是整个资源包里代码量最大的一块也是二次开发时改动最频繁的地方。很多课程设计停在这一步能对一段字符串做加解密一换成文件就出问题。原因通常不在 AES 本身而在密钥怎么来、文件怎么分块、尾部怎么处理这三个工程细节上。aes_file.py把这三件事拆开写结构值得照着抄。3.1 密钥派生口令不能直接截断成 16 字节初学者最常见的写法是key password.encode().ljust(16, b\0)把口令补零凑够 16 字节直接当密钥。这种做法有两个硬伤一是口令熵太低攻击者拿字典跑几十万次就能撞出来二是补零后不同口令可能产生相同密钥。正确做法是用 PBKDF2 做密钥派生把迭代次数拉高让每次尝试的计算成本变大。import os from Crypto.Hash import SHA256 from Crypto.Protocol.KDF import PBKDF2 from Crypto.Random import get_random_bytes SALT_LEN 16 KDF_ITER 200_000 # 迭代次数课程设计里写到报告中的安全参数 def derive_key(password: str, salt: bytes) - bytes: 口令 盐 - 32 字节 AES-256 密钥 return PBKDF2( password, salt, dkLen32, # AES-256 要 32 字节 countKDF_ITER, hmac_hash_moduleSHA256, ) def new_salt() - bytes: # 每个文件独立随机盐绝不能全局写死 return get_random_bytes(SALT_LEN)dkLen32对应 AES-256如果报告里写的是 AES-128这里改成 16 即可但密钥长度和AES.new会自动匹配不需要额外传参。count是迭代次数调高更安全但加密变慢20 万次在现代机器上大约是几百毫秒作为课程设计的安全参数足够。salt必须每个文件随机生成并随密文一起存储它的作用不是保密而是让相同的口令派生不出相同的密钥从而阻止彩虹表批量破解。还有一个细节PBKDF2的第一个参数既接受str也接受bytes但内部编码方式不同。统一传str更稳避免在 Windows 和 Linux 上因为默认编码差异派生出不同密钥导致“同一口令换台机器就解不开”的异常情况。3.2 文件头设计魔数、原始长度、盐与 IV加密文件不能只写密文否则解密端不知道盐和 IV 在哪也不知道明文原本多长。aes_file.py在文件开头写了一段固定长度的头import struct MAGIC bENCF # 4 字节魔数用来识别自家格式 HEAD_LEN 4 8 SALT_LEN 16 # 魔数 原长 盐 IV def build_header(size: int, salt: bytes, iv: bytes) - bytes: # Q 表示大端 8 字节无符号整数跨平台字节序一致 return MAGIC struct.pack(Q, size) salt iv四个字段各有用途。MAGIC是格式标识解密前先比对能挡住“拿错文件”这类低级错误原始长度用 8 字节大端存储解密完按这个长度截断避免填充字节混进明文盐和 IV 都是 16 字节直接拼在头里。整个头 44 字节读取时一次性读满再解析不要用多次read(4)、read(8)这种写法否则文件句柄位置很容易算错。注意IV 不需要保密但必须每次加密都重新随机生成。CBC 模式下如果两次加密用同一个密钥和同一个 IV相同的前缀会产生相同的密文攻击者能直接看出来两个文件开头一样。这一点在报告的安全性分析里值得单独写一段。3.3 分块加解密实现与 20MB 文件回归验证文件读写用固定大小的块循环不要一次性read()整个文件。块大小取 64KB必须是 16 的整数倍因为 AES 分组长度是 16 字节CBC 要求每个输入块对齐。from Crypto.Cipher import AES CHUNK 64 * 1024 # 64KB16 的整数倍 def _pad(data: bytes) - bytes: PKCS#7 填充缺 n 字节就补 n 个值为 n 的字节 n 16 - len(data) % 16 return data bytes([n]) * n def _unpad(data: bytes) - bytes: n data[-1] if n 1 or n 16: raise ValueError(填充非法口令错误或密文被篡改) return data[:-n] def encrypt_file(src: str, dst: str, password: str) - None: salt, iv new_salt(), get_random_bytes(16) cipher AES.new(derive_key(password, salt), AES.MODE_CBC, iv) size os.path.getsize(src) with open(src, rb) as fin, open(dst, wb) as fout: fout.write(build_header(size, salt, iv)) while True: chunk fin.read(CHUNK) if len(chunk) CHUNK: # 尾块含空文件必须填充 fout.write(cipher.encrypt(_pad(chunk))) break fout.write(cipher.encrypt(chunk)) def decrypt_file(src: str, dst: str, password: str) - None: with open(src, rb) as fin: header fin.read(HEAD_LEN) if len(header) HEAD_LEN or header[:4] ! MAGIC: raise ValueError(不是本工具生成的加密文件) size struct.unpack(Q, header[4:12])[0] salt, iv header[12:28], header[28:44] cipher AES.new(derive_key(password, salt), AES.MODE_CBC, iv) written 0 with open(dst, wb) as fout: while True: block fin.read(CHUNK) if not block: break plain cipher.decrypt(block) if len(block) CHUNK: # 最后一块去掉 PKCS#7 填充 plain _unpad(plain) take plain[:size - written] # 按原始长度截断 fout.write(take) written len(take) if written ! size: raise ValueError(长度校验失败密文可能被截断)这段代码有三个关键点。第一加密循环用len(chunk) CHUNK判断尾块包括空文件的情况——空文件第一次读就返回b_pad(b)会补出 16 个0x10解密端能正确还原成空文件。第二如果文件大小正好是 64KB 的整数倍循环会多走一轮读到空块再补一个完整填充块这是 PKCS#7 的标准行为不是 bug。第三解密端的plain[:size - written]负责把填充字节切掉同时兜住“密文被追加垃圾数据”的情况。验证时别只用一个小文本文件。准备三个样本空文件、1 字节文件、正好 64KB 的文件再加一个 20MB 的二进制文件跑一轮“加密—解密—cmp比对”# Linux/macOS 下逐字节比对输出为空即一致 cmp tests/sample.bin tests/sample.bin.dec echo round-trip OKWindows 下没有cmp可以用certutil -hashfile 文件 SHA256分别算两个文件的摘要比对效果一样。这一步跑通对称加密模块基本就稳了。4. 非对称与摘要模块RSA 密钥对、数字签名与 SHA-256 校验对称加密解决的是“内容不被看到”非对称和摘要解决的是另外两个问题密钥怎么安全传递、文件有没有被改过。rsa_sign.py和hash_check.py加起来代码量不大但概念密度高答辩时被追问的概率也最高。很多课程设计把 RSA 写成“加密一段短字符串就完事”其实数字签名的链路更能体现对非对称体系的理解。4.1 密钥对生成与 PEM 文件落盘RSA 密钥对生成只需要一行核心调用但落盘格式和权限处理有讲究。资源包里统一导出成 PEM私钥用 PKCS#8 格式公钥单独存一个文件方便分发给验签方。from Crypto.PublicKey import RSA def gen_keypair(priv_pathprivate.pem, pub_pathpublic.pem, bits2048, passphraseNone): 生成 RSA 密钥对并写入 PEM 文件 key RSA.generate(bits) # 私钥加口令保护导出时用 PKCS#8 结构 priv_pem key.export_key( formatPEM, pkcs8, passphrasepassphrase, # None 表示不加密私钥 protectionPBKDF2WithHMAC-SHA1AndAES256-CBC, ) with open(priv_path, wb) as f: f.write(priv_pem) os.chmod(priv_path, 0o600) # 私钥只允许本人读写 with open(pub_path, wb) as f: f.write(key.publickey().export_key(formatPEM))bits2048是课程设计里比较稳妥的选择1024 位现在偏弱4096 位生成密钥会明显变慢演示时容易卡住。passphrase参数建议留空时也要在报告里说明“私钥未加密存储仅适用于本地演示”把这当作已知局限写进安全性分析比假装没这回事更专业。os.chmod在 Windows 上不起作用但加上不会报错跨平台代码里保留它没有坏处。读取密钥时用RSA.import_key()它同时接受文件路径对应的字节串和带口令的私钥key RSA.import_key(open(private.pem, rb).read(), passphrase你的口令)口令错误会抛ValueError: Incorrect padding这个异常信息很误导人看起来像填充问题实际是口令不对遇到时不要往加密模式上排查。4.2 签名链路先摘要再签顺序反了必挂数字签名的正确顺序是对原文算摘要再用私钥对摘要签名验签时用公钥解出摘要和自己重新算的摘要比对。pkcs1_15这个模块已经把摘要计算和填充打包好了调用时传进去的必须是哈希对象不能是原始数据。from Crypto.Hash import SHA256 from Crypto.Signature import pkcs1_15 def sign_file(path: str, priv_path: str, passphraseNone) - bytes: 对文件内容签名返回签名字节串 key RSA.import_key(open(priv_path, rb).read(), passphrasepassphrase) h SHA256.new() with open(path, rb) as f: for chunk in iter(lambda: f.read(8192), b): h.update(chunk) # 分块喂给哈希避免大文件占内存 return pkcs1_15.new(key).sign(h) def verify_file(path: str, signature: bytes, pub_path: str) - bool: key RSA.import_key(open(pub_path, rb).read()) h SHA256.new() with open(path, rb) as f: for chunk in iter(lambda: f.read(8192), b): h.update(chunk) try: pkcs1_15.new(key).verify(h, signature) return True except (ValueError, TypeError): return False # 验签失败统一返回 Falseiter(lambda: f.read(8192), b)这个写法值得记住它等价于一个循环读到文件尾但不需要手写while在处理大文件时比f.read()一次性读取安全得多。verify失败会抛ValueError不要用assert包住它否则在生产环境里开启-O优化会被直接跳过签名验证形同虚设。签名的典型用途是“防篡改”把签名和文件一起发给对方对方拿到后用公钥验签验不过说明文件被动过。它不提供保密性文件本身还是明文这一点在报告里要和加密区分清楚。4.3 文件完整性校验与批量测试脚本hash_check.py做的事情更简单计算文件 SHA-256输出十六进制摘要支持批量比对。它和签名的区别在于没有密钥任何人都能重新算一份摘要所以只能防意外损坏防不住故意篡改。课程设计里经常把两者混为一谈实际上摘要用于校验传输完整性签名用于确认来源。def sha256_file(path: str) - str: h SHA256.new() with open(path, rb) as f: for chunk in iter(lambda: f.read(65536), b): h.update(chunk) return h.hexdigest() def check_manifest(manifest_path: str) - int: 逐行读取 摘要 文件路径返回不一致的条数 bad 0 with open(manifest_path, encodingutf-8) as f: for line in f: digest, _, filepath line.strip().partition( ) if not filepath: continue actual sha256_file(filepath) if actual ! digest: print(f[FAIL] {filepath}\n 期望 {digest}\n 实际 {actual}) bad 1 return bad清单文件用两个空格分隔是为了兼容sha256sum生成的格式这样在 Linux 上可以直接用系统命令交叉验证不必完全信任自己写的代码。tests/run_all.sh里就是先跑一遍自己的脚本再跑一遍sha256sum -c两边结果一致才算通过。5. 避坑与排查加密 Demo 跑不通的五个现场加密代码的报错信息普遍不友好同一个异常可能对应三四种原因。下面这五条是这类课程设计资源里出现频率最高的翻车现场每条都按“现象—原因—解决”记录遇到问题时按顺序排查能省下大量时间。5.1 解密抛 ValueError: Padding is incorrect现象加密正常解密时抛ValueError: Padding is incorrect换小文件又能成功。原因九成是口令输错或者文件不是用当前口令加密的。CBC 解密出来的最后一个块是随机字节_unpad读到末字节不在 1 到 16 之间就报这个错。如果文件大小接近块边界错误口令偶尔也能“碰巧”通过填充校验但解出来的内容是乱码所以不能只看有没有报错还要比对内容。解决先把口令打印出来核对确认没有首尾空格再确认加密和解密用的是同一个KDF_ITER和dkLen参数不一致会导致派生出的密钥完全不同表现和口令错误一模一样。排查时可以在derive_key里临时打印密钥前 4 字节的十六进制两边对比确认派生环节没问题再往下查。5.2 换了口令仍能解开盐值写死的隐蔽坑现象修改了代码里的口令重新加密一个文件用旧口令居然还能解开。原因盐值被写成了常量比如salt b0123456789abcdef。盐固定后口令派生出的密钥只由口令决定旧口令对应的密钥没变自然能解开。这种情况在只测一个文件的场景下很难发现因为加密解密都用同一份代码。解决检查new_salt()是否每次调用都走get_random_bytes并确认盐被写进了文件头而不是从常量读取。验证方法是连续加密同一个文件两次比较两个密文的头部字节盐和 IV 都应该不同如果完全相同说明随机源没生效。5.3 大文件加密内存暴涨read() 不带参数现象加密一个几百 MB 的视频文件进程内存直接飙到几个 G机器开始卡顿甚至被系统杀掉。原因fin.read()不带参数会一次性把整个文件读进内存再交给cipher.encrypt()。AES 本身按块处理但 Python 层的字节串复制会额外占一份内存文件越大越明显。解决所有文件读写都带块大小参数按 64KB 循环。检查代码里有没有f.read()、f.read(-1)这种写法全局搜一遍。哈希计算同样要注意SHA256.new(f.read())也是同样的坑改成循环update。5.4 RSA 直接加密文件报 Plaintext is too long现象想用 RSA 直接加密一个几 KB 的文本文件抛ValueError: Plaintext is too long。原因RSA 能加密的数据长度受模数限制2048 位密钥配合 PKCS#1 v1.5 填充单次最多加密 245 字节。文件稍微大一点就超限这不是代码写错是算法本身的约束。解决改用混合加密。随机生成一个 32 字节的 AES 会话密钥用 RSA 公钥加密这个会话密钥文件内容用 AES 加密解密时先用 RSA 私钥解出会话密钥再解文件。hybrid_demo.py就是这条链路的最小实现。报告里要写清楚“非对称加密只用来传密钥不直接加密数据”这是得分点。5.5 Windows 下中文路径报 UnicodeDecodeError现象在 Windows 上对含中文的路径执行加解密抛UnicodeDecodeError或直接找不到文件。原因open()在部分环境下默认编码不是 UTF-8路径里的中文被按 GBK 解码后传给系统调用文件名对不上。这个问题在跨平台代码里很常见Linux 上一切正常换到 Windows 就失败。解决文本文件读写显式传encodingutf-8路径参数统一用pathlib.Path包装避免字符串拼接命令行入口用argparse接收参数时中文路径在 Windows 终端里可能被转义建议直接用引号包住路径测试。如果仍然失败检查 Python 版本3.6 以后的文件系统编码在 Windows 上默认是 UTF-8老版本需要额外设置。6. 二次开发把这套 Demo 改成能交付的文件加密工具课程设计交上去只是开始这套代码真正有价值的地方是它能当一个小工具的骨架。我拿到手后做的第一件事是把 CBC 换成 GCM原因很直接CBC 只保证机密性不保证完整性攻击者翻转密文比特能让明文产生可预测的变化而 GCM 自带认证标签解密时标签对不上直接报错省去自己拼 HMAC 的麻烦。from Crypto.Cipher import AES from Crypto.Random import get_random_bytes def encrypt_gcm(plain: bytes, key: bytes) - tuple: cipher AES.new(key, AES.MODE_GCM, nonceget_random_bytes(12)) ct, tag cipher.encrypt_and_digest(plain) # nonce、tag 都要随密文一起存缺一不可 return cipher.nonce, tag, ct def decrypt_gcm(nonce: bytes, tag: bytes, ct: bytes, key: bytes) - bytes: cipher AES.new(key, AES.MODE_GCM, noncenonce) return cipher.decrypt_and_verify(ct, tag) # 标签不对直接抛异常改造时有三处要同步动文件头要加 nonce 和 tag 字段长度从 44 字节变成 12 16 44decrypt_file里的_unpad调用要删掉GCM 是流式模式不需要填充tests/run_all.sh要加一条篡改用例把密文任意一个字节取反确认解密会失败而不是返回乱码。这三步做完才算真正换掉了加密模式而不是只在代码里改了个常量。再往下走可以做命令行参数化用argparse把encrypt、decrypt、sign、verify四个子命令挂上去入口统一成python -m crypto_tool encrypt 输入 输出交付给同学使用时不用改代码。进度显示用tqdm包一层循环即可大文件加密时体感提升明显。最后说个血泪经验。我做这类文件加密功能最开始只测正常大小的文本文件结果答辩现场用一个正好 64KB 的二进制样本演示解密出来的文件末尾多了 16 个字节当场翻车。从那以后我每次交付带加密功能的模块都强制先跑一遍空文件、1 字节文件、正好 64KB 文件这三个边界样本再谈功能。资源包里的tests/目录就是按这个习惯整理的报告和源码都在里面照着边界用例跑一轮再改能少走很多弯路。希望帮到你。本文还有配套的精品资源点击获取