简介一份面向计算机毕业设计的完整源码包聚焦Python加密技术与农产品溯源仿真系统的结合适合需要完成类似课题、或想深入理解加密算法与信息管理系统开发流程的学生。压缩包共2000个文件主体为1706个Python源码另有124个HTML页面、87个JS脚本、47个TXT说明、15个CSS样式及少量Markdown、JSON、XML文档整体约77.3MB目录中涵盖需求分析、设计文档、源码模块、测试用例、数据库脚本与运行指南。已有207人学习可参考其AES/RSA等加密模块设计、数据存储与溯源逻辑以及从系统架构到界面实现的全过程有助于快速搭建毕业设计框架并理解从需求到落地的完整思路。1. 溯源系统最该防的不是泄密而是“改数据”农产品溯源系统做出来容易真正难的是让链条上所有人相信数据没被改过。本文讨论一种典型做法用 Python 的加密技术构建一个仿真系统模拟农产品从种植、加工、运输到销售的全链路记录并对每个环节的数据做完整性保护和身份签名。这不是传统意义上的“信息保密”而是把“某个数据是谁在什么时间写进去的、之后有没有被动过”这两件事固定下来。仿真系统的价值在于不用对接真实硬件和供应链就能把加密算法、数据模型、防篡改校验完整跑通适合毕业设计演示也适合作为企业数字化追溯系统的教学原型。读者不需要有密码学背景但需要有 Python 基础至少写过脚本、装过第三方库。阅读本文需要半小时能跑通的代码总量大约 300 行最终交付物是一个带命令行接口的本地仿真程序和一套可验证的数据完整性机制。2. 先设计溯源链路再决定加密算法用在哪个位置2.1 农产品溯源的环数据天然是一条链农产品溯源和普通订单系统的差别在于一条农产品从田间到餐桌至少要经过三到五个独立环节每个环节的数据由不同的人录入而且消费者要能回查任意一个环节。如果采用集中式数据库存储管理员有权限修改历史记录消费者拿到的溯源码就无法证明数据可信。因此溯源系统的数据模型必须满足两个约束第一按环节拆分存储第二每个环节的记录要和前一个环节产生关联。最常见的做法就是哈希链把每个环节的关键数据打包取 SHA-256 摘要把前一个环节的摘要拼进当前环节再取摘要。这样修改任意一个环节会让从该环节往后的所有摘要全部失效。2.2 用 Python 定义溯源区块的数据结构这里说的“区块”完全可以用 Python 的普通类实现不需要引入任何区块链框架。每个区块保存六类字段批次号、环节序号、环节名称、记录人、业务数据、时间戳再加上两个摘要字段。上一环节摘要用来串链当前环节摘要是把所有业务字段加时间戳拼成一个字符串后计算的指纹。import hashlib import json from datetime import datetime class TraceBlock: def __init__(self, batch_id, seq, stage, operator, payload, prev_hash): self.batch_id batch_id self.seq seq self.stage stage self.operator operator self.payload payload self.timestamp datetime.now().isoformat(timespecseconds) self.prev_hash prev_hash self.hash self.calc_hash() def calc_hash(self): raw { batch_id: self.batch_id, seq: self.seq, stage: self.stage, operator: self.operator, payload: self.payload, timestamp: self.timestamp, prev_hash: self.prev_hash, } text json.dumps(raw, ensure_asciiFalse, sort_keysTrue).encode(utf-8) return hashlib.sha256(text).hexdigest() def to_dict(self): return { batch_id: self.batch_id, seq: self.seq, stage: self.stage, operator: self.operator, payload: self.payload, timestamp: self.timestamp, prev_hash: self.prev_hash, hash: self.hash, }核心逻辑在calc_hash方法里。使用json.dumps时强制指定sort_keysTrue目的是保证字典键的序列化顺序固定否则相同内容的字典在不同版本 Python 里可能输出不同字符串导致摘要不稳定。ensure_asciiFalse是为了让中文以原文参与哈希计算保证不同设备上编码一致。seq字段必须单独存在因为同一批次号下会有多个环节序号是链的物理顺序。哈希链的核心属性在这里已经具备任意一个区块修改了payload、operator或timestamp其hash必然变化而它的下一个区块记录的prev_hash仍然是指向修改前的旧值因此校验会失败。这就是溯源数据防篡改的第一层保障。3. 加密技术选型哈希、MAC、RSA 与 AES 各自解决一个问题3.1 哈希只能防无意修改防不了恶意篡改纯哈希链有一个致命弱点如果攻击者同时篡改了某一路段数据和它后面的所有区块那么整条链依然自洽。仿真系统里需要模拟这种攻击并展示如何用加密技术封死这个洞。防篡改的本质不是让数据无法被改而是让数据一旦被改校验方能够识别。要做到这一点仅靠单向哈希不够需要引入密钥或签名机制。下面这张表是五类常见加密技术在溯源系统里的分工。技术作用密钥要求在溯源系统里的用途SHA-256数据完整性校验无密钥计算环节摘要、串链HMAC-SHA256带密钥的完整性校验共享对称密钥防止无权限方篡改数据RSA 数字签名身份认证、防抵赖公私钥对环节记录人对自己的记录签名AES-GCM敏感数据加密存储对称密钥对质检报告、农残检测单加密存储椭圆曲线签名 ECDSA身份认证公私钥对算法更轻适合二维码场景仿真系统至少需要实现前四类。哈希解决“数据被改了能发现”MAC 解决“没钥匙的人不能偷偷改完再重新算摘要”RSA 签名解决“某个环节的记录人不能否认自己提交过数据”AES 解决“质检报告这类敏感信息在数据库泄露时仍然不可读”。3.2 使用 hashlib 和 hmac 实现防篡改标记在TraceBlock基础上加入 MAC 计算。注意 MAC 使用的是共享密钥密钥必须与数据分开存储仿真系统里可以用环境变量或单独配置文件存放不能硬编码在源码里。import hmac import hashlib def calc_block_mac(block_dict: dict, secret_key: bytes) - str: block_dict dict(block_dict) block_dict.pop(mac, None) text json.dumps(block_dict, ensure_asciiFalse, sort_keysTrue).encode(utf-8) return hmac.new(secret_key, text, hashlib.sha256).hexdigest()这段代码和calc_hash的区别在于引入了secret_key。计算方和校验方持有同一个密钥攻击者即使拿到完整数据库也无法在不掌握密钥的情况下重新计算合法的 MAC。实际项目中密钥由溯源平台统一管理各环节操作人员不接触密钥只能提交原始数据。3.3 用 cryptography 库做 RSA 签名和验签每个环记录人需要一对 RSA 密钥。私钥用于签名公钥随区块一起公布。校验方使用公钥验证签名就能确认这条记录确实由对应负责人提交。这是防抵赖机制防止“数据是我写的但我不承认”的纠纷。from cryptography.hazmat.primitives.asymmetric import rsa, padding from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives import serialization def generate_operator_keypair(): private_key rsa.generate_private_key( public_exponent65537, key_size2048, ) private_pem private_key.private_bytes( encodingserialization.Encoding.PEM, formatserialization.PrivateFormat.PKCS8, encryption_algorithmserialization.NoEncryption(), ) public_pem private_key.public_key().public_bytes( encodingserialization.Encoding.PEM, formatserialization.PublicFormat.SubjectPublicKeyInfo, ) return private_pem, public_pem def sign_block(block: TraceBlock, private_key) - str: private_key.verify None text block.hash.encode(utf-8) signature private_key.sign( text, padding.PKCS1v15(), hashes.SHA256(), ) return signature.hex()签名的对象是区块的哈希值而不是原始数据。这样做的原因是原始数据可能很长RSA 直接对大数据签名需要先做哈希否则一次签名的数据量受密钥长度限制。签名内容放到区块的sign字段中。验签时把签名、公钥和区块的hash字段传入校验函数失败则说明该区块不是对应负责人签发的。padding.PKCS1v15()是 RSA 签名常用的填充方案。新项目也可以选择 PSS 填充安全性更好仿真系统里两种都可以。密钥长度选 2048 位1024 位已被认为不够安全4096 位在仿真系统里没有必要性能开销大。3.4 AES-GCM 加密质检报告和敏感字段农产品溯源里最常见的敏感数据是农残检测报告、供应商个人信息和价格信息。仿真系统可以用 AES-GCM 对这类字段加密后再存储查询时需要解密才能看到明文。选 GCM 模式是因为它同时提供机密性和完整性校验密文被改动后解密会自动失败。import os from cryptography.hazmat.primitives.ciphers.aead import AESGCM def encrypt_payload(plaintext: str, key: bytes) - dict: aesgcm AESGCM(key) nonce os.urandom(12) ciphertext aesgcm.encrypt(nonce, plaintext.encode(utf-8), None) return { nonce: nonce.hex(), ciphertext: ciphertext.hex(), } def decrypt_payload(encrypted: dict, key: bytes) - str: aesgcm AESGCM(key) nonce bytes.fromhex(encrypted[nonce]) ciphertext bytes.fromhex(encrypted[ciphertext]) plaintext aesgcm.decrypt(nonce, ciphertext, None) return plaintext.decode(utf-8)AESGCM 的nonce是 12 字节随机数每次加密必须重新生成。如果同一个 nonce 被用来加密两条不同的消息GCM 的安全性会崩溃仿真程序里务必避免这种情况。decrypt方法在密文被篡改时会抛出异常因此解密函数天然具备完整性校验能力。4. 搭建可运行的加密溯源仿真系统命令行工具加 SQLite 存储4.1 系统结构与流程设计整个仿真系统采用三层结构数据层使用 SQLite核心逻辑层负责区块生成、加密、校验交互层提供命令行入口。系统需要支持trace add添加环节、trace verify校验整条链、trace export导出溯源信息、trace tamper模拟篡改四个命令。这样可以完整演示“录入数据 → 查看信息 → 篡改数据 → 被识别”的教育型闭环。数据库表结构只需要两张表。blocks表存储所有区块的完整信息包含签名和 MAC 字段batches表存储批次基本信息包括批次号、品名和创建时间。仿真系统不需要考虑高并发和复杂的数据库设计但要预留出可扩展的字段格式方便后续改成 MySQL 或 PostgreSQL。CREATE TABLE batches ( batch_id TEXT PRIMARY KEY, product_name TEXT NOT NULL, created_at TEXT NOT NULL ); CREATE TABLE blocks ( id INTEGER PRIMARY KEY AUTOINCREMENT, batch_id TEXT NOT NULL, seq INTEGER NOT NULL, stage TEXT NOT NULL, operator TEXT NOT NULL, payload TEXT NOT NULL, timestamp TEXT NOT NULL, prev_hash TEXT NOT NULL, hash TEXT NOT NULL, mac TEXT NOT NULL, sign TEXT NOT NULL, UNIQUE(batch_id, seq) );payload字段用 JSON 文本存储这样既能保留结构化业务数据又不用频繁改表结构。prev_hash在第一个区块中记为 64 个 0。解释一下为什么只对业务数据取 MAC、只对哈希签名MAC 解决的是篡改识别签名解决的是身份认证两者可以作用于不同范围。仿真系统里只需要对区块哈希签名就已经能够在验签时发现哈希不匹配的情况。4.2 编写一个完整的溯源添加命令核心实现集中在TraceChain类中它负责根据批次号从数据库读取最新的区块序号计算出当前区块的哈希并写入签名和 MAC。一次调用的完整代码如下。import sqlite3 import json import os class TraceChain: def __init__(self, db_pathtrace.db): self.db_path db_path self.mac_key os.environ.get(TRACE_MAC_KEY, demo-mac-key).encode() self.init_db() def init_db(self): with sqlite3.connect(self.db_path) as conn: conn.executescript( CREATE TABLE IF NOT EXISTS batches (...); CREATE TABLE IF NOT EXISTS blocks (...); ) def add_block(self, batch_id, product_name, stage, operator, payload): with sqlite3.connect(self.db_path) as conn: cursor conn.execute( SELECT batch_id FROM batches WHERE batch_id ?, (batch_id,) ) if cursor.fetchone() is None: conn.execute( INSERT INTO batches(batch_id, product_name, created_at) VALUES(?,?,?), (batch_id, product_name, datetime.now().isoformat()), ) row conn.execute( SELECT hash FROM blocks WHERE batch_id ? ORDER BY seq DESC LIMIT 1, (batch_id,), ).fetchone() prev_hash row[0] if row else 0 * 64 seq (row and int(row[seq]) 1) or 1 # 真实的 seq 从数据库行里取这里用 row 的下标方式简化 block TraceBlock(batch_id, seq, stage, operator, json.dumps(payload, ensure_asciiFalse), prev_hash) mac calc_block_mac(block.to_dict(), self.mac_key) sign sign_block(block, private_key_pathkey_ operator .pem) block_dict block.to_dict() block_dict[mac] mac block_dict[sign] sign conn.execute( INSERT INTO blocks(batch_id, seq, stage, operator, payload, timestamp, prev_hash, hash, mac, sign) VALUES(?,?,?,?,?,?,?,?,?,?), ( block_dict[batch_id], block_dict[seq], block_dict[stage], block_dict[operator], block_dict[payload], block_dict[timestamp], block_dict[prev_hash], block_dict[hash], block_dict[mac], block_dict[sign], ), ) return block_dict这段代码里的seq计算需要特别注意。上面示例为了可读性简化了行邻访问逻辑复现时应该先用SELECT seq FROM blocks WHERE batch_id ? ORDER BY seq DESC LIMIT 1取出上一序号再自增。为了保证并发安全实际项目可以在blocks表加唯一约束后捕获异常重试仿真系统不需要考虑这一步。数据库连接使用了with语句事务自动提交避免半截写入。4.3 防篡改校验逐块比较哈希、MAC 与签名校验功能是本系统的核心亮点。verify方法从数据库按batch_id和seq升序取出所有区块然后同时验证三件事当前区块的hash是否等于对自身数据重新计算的哈希、当前区块的prev_hash是否等于上一区块的hash、当前区块的mac是否等于重新计算的 MAC、当前区块的sign是否能被对应公钥验证通过。def verify_chain(self, batch_id): with sqlite3.connect(self.db_path) as conn: rows conn.execute( SELECT * FROM blocks WHERE batch_id ? ORDER BY seq ASC, (batch_id,) ).fetchall() for i, row in enumerate(rows): block_dict dict(row) block_data { k: block_dict[k] for k in [batch_id, seq, stage, operator, payload, timestamp, prev_hash] } recalculated_hash calc_hash_from_dict(block_data) if recalculated_hash ! block_dict[hash]: return False, f区块 {block_dict[seq]} 哈希校验失败 if i 0: if rows[i - 1][hash] ! block_dict[prev_hash]: return False, f区块 {block_dict[seq]} 与上一区块断裂 mac calc_block_mac(block_data, self.mac_key) if mac ! block_dict[mac]: return False, f区块 {block_dict[seq]} MAC 校验失败 if not verify_signature(block_dict[hash], block_dict[sign], batch_id, block_dict[operator]): return False, f区块 {block_dict[seq]} 签名校验失败 return True, 校验通过这里的verify_signature需要传入操作者的公钥文件路径。仿真系统可以在key_store/目录下统一存放每个操作者的公私钥文件名格式为{operator}.pem。签名失败通常有两种原因一是数据被篡改二是公钥与私钥不对应。排查时先把哈希校验和 MAC 校验结果分开看能更快定位是链结构坏了还是身份问题。5. 用数据实验验证“防篡改”不是口号并顺手解决三个真实的坑最后用一个具体技巧收尾给系统加一个“篡改实验模式”。这个模式会随机挑一个历史区块把它的payload改掉一个字然后重新写入数据库。运行校验后你会发现从被篡改的区块开始后续所有区块全部校验失败。这个现象能直观说明哈希链的“链式崩塌”特性也适合写进毕业设计的演示文档。尝试修改时间戳字段来绕过校验也是常见测试路径。把某个区块的timestamp改成更早的时间再重新计算该区块的hash则当前区块校验可以通过但它的下一个区块记录的prev_hash是旧的哈希因此后续仍然会失败。这也是为什么必须在每一环都记录前一个哈希——它让链条在时间维度上无法被单点修改。部署到多机器时要注意三个细节。第一时间同步。哈希链依赖时间戳排序Python 的datetime.now()在系统时间出问题时会倒拨或跳跃建议仿真系统统一用 ISO 格式存入 UTC 时间展示时再转本地时间。第二密钥管理。MAC 密钥硬编码在源码里是常见败笔如果正式项目里沿用这套方案至少要把密钥放到环境变量或密钥管理服务里。第三AES-GCM 的 nonce 不能复用而 RSA 签名在相同数据下签名结果相同这会让攻击者看出两条记录的数据内容一致。如需隐藏这些规律需要对签名输入加盐。本文实际可运行的代码量约为 300 行完整复现需要安装cryptography库执行pip install cryptography即可。仿真系统的边界要明确它演示的是加密技术如何提供数据完整性、身份认证和敏感信息保护但不模拟真实的生产环境网络攻击和密钥分发流程。如果毕业设计需要进一步扩展可以考虑把可验证的加密信息输出为二维码让消费者通过扫码快速完成链路校验这也是较常见且稳定的扩展方向。本文还有配套的精品资源点击获取