简介面向高校安全技术课程设计这是一份基于Python的安全即时通讯系统完整项目。系统分为聊天客户端与集中服务器覆盖用户注册与数字证书管理、认证登录与多重登录处理、好友管理、文字图片即时通信以及聊天记录保存查看等需求同时在消息安全方面通过D-H体制协商密钥、AES算法加解密并利用MD5消息摘要校验完整性还实现了未读消息红点提醒与离线消息上线后补发。项目共53个文件其中42个Python源文件构成client、server、common等核心模块另有SQL数据库脚本、SQLite数据库文件、JSON配置、依赖清单requirements、README说明文档及产品演示gif压缩包仅759KB轻量完整易于部署运行。目前已有1200人学习下载适合作为网络安全、软件工程等相关课程设计或毕业设计的参考方案可直接运行验证也可在其基础上扩展界面与加密策略。1. 为什么说“能跑通”和“够安全”是两码事一个基于 Python 的安全即时通讯系统最难的地方从来不是聊天功能本身而是“安全”这两个字。用 socket 做一对一的文本转发几十行代码就能跑通但加上密码学、密钥管理、消息完整性校验之后项目复杂度会陡增而且越到后面越容易在细节上翻车。这个课程设计题目的真正考察点是你能不能把一个带优先级的实时消息链路用可验证的方式加固成“即使流量被截获也读不出原文、篡改后能被立刻发现”的系统。它适合正在找课程设计切入点的本科生也适合想把自己之前练过的 socket 程序升级成安全版本的初级工程师。与其堆砌一堆库不如先想清楚威胁模型本地消息缓存、网络监听、中间人篡改、服务端明文落地这四个问题能处理掉一个设计报告就比大多数只贴聊天截图的同学扎实。2. 基于 Python 的安全即时通讯系统先定威胁模型与技术选型2.1 不选 WebSocket 而选原生 socket 的课程设计理由课程设计最常见的选择路径是“Flask-SocketIO WebSocket”但这一般不是安全方向的好起点。WebSocket 天然帮你处理了握手、分帧、心跳但你看到的是一层被封装好的传输抽象底层包长什么样、什么时候该做加密、证书校验失败时抛出什么异常全都被框架吞掉了。安全类课程设计最忌讳“框架帮你把安全问题处理完了但你说不清楚处理在哪一层”。我一般直接用标准库socket ssl threading写服务端客户端用 socket 建立 TCP 连接再把明文消息经cryptography库加密后发送。这样做的好处是整条链路的每个环节都暴露在代码里TCP 建立连接、TLS 握手、应用层加密、消息排队、心跳、离线缓存全部可控。评审老师问起来你能回答“我的安全边界在哪一层”而不是说“框架做的”。2.2 安全粒度拆解传输层加密与应用层加密都要有把“安全”拆成两类一是在传输链路上用 TLS 保护信道二是在消息体上做端到端加密。这两个安全层不是二选一而是并存的。传输层解决“信道被监听”的问题只要 TLS 握手和证书校验是完整的数据在链路上就是密文应用层解决“服务端不可信”的问题消息在客户端加密后再进入 socket 流服务端即使把消息明文写进日志也读不出内容。从课程设计报告的量级来看传输层走 TLS应用层走 AES-GCM是可以完整落地且工作量可控的组合。把两套方案都写上说明你理解纵深防御而不是单点加密。2.3 依赖选型cryptography 而不是自己造轮子密码学相关代码有一条铁律不要自己实现加密算法。直接用cryptography库它是 pyca/cryptography 提供的底层封装支持 AES-GCM、RSA、X.509 证书生成接口稳定课程设计里完全够用。用标准库自带的hashlib做消息摘要hmac做消息认证ssl做 TLS 封装。安装命令如下前提是先把 Python 3.10 装好并配置了 PATHpython -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate pip install cryptography python --version参数说明这里用python -m venv创建虚拟环境而不是直接pip install是为了避免把包装进全局 Python 路径。常见问题是只装了 Python 但没勾选 “Add Python to PATH”导致python was not found这时重装解释器或者手动把安装目录配进环境变量即可。3. 用 Python 实现加密即时通讯的核心代码结构3.1 服务端骨架线程化 socket 与消息队列服务端要解决的问题有三个并发连接、消息路由、连接状态维护。用threading给每个客户端开一个线程用queue.Queue做待发送消息队列用dict存username - handler映射。消息格式定义为 JSON方便解析也方便后续加字段。import socket import threading import queue import json clients {} pending_queues {} def handle_client(conn, addr): username None try: data conn.recv(1024) if not data: conn.close() return username data.decode(utf-8) clients[username] conn pending_queues[username] queue.Queue() while True: raw conn.recv(4096) if not raw: break msg json.loads(raw.decode(utf-8)) target msg[to] if target in clients: try: clients[target].sendall(json.dumps(msg).encode(utf-8)) except Exception: pending_queues[target].put(msg) else: pending_queues.setdefault(target, queue.Queue()).put(msg) except Exception as e: print(fclient error: {e}) finally: if username and username in clients: del clients[username] conn.close() def start_server(host127.0.0.1, port8888): server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((host, port)) server.listen(5) while True: conn, addr server.accept() threading.Thread(targethandle_client, args(conn, addr), daemonTrue).start()代码逻辑说明handle_client先把第一条消息当作用户名注册之后每次recv都尝试解析成 JSONto字段是目标用户在线直接转发离线先放队列。listen(5)表示最多 5 个未处理的连接请求排队这个数字不需要调太大课程设计场景不需要支持高并发。这里刻意没有做任何加密是先把消息链路打通。要记住一个原则先让明文链路稳定运行再逐步加安全层否则排错时你会分不清是网络问题还是加解密问题。3.2 客户端骨架收发线程分离与粘包处理客户端要支持“边收边发”所以收发必须分线程同时 TCP 是流协议recv可能一次读到半条 JSON 或者粘连多条消息这就是经典的粘包问题。解决办法是自定义一个简单的长度前缀协议每条消息前面加 4 字节的大端整数长度。import socket import json import struct import threading def recv_exact(conn, n): buf b while len(buf) n: chunk conn.recv(n - len(buf)) if not chunk: raise ConnectionError(connection closed) buf chunk return buf def recv_message(conn): header recv_exact(conn, 4) length struct.unpack(!I, header)[0] if length 1024 * 1024: raise ValueError(message too long, refuse) body recv_exact(conn, length) return body.decode(utf-8) def send_message(conn, msg_dict): body json.dumps(msg_dict).encode(utf-8) header struct.pack(!I, len(body)) conn.sendall(header body)参数说明!I表示网络字节序的 4 字节无符号整数recv_exact保证读满指定字节数防止半包length 1024 * 1024是防御性检查防止恶意对端声称要发 10 GB 数据把内存耗尽。课程设计里不写这条检查代码也能跑但写了它报告里的“安全”就不再只是一句口号。3.3 加入 TLS证书生成与 ssl.SSLContext 配置链路加密用 ssl 模块需要先生成自签名证书openssl req -x509 -newkey rsa:2048 -nodes \ -keyout server.key -out server.crt -days 365 \ -subj /CNlocalhost服务端用ssl.SSLContext包装 socketimport ssl def start_tls_server(host127.0.0.1, port8888, certfileserver.crt, keyfileserver.key): ctx ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER) ctx.load_cert_chain(certfilecertfile, keyfilekeyfile) raw_server socket.socket(socket.AF_INET, socket.SOCK_STREAM) raw_server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) raw_server.bind((host, port)) raw_server.listen(5) while True: raw_conn, addr raw_server.accept() try: conn ctx.wrap_socket(raw_conn, server_sideTrue) threading.Thread(targethandle_client, args(conn, addr), daemonTrue).start() except ssl.SSLError as e: print(fTLS handshake failed: {e})客户端连接时建议开启证书校验而不是传ssl._create_unverified_context()。课程设计中如果用 IP 而不是域名访问需要给证书加上subjectAltNameIP:127.0.0.1否则校验会失败。ctx ssl.create_default_context() ctx.check_hostname False ctx.verify_mode ssl.CERT_NONE conn socket.create_connection((127.0.0.1, 8888)) tls_conn ctx.wrap_socket(conn, server_hostnamelocalhost)这里的server_hostname必须填证书里 CN 对应的值证书是CNlocalhost就连填 localhost。客户端如果不想在校验上花时间课程设计里允许先关闭校验但报告中必须把“生产环境中应改为 CERT_REQUIRED”写清楚。4. 消息端到端加密AES-GCM 与 RSA 密钥交换配置4.1 用 AES-GCM 加密消息体而不是 AES-CBCAES-CBC 需要自己处理填充、IV 随机性和完整性校验链路中任何一环节漏掉密文就可能被篡改且无法被发现。AES-GCM 同时提供机密性和完整性加密后输出ciphertext tag解密时先校验 tag 再返回明文加解密代码短且不容易出错。import os from cryptography.hazmat.primitives.ciphers.aead import AESGCM def encrypt_message(key: bytes, plaintext: str) - tuple[bytes, bytes, bytes]: nonce os.urandom(12) aesgcm AESGCM(key) ciphertext aesgcm.encrypt(nonce, plaintext.encode(utf-8), None) return nonce, ciphertext[:-16], ciphertext[-16:]参数说明nonce 长度固定为 12 字节是 GCM 的标准推荐值不要用 os.urandom 生成 16 字节ciphertext最后 16 字节是认证 tag需要跟随消息一起发送解密时把nonce ciphertext tag拼回去再调decrypt。这段代码最关键的一点是每次加密都必须生成新的 nonce同一个 key 下重复使用 nonce 会让 GCM 安全性雪崩。4.2 RSA-OAEP 做密钥分配不要把 AES 密钥写死在源码双方要共享同一个 AES 密钥但密钥不能硬编码。常见做法是服务器生成 RSA 2048 密钥对客户端登录时把公钥传给客户端客户端生成 AES 密钥后用 RSA 公钥加密再把密文发给服务器服务器用私钥解密得到 AES 密钥之后所有消息都走 AES-GCM。from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import padding from cryptography.hazmat.primitives.asymmetric import rsa private_key rsa.generate_private_key(public_exponent65537, key_size2048) public_key private_key.public_key() def wrap_aes_key(public_key, aes_key: bytes) - bytes: return public_key.encrypt( aes_key, padding.OAEP(mgfpadding.MGF1(algorithmhashes.SHA256()), algorithmhashes.SHA256(), labelNone) ) def unwrap_aes_key(private_key, wrapped: bytes) - bytes: return private_key.decrypt( wrapped, padding.OAEP(mgfpadding.MGF1(algorithmhashes.SHA256()), algorithmhashes.SHA256(), labelNone) )参数说明public_exponent65537是常用安全值课程设计不需要改动key_size2048在测试环境足够但代码注释里建议指出生产环境用 3072 更稳妥。OAEP 必须显式指定 hash 算法否则不同版本cryptography库的默认值可能不一致换环境后导致加解密失败。4.3 消息结构设计把加密与元数据分离完整消息格式建议用 JSON 包裹外层是路由与身份信息内层是加密后的密文密文结构放到payload里。{ type: chat, from: alice, to: bob, timestamp: 1710000000, payload: { nonce: base64, ciphertext: base64, tag: base64 } }设计说明to字段用于路由转发是明文这没有问题真正要隐藏的是消息正文它只存在于payload里。注意不要出现把from和to也加密的做法那会让服务端无法路由课程设计里不必要。timestamp用于防重放攻击的初阶设计接收方可以拒绝 5 分钟前的旧消息这个点写进报告很加分。5. 密聊系统的完整协议时序与密钥生命周期参数5.1 登录握手阶段的密钥协商流程图时序上的顺序决定安全隐患。我建议的完整握手流程是客户端发起 TCP 连接并完成 TLS 握手。客户端发送HELLO消息服务端返回自己的 RSA 公钥Base64 编码。客户端校验公钥是否与之前保存的“指纹”一致首次连接时提示用户确认。客户端生成随机 AES-256 密钥用 RSA-OAEP 加密后发送。服务端解密得到 AES 密钥回复SESSION_OK。双方后续消息全部使用该 AES-GCM 密钥加密。Client Server |--- TLS handshake -------------------| |--- RSA public key (base64) ---------| |--- wrap(aes_key) -------------------| |--- SESSION_OK ----------------------| | AES-GCM encrypted messages |流程中存在两个常见的坑。第一个坑是客户端没有保存公钥指纹导致每次连接都接受新公钥中间人攻击可以借此替换公钥第二个坑是 AES 密钥一次性生成后无轮换机制长连接跑几个小时也不重新协商一旦密钥被侧信道攻击获取所有历史消息全部泄露。课程设计里至少要做第一个第二个可以作为报告中的“改进方向”。5.2 心跳、超时与下线互踢的参数配置网络异常会导致连接半开即一方还认为连接正常另一方早已断链。解决办法是心跳机制客户端每 30 秒发送一次心跳明文包服务端如果 90 秒内没收到任何包就断开该连接。import time LAST_SEEN {} def heartbeat_checker(timeout90): while True: now time.time() stale [u for u, t in LAST_SEEN.items() if now - t timeout] for u in stale: if u in clients: clients[u].close() del clients[u] time.sleep(10)参数说明心跳间隔 30 秒、超时阈值 90 秒是比较保守的组合适合校园网环境如果网络质量差可以放宽到 60/180。time.sleep(10)是扫描周期设太短浪费 CPU设太长则清理不及时。这份参数表建议写进设计报告参数值说明心跳间隔30s客户端定时发送超时阈值90s超过即判定离线最大消息长度1MB防恶意超大报文消息重发次数3离线队列投递上限5.3 离线消息存储加密后再落盘课程设计的加分项是离线消息。当目标用户不在线时消息不能丢。实现路径是把加密后的消息不是明文写入 SQLite等用户上线后再推送并删除。import sqlite3 DB_PATH offline_messages.db def store_offline(username: str, encrypted_payload: bytes): conn sqlite3.connect(DB_PATH) conn.execute( INSERT INTO offline (user, ciphertext, created_at) VALUES (?, ?, datetime(now)), (username, encrypted_payload), ) conn.commit() conn.close()这里的要点是加密操作必须在客户端完成服务端拿到的已经是密文所以离线表里不存在明文泄露风险。这个代码会同时触及课程设计评分表里的“数据持久化”“安全存储”两个点性价比极高。6. Python 环境配置、常见报错修复与安全验证技巧6.1 从安装 Python 到跑通加解密的完整环境清单课程设计开始前先把环境装干净。Windows 上安装 Python 后经常出现python was not found; run without arguments to install from the Microsoft Store这种报错说明 PATH 里没有python.exe路径。解决方法是打开“设置 - 系统 - 关于 - 高级系统设置 - 环境变量”把C:\Users\你的用户名\AppData\Local\Programs\Python\Python311\加进 Path。VSCode 里做 Python 开发建议先建虚拟环境再让解释器指向虚拟环境。命令行里依次执行conda create -n securechat python3.11 -y conda activate securechat pip install cryptography如果不想用 condaWindows 下面的等效做法是py -m venv .venv .venv\Scripts\activate pip install -r requirements.txt环境问题最常见的有三个ModuleNotFoundError: cryptography表示包没装进当前环境通常是激活了错误的虚拟环境ImportError: DLL load failed表示 Python 版本与 cryptography 预编译轮子不兼容建议换 64 位 Python 3.10pip 安装慢则可以在 pypi 镜像源里配置-i https://pypi.tuna.tsinghua.edu.cn/simple课程设计期间临时用一次没有问题。6.2 加解密接口的快速验证脚本不要等到聊天界面做完再验证安全逻辑。写一个独立测试脚本专门验证 AES-GCM 加解密、RSA 包装与解包、消息长度校验三个功能import unittest from aes_gcm import encrypt_message, decrypt_message from rsa_wrap import wrap_aes_key, unwrap_aes_key from cryptography.hazmat.primitives.asymmetric import rsa class SecurityTest(unittest.TestCase): def test_aes_roundtrip(self): key b0 * 32 nonce, ciphertext, tag encrypt_message(key, hello) plain decrypt_message(key, nonce, ciphertext, tag) self.assertEqual(plain, hello) def test_aes_wrong_key_fails(self): key b0 * 32 wrong_key b1 * 32 nonce, ciphertext, tag encrypt_message(key, hello) with self.assertRaises(Exception): decrypt_message(wrong_key, nonce, ciphertext, tag) def test_rsa_wrap_unwrap(self): pri rsa.generate_private_key(public_exponent65537, key_size2048) aes_key b0 * 32 wrapped wrap_aes_key(pri.public_key(), aes_key) self.assertEqual(unwrap_aes_key(pri, wrapped), aes_key) if __name__ __main__: unittest.main()业务跑通后做一次“明文在链路上不可见”的验证。在服务器代码里临时打印conn.recv()收到的内容如果看到的是乱码而不是 JSON 明文说明应用层加密生效。常用的命令是tcpdump -i lo port 8888 -A-A参数会以 ASCII 格式打印包内容如果输出里找不到消息原文链路加密就验证到位了。这一步是最直观、也最能在答辩时讲清楚的安全证据。6.3 答辩评审视角的验收关注点本文还有配套的精品资源点击获取 Python安全即时通讯系统设计：从Socket到AES-GCM加密实战
简介面向高校安全技术课程设计这是一份基于Python的安全即时通讯系统完整项目。系统分为聊天客户端与集中服务器覆盖用户注册与数字证书管理、认证登录与多重登录处理、好友管理、文字图片即时通信以及聊天记录保存查看等需求同时在消息安全方面通过D-H体制协商密钥、AES算法加解密并利用MD5消息摘要校验完整性还实现了未读消息红点提醒与离线消息上线后补发。项目共53个文件其中42个Python源文件构成client、server、common等核心模块另有SQL数据库脚本、SQLite数据库文件、JSON配置、依赖清单requirements、README说明文档及产品演示gif压缩包仅759KB轻量完整易于部署运行。目前已有1200人学习下载适合作为网络安全、软件工程等相关课程设计或毕业设计的参考方案可直接运行验证也可在其基础上扩展界面与加密策略。1. 为什么说“能跑通”和“够安全”是两码事一个基于 Python 的安全即时通讯系统最难的地方从来不是聊天功能本身而是“安全”这两个字。用 socket 做一对一的文本转发几十行代码就能跑通但加上密码学、密钥管理、消息完整性校验之后项目复杂度会陡增而且越到后面越容易在细节上翻车。这个课程设计题目的真正考察点是你能不能把一个带优先级的实时消息链路用可验证的方式加固成“即使流量被截获也读不出原文、篡改后能被立刻发现”的系统。它适合正在找课程设计切入点的本科生也适合想把自己之前练过的 socket 程序升级成安全版本的初级工程师。与其堆砌一堆库不如先想清楚威胁模型本地消息缓存、网络监听、中间人篡改、服务端明文落地这四个问题能处理掉一个设计报告就比大多数只贴聊天截图的同学扎实。2. 基于 Python 的安全即时通讯系统先定威胁模型与技术选型2.1 不选 WebSocket 而选原生 socket 的课程设计理由课程设计最常见的选择路径是“Flask-SocketIO WebSocket”但这一般不是安全方向的好起点。WebSocket 天然帮你处理了握手、分帧、心跳但你看到的是一层被封装好的传输抽象底层包长什么样、什么时候该做加密、证书校验失败时抛出什么异常全都被框架吞掉了。安全类课程设计最忌讳“框架帮你把安全问题处理完了但你说不清楚处理在哪一层”。我一般直接用标准库socket ssl threading写服务端客户端用 socket 建立 TCP 连接再把明文消息经cryptography库加密后发送。这样做的好处是整条链路的每个环节都暴露在代码里TCP 建立连接、TLS 握手、应用层加密、消息排队、心跳、离线缓存全部可控。评审老师问起来你能回答“我的安全边界在哪一层”而不是说“框架做的”。2.2 安全粒度拆解传输层加密与应用层加密都要有把“安全”拆成两类一是在传输链路上用 TLS 保护信道二是在消息体上做端到端加密。这两个安全层不是二选一而是并存的。传输层解决“信道被监听”的问题只要 TLS 握手和证书校验是完整的数据在链路上就是密文应用层解决“服务端不可信”的问题消息在客户端加密后再进入 socket 流服务端即使把消息明文写进日志也读不出内容。从课程设计报告的量级来看传输层走 TLS应用层走 AES-GCM是可以完整落地且工作量可控的组合。把两套方案都写上说明你理解纵深防御而不是单点加密。2.3 依赖选型cryptography 而不是自己造轮子密码学相关代码有一条铁律不要自己实现加密算法。直接用cryptography库它是 pyca/cryptography 提供的底层封装支持 AES-GCM、RSA、X.509 证书生成接口稳定课程设计里完全够用。用标准库自带的hashlib做消息摘要hmac做消息认证ssl做 TLS 封装。安装命令如下前提是先把 Python 3.10 装好并配置了 PATHpython -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate pip install cryptography python --version参数说明这里用python -m venv创建虚拟环境而不是直接pip install是为了避免把包装进全局 Python 路径。常见问题是只装了 Python 但没勾选 “Add Python to PATH”导致python was not found这时重装解释器或者手动把安装目录配进环境变量即可。3. 用 Python 实现加密即时通讯的核心代码结构3.1 服务端骨架线程化 socket 与消息队列服务端要解决的问题有三个并发连接、消息路由、连接状态维护。用threading给每个客户端开一个线程用queue.Queue做待发送消息队列用dict存username - handler映射。消息格式定义为 JSON方便解析也方便后续加字段。import socket import threading import queue import json clients {} pending_queues {} def handle_client(conn, addr): username None try: data conn.recv(1024) if not data: conn.close() return username data.decode(utf-8) clients[username] conn pending_queues[username] queue.Queue() while True: raw conn.recv(4096) if not raw: break msg json.loads(raw.decode(utf-8)) target msg[to] if target in clients: try: clients[target].sendall(json.dumps(msg).encode(utf-8)) except Exception: pending_queues[target].put(msg) else: pending_queues.setdefault(target, queue.Queue()).put(msg) except Exception as e: print(fclient error: {e}) finally: if username and username in clients: del clients[username] conn.close() def start_server(host127.0.0.1, port8888): server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((host, port)) server.listen(5) while True: conn, addr server.accept() threading.Thread(targethandle_client, args(conn, addr), daemonTrue).start()代码逻辑说明handle_client先把第一条消息当作用户名注册之后每次recv都尝试解析成 JSONto字段是目标用户在线直接转发离线先放队列。listen(5)表示最多 5 个未处理的连接请求排队这个数字不需要调太大课程设计场景不需要支持高并发。这里刻意没有做任何加密是先把消息链路打通。要记住一个原则先让明文链路稳定运行再逐步加安全层否则排错时你会分不清是网络问题还是加解密问题。3.2 客户端骨架收发线程分离与粘包处理客户端要支持“边收边发”所以收发必须分线程同时 TCP 是流协议recv可能一次读到半条 JSON 或者粘连多条消息这就是经典的粘包问题。解决办法是自定义一个简单的长度前缀协议每条消息前面加 4 字节的大端整数长度。import socket import json import struct import threading def recv_exact(conn, n): buf b while len(buf) n: chunk conn.recv(n - len(buf)) if not chunk: raise ConnectionError(connection closed) buf chunk return buf def recv_message(conn): header recv_exact(conn, 4) length struct.unpack(!I, header)[0] if length 1024 * 1024: raise ValueError(message too long, refuse) body recv_exact(conn, length) return body.decode(utf-8) def send_message(conn, msg_dict): body json.dumps(msg_dict).encode(utf-8) header struct.pack(!I, len(body)) conn.sendall(header body)参数说明!I表示网络字节序的 4 字节无符号整数recv_exact保证读满指定字节数防止半包length 1024 * 1024是防御性检查防止恶意对端声称要发 10 GB 数据把内存耗尽。课程设计里不写这条检查代码也能跑但写了它报告里的“安全”就不再只是一句口号。3.3 加入 TLS证书生成与 ssl.SSLContext 配置链路加密用 ssl 模块需要先生成自签名证书openssl req -x509 -newkey rsa:2048 -nodes \ -keyout server.key -out server.crt -days 365 \ -subj /CNlocalhost服务端用ssl.SSLContext包装 socketimport ssl def start_tls_server(host127.0.0.1, port8888, certfileserver.crt, keyfileserver.key): ctx ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER) ctx.load_cert_chain(certfilecertfile, keyfilekeyfile) raw_server socket.socket(socket.AF_INET, socket.SOCK_STREAM) raw_server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) raw_server.bind((host, port)) raw_server.listen(5) while True: raw_conn, addr raw_server.accept() try: conn ctx.wrap_socket(raw_conn, server_sideTrue) threading.Thread(targethandle_client, args(conn, addr), daemonTrue).start() except ssl.SSLError as e: print(fTLS handshake failed: {e})客户端连接时建议开启证书校验而不是传ssl._create_unverified_context()。课程设计中如果用 IP 而不是域名访问需要给证书加上subjectAltNameIP:127.0.0.1否则校验会失败。ctx ssl.create_default_context() ctx.check_hostname False ctx.verify_mode ssl.CERT_NONE conn socket.create_connection((127.0.0.1, 8888)) tls_conn ctx.wrap_socket(conn, server_hostnamelocalhost)这里的server_hostname必须填证书里 CN 对应的值证书是CNlocalhost就连填 localhost。客户端如果不想在校验上花时间课程设计里允许先关闭校验但报告中必须把“生产环境中应改为 CERT_REQUIRED”写清楚。4. 消息端到端加密AES-GCM 与 RSA 密钥交换配置4.1 用 AES-GCM 加密消息体而不是 AES-CBCAES-CBC 需要自己处理填充、IV 随机性和完整性校验链路中任何一环节漏掉密文就可能被篡改且无法被发现。AES-GCM 同时提供机密性和完整性加密后输出ciphertext tag解密时先校验 tag 再返回明文加解密代码短且不容易出错。import os from cryptography.hazmat.primitives.ciphers.aead import AESGCM def encrypt_message(key: bytes, plaintext: str) - tuple[bytes, bytes, bytes]: nonce os.urandom(12) aesgcm AESGCM(key) ciphertext aesgcm.encrypt(nonce, plaintext.encode(utf-8), None) return nonce, ciphertext[:-16], ciphertext[-16:]参数说明nonce 长度固定为 12 字节是 GCM 的标准推荐值不要用 os.urandom 生成 16 字节ciphertext最后 16 字节是认证 tag需要跟随消息一起发送解密时把nonce ciphertext tag拼回去再调decrypt。这段代码最关键的一点是每次加密都必须生成新的 nonce同一个 key 下重复使用 nonce 会让 GCM 安全性雪崩。4.2 RSA-OAEP 做密钥分配不要把 AES 密钥写死在源码双方要共享同一个 AES 密钥但密钥不能硬编码。常见做法是服务器生成 RSA 2048 密钥对客户端登录时把公钥传给客户端客户端生成 AES 密钥后用 RSA 公钥加密再把密文发给服务器服务器用私钥解密得到 AES 密钥之后所有消息都走 AES-GCM。from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import padding from cryptography.hazmat.primitives.asymmetric import rsa private_key rsa.generate_private_key(public_exponent65537, key_size2048) public_key private_key.public_key() def wrap_aes_key(public_key, aes_key: bytes) - bytes: return public_key.encrypt( aes_key, padding.OAEP(mgfpadding.MGF1(algorithmhashes.SHA256()), algorithmhashes.SHA256(), labelNone) ) def unwrap_aes_key(private_key, wrapped: bytes) - bytes: return private_key.decrypt( wrapped, padding.OAEP(mgfpadding.MGF1(algorithmhashes.SHA256()), algorithmhashes.SHA256(), labelNone) )参数说明public_exponent65537是常用安全值课程设计不需要改动key_size2048在测试环境足够但代码注释里建议指出生产环境用 3072 更稳妥。OAEP 必须显式指定 hash 算法否则不同版本cryptography库的默认值可能不一致换环境后导致加解密失败。4.3 消息结构设计把加密与元数据分离完整消息格式建议用 JSON 包裹外层是路由与身份信息内层是加密后的密文密文结构放到payload里。{ type: chat, from: alice, to: bob, timestamp: 1710000000, payload: { nonce: base64, ciphertext: base64, tag: base64 } }设计说明to字段用于路由转发是明文这没有问题真正要隐藏的是消息正文它只存在于payload里。注意不要出现把from和to也加密的做法那会让服务端无法路由课程设计里不必要。timestamp用于防重放攻击的初阶设计接收方可以拒绝 5 分钟前的旧消息这个点写进报告很加分。5. 密聊系统的完整协议时序与密钥生命周期参数5.1 登录握手阶段的密钥协商流程图时序上的顺序决定安全隐患。我建议的完整握手流程是客户端发起 TCP 连接并完成 TLS 握手。客户端发送HELLO消息服务端返回自己的 RSA 公钥Base64 编码。客户端校验公钥是否与之前保存的“指纹”一致首次连接时提示用户确认。客户端生成随机 AES-256 密钥用 RSA-OAEP 加密后发送。服务端解密得到 AES 密钥回复SESSION_OK。双方后续消息全部使用该 AES-GCM 密钥加密。Client Server |--- TLS handshake -------------------| |--- RSA public key (base64) ---------| |--- wrap(aes_key) -------------------| |--- SESSION_OK ----------------------| | AES-GCM encrypted messages |流程中存在两个常见的坑。第一个坑是客户端没有保存公钥指纹导致每次连接都接受新公钥中间人攻击可以借此替换公钥第二个坑是 AES 密钥一次性生成后无轮换机制长连接跑几个小时也不重新协商一旦密钥被侧信道攻击获取所有历史消息全部泄露。课程设计里至少要做第一个第二个可以作为报告中的“改进方向”。5.2 心跳、超时与下线互踢的参数配置网络异常会导致连接半开即一方还认为连接正常另一方早已断链。解决办法是心跳机制客户端每 30 秒发送一次心跳明文包服务端如果 90 秒内没收到任何包就断开该连接。import time LAST_SEEN {} def heartbeat_checker(timeout90): while True: now time.time() stale [u for u, t in LAST_SEEN.items() if now - t timeout] for u in stale: if u in clients: clients[u].close() del clients[u] time.sleep(10)参数说明心跳间隔 30 秒、超时阈值 90 秒是比较保守的组合适合校园网环境如果网络质量差可以放宽到 60/180。time.sleep(10)是扫描周期设太短浪费 CPU设太长则清理不及时。这份参数表建议写进设计报告参数值说明心跳间隔30s客户端定时发送超时阈值90s超过即判定离线最大消息长度1MB防恶意超大报文消息重发次数3离线队列投递上限5.3 离线消息存储加密后再落盘课程设计的加分项是离线消息。当目标用户不在线时消息不能丢。实现路径是把加密后的消息不是明文写入 SQLite等用户上线后再推送并删除。import sqlite3 DB_PATH offline_messages.db def store_offline(username: str, encrypted_payload: bytes): conn sqlite3.connect(DB_PATH) conn.execute( INSERT INTO offline (user, ciphertext, created_at) VALUES (?, ?, datetime(now)), (username, encrypted_payload), ) conn.commit() conn.close()这里的要点是加密操作必须在客户端完成服务端拿到的已经是密文所以离线表里不存在明文泄露风险。这个代码会同时触及课程设计评分表里的“数据持久化”“安全存储”两个点性价比极高。6. Python 环境配置、常见报错修复与安全验证技巧6.1 从安装 Python 到跑通加解密的完整环境清单课程设计开始前先把环境装干净。Windows 上安装 Python 后经常出现python was not found; run without arguments to install from the Microsoft Store这种报错说明 PATH 里没有python.exe路径。解决方法是打开“设置 - 系统 - 关于 - 高级系统设置 - 环境变量”把C:\Users\你的用户名\AppData\Local\Programs\Python\Python311\加进 Path。VSCode 里做 Python 开发建议先建虚拟环境再让解释器指向虚拟环境。命令行里依次执行conda create -n securechat python3.11 -y conda activate securechat pip install cryptography如果不想用 condaWindows 下面的等效做法是py -m venv .venv .venv\Scripts\activate pip install -r requirements.txt环境问题最常见的有三个ModuleNotFoundError: cryptography表示包没装进当前环境通常是激活了错误的虚拟环境ImportError: DLL load failed表示 Python 版本与 cryptography 预编译轮子不兼容建议换 64 位 Python 3.10pip 安装慢则可以在 pypi 镜像源里配置-i https://pypi.tuna.tsinghua.edu.cn/simple课程设计期间临时用一次没有问题。6.2 加解密接口的快速验证脚本不要等到聊天界面做完再验证安全逻辑。写一个独立测试脚本专门验证 AES-GCM 加解密、RSA 包装与解包、消息长度校验三个功能import unittest from aes_gcm import encrypt_message, decrypt_message from rsa_wrap import wrap_aes_key, unwrap_aes_key from cryptography.hazmat.primitives.asymmetric import rsa class SecurityTest(unittest.TestCase): def test_aes_roundtrip(self): key b0 * 32 nonce, ciphertext, tag encrypt_message(key, hello) plain decrypt_message(key, nonce, ciphertext, tag) self.assertEqual(plain, hello) def test_aes_wrong_key_fails(self): key b0 * 32 wrong_key b1 * 32 nonce, ciphertext, tag encrypt_message(key, hello) with self.assertRaises(Exception): decrypt_message(wrong_key, nonce, ciphertext, tag) def test_rsa_wrap_unwrap(self): pri rsa.generate_private_key(public_exponent65537, key_size2048) aes_key b0 * 32 wrapped wrap_aes_key(pri.public_key(), aes_key) self.assertEqual(unwrap_aes_key(pri, wrapped), aes_key) if __name__ __main__: unittest.main()业务跑通后做一次“明文在链路上不可见”的验证。在服务器代码里临时打印conn.recv()收到的内容如果看到的是乱码而不是 JSON 明文说明应用层加密生效。常用的命令是tcpdump -i lo port 8888 -A-A参数会以 ASCII 格式打印包内容如果输出里找不到消息原文链路加密就验证到位了。这一步是最直观、也最能在答辩时讲清楚的安全证据。6.3 答辩评审视角的验收关注点本文还有配套的精品资源点击获取