加密文件代码

去年秋天，加密一个做安全审计的文件朋友给我看了一段代码。两百来行，代码Python写的加密，乍看像是文件某种数据清洗脚本。变量名起得规规矩矩——process_data、代码validate_input、加密output_result。文件他把文件丢进反混淆工具跑了一遍，代码结果出来的加密时候他笑了一声：这玩意儿加密了三层。

最外层是文件Base64，套了一层ROT13，代码最里面是加密AES-256-CBC。密钥没硬编码在文件里，文件而是代码拆成三段，分别藏在三个不同的HTTP请求头里。朋友说，这种写法在恶意软件里常见，但出现在一个“数据清洗脚本”里就很有意思了。

加密文件的代码，本质上是把可读的东西变成不可读的。听起来简单，做起来花样多得离谱。我见过最粗暴的——直接对每个字节做异或运算，密钥就一个字符，0x5A。这种加密用频率分析几秒钟就能破，但写代码的人显然不在乎。他要的只是让文件在十六进制编辑器里看起来像一堆乱码，挡住那些随手翻文件夹的人。

也见过讲究的。一个开源项目里，配置文件全部用age加密，每个开发者本地生成密钥对，公钥提交到仓库，私钥自己留着。CI流程里用环境变量注入私钥，构建时解密。这套流程跑起来很顺，但有个前提：团队里每个人都得理解非对称加密的基本逻辑。实际执行时，总有人把私钥误提交，或者把解密后的文件留在工作目录里忘了删。

加密这件事，密码学强度只是一半。另一半是使用它的人。

我自己的做法比较土。敏感文件用gpg对称加密，密码存在密码管理器里。命令行敲gpg -c file.txt，输入两次密码，得到一个file.txt.gpg。解密反过来，gpg -d file.txt.gpg。没什么花哨的，但胜在稳定，二十年了这套接口没怎么变过。有时候简单的东西活得久，复杂的东西死得快。

写加密代码最怕的是自己骗自己。比如有人用hashlib.md5来“加密”密码，这根本不是加密，是哈希，而且MD5早就被撞得千疮百孔。还有人把密钥写在代码注释里，然后删掉注释以为就安全了——Git历史里翻得出来。更常见的是用random模块生成密钥，忘了那玩意儿是伪随机，种子可预测。

真正让我觉得有意思的，是那些把加密逻辑藏进正常业务流程里的代码。一个电商系统，订单号看起来是普通的自增ID，实际上是用AES加密后再Base64编码的。用户看到的是ORD-2024-8871，后端解码出来才知道真实ID是15329。这样既防止了遍历订单，又不需要额外的鉴权查询。代码写得很干净，encrypt_order_id()和decrypt_order_id()两个函数，调用处毫无痕迹。

这种设计思路比单纯堆加密算法高明。加密不是目的，是手段。目的是让数据在特定环节不可读，在其他环节照常流转。

回到朋友那个脚本。他后来把三层剥完，发现里面是一段爬虫代码，抓的是某个公开API的数据。加密只是为了不让同事看懂他在抓什么。他说这比恶意软件还让他不舒服——恶意软件至少坦荡，这玩意儿披着正常代码的皮，干着不想让人知道的事。

加密文件代码写到最后，考验的不是数学，是判断力。知道什么时候该加密，什么时候不该，比知道怎么加密难得多。