Tcl中zipfile与OpenSSL对称加密跨平台兼容性异常问题

问题核心 #

同一平台（Windows/Linux）下加密解密完全正常，但跨平台操作时，经过camellia-256-ofb加密的zip文件解密后直接损坏。换成rc4加密或者跳过最后一步加密，跨平台就能正常工作。

原因排查 #

1. 文件读写的二进制模式遗漏
   Windows下Tcl默认会把文本文件的换行符从\n转成\r\n，但你处理的都是二进制文件（加密后的文件、zip包），如果没指定二进制模式打开，字节流就会被悄悄修改。RC4是流加密，可能刚好没触发致命损坏，但本质是二进制文件被当成文本处理后，字节数和内容变了，任何加密解密都会出问题。

2. Camellia-OFB的字节处理差异
   Camellia是块加密算法，OFB模式虽属流加密变体，但密钥、初始向量（IV）的字节序或编码方式在跨平台时可能有差异。比如Tcl在Windows下默认用本地编码，Linux用UTF-8，直接传字符串当密钥的话，转成字节数组就不一样了，解密时自然对不上。

3. OpenSSL版本或实现差异
   不同平台的OpenSSL版本可能对Camellia算法的细节实现有区别，比如IV的处理、块对齐的方式，导致跨平台加密解密的流不匹配。

解决步骤 #

1. 所有文件操作强制用二进制模式 #

Tcl里打开文件必须加rb（读二进制）或wb（写二进制），写入时用puts -nonewline避免自动加换行符：

# 读文件示例
set f [open "target.bin" rb]
set content [read $f]
close $f

# 写文件示例
set f [open "encrypted.bin" wb]
puts -nonewline $f $encrypted_data
close $f

这一步是跨平台二进制处理的关键，也是最容易忽略的点。

2. 统一密钥和IV的二进制格式 #

别直接用字符串当密钥/IV，转成十六进制解码的二进制字节数组，确保跨平台字节序列完全一致：

# 256位密钥转二进制
set key [binary decode hex "这里填你的256位密钥十六进制字符串"]
# Camellia的IV是128位，同样转二进制
set iv [binary decode hex "这里填你的128位IV十六进制字符串"]

这样不管平台编码是什么，密钥和IV的字节都是固定的。

3. 检查zip打包的跨平台兼容性 #

用zipfile::mkzip时，尽量避免添加平台特定的元数据，比如禁用压缩或者用标准deflate压缩，同时不要包含平台专属的文件属性：

zipfile::mkzip "output.zip" {
    { "encrypted_file.bin" "encrypted_file.bin" }
    { "header.bin" "header.bin" }
    { "footer.bin" "footer.bin" }
} -compression 0 ;# 禁用压缩，减少跨平台差异

有些zip库会在Windows下添加NTFS权限这类信息，Linux解压时可能识别不了，导致zip损坏。

4. 对齐OpenSSL版本 #

分别在Windows和Linux下执行openssl version，如果版本差得比较多，升级到同一主版本（比如都用1.1.1系列），确保Camellia算法的实现一致。

验证方法 #

1. 先跳过最后一步Camellia加密，Windows打包的zip直接拿到Linux解压，看是否正常——如果这一步就有问题，说明zip打包或文件读取阶段出了问题。
2. 对比Windows和Linux下，Camellia加密前的zip文件MD5值，要是不一样，肯定是前面的步骤有字节差异。
3. 用同一zip文件，分别在Windows和Linux下做Camellia加密，对比加密后的文件MD5，要是不一样，说明密钥/IV或者OpenSSL实现有问题。

内容的提问来源于stack exchange，提问作者dana