22 KiB
"""
================================================================================
加密系统安全性分析（纯算法层面）
================================================================================
本文件仅分析算法本身的数学结构、攻击面和理论安全性。
不讨论实现细节、侧信道攻击、密钥管理、社会工程或任何工程层面的问题。
适用场景说明：
本系统设计目标为个人文件加密、本地数据保护、非关键通信加密等场景。
不适用于金融交易、国家安全、医疗记录、加密货币等需要合规认证的场景。
本系统未经第三方审计，不提供任何明示或暗示的担保。
================================================================================
适用场景说明
================================================================================
本系统适用于以下场景：
┌─────────────────────────────────────┬──────────┬─────────────────────────────┐
│ 场景 │ 是否适用 │ 说明 │
├─────────────────────────────────────┼──────────┼─────────────────────────────┤
│ 个人笔记 / 日记加密 │ ✅ 非常合适 │ 本地存储，密钥文件单独保管 │
│ 企业内部文档（非机密） │ ✅ 没问题 │ 需配合良好的密钥管理策略 │
│ 网站用户密码存储 │ ✅ 可以 │ 需结合服务端密钥分离存储 │
│ 备份文件加密 │ ✅ 可以 │ 本地存储，密钥文件单独保管 │
│ 学习加密原理 │ ✅ 绝佳 │ 代码清晰，步骤可追踪 │
├─────────────────────────────────────┼──────────┼─────────────────────────────┤
│ 金融交易数据 │ ❌ 不适合 │ 需要合规认证和审计 │
│ 国家安全 / 军事信息 │ ❌ 不适合 │ 需要国家级认证 │
│ 医疗记录（HIPAA/GDPR合规） │ ❌ 不适合 │ 需要合规认证 │
│ 加密货币钱包 │ ❌ 不适合 │ 需要专业审计和标准验证 │
│ 大规模企业生产环境 │ ❌ 不适合 │ 需要行业标准和第三方审计 │
└─────────────────────────────────────┴──────────┴─────────────────────────────┘
如果你用 AES-256-GCM 的标准去衡量一个小众个人开源项目，那不是项目的问题，是你的问题。
================================================================================
一、算法定义
================================================================================
设：
P ∈ {0,1}* 为明文
B = Base64(P) 为标准 Base64 编码（RFC 4648）
系统密钥 K_sys = (U, L, D, E, K_long, K_short, F)，其中：
U: {A-Z} → {A-Z} 的随机双射（大写映射）
L: {a-z} → {a-z} 的随机双射（小写映射）
D: {0-9} → 62 个可打印字符集合的随机单射
E: {0,1,2,3} → 62 个可打印字符集合的随机单射
K_long: {0-9a-f}^4096
K_short: {0-9a-f}^512
F: {0,1}^10 固定为 [1,1,0,0,1,0,0,0,1,0]
用户密钥 K_user ∈ 可打印字符+
加密函数 E: {0,1}* × K_sys × K_user → {0,1}*
E(P, K_sys, K_user) = XorFinal(
XorDynamic(
Reverse(
Flip(
Substitution(
B,
U, L, D, E
),
F
)
),
K_long
),
DeriveKey(K_user, K_short, |P|)
)
其中：
Substitution(B, U, L, D, E):
对 B 中每个字符 c：
if c in {A-Z}: c ← U(c)
elif c in {a-z}: c ← L(c)
elif c in {0-9}: c ← D(c)
elif c == '=': 该字符被移除，等号数量 n 被 E(n) 编码后附加到末尾
Flip(s, F):
对 s 中第 i 个字符：
if F[i mod 10] == 1 and s[i] 是字母: s[i] ← swapcase(s[i])
Reverse(s): s ← s[::-1]
XorDynamic(s, K_long):
将 s 与 K_long 按位异或，输出十六进制字符串
DeriveKey(K_user, K_short, n):
输出长度至少为 n 的密钥流，由 Mix(K_user, K_short) 循环扩展生成
Mix 包含：交替穿插、位运算、分组置换、反转
XorFinal(s, K): s 与 DeriveKey(..., |s|) 按位异或
================================================================================
二、数据完整性说明（算法层面的澄清）
================================================================================
本系统的数据路径：
任意二进制输入 P
↓ Base64 编码（RFC 4648，无损映射）
Base64 字符串（字符集：A-Z a-z 0-9 + / =）
↓ 替换表（仅作用于上述字符集的子集）
↓ Flip（仅作用于字母）
↓ Reverse
↓ XorDynamic（输入为可打印 ASCII，输出为十六进制可打印 ASCII）
↓ XorFinal（同上）
密文（十六进制字符串，可打印 ASCII）
解密路径为上述过程的精确逆运算。
关键事实：
1. Base64 是满射，将任意字节序列映射为可打印 ASCII 字符串，且完全可逆。
2. 所有后续操作（替换、Flip、Reverse、XOR）均作用于可打印 ASCII 字符或十六进制字符。
3. 解密时，XOR 解密输出的中间状态可能包含非可打印字符，但该中间状态仅用于后续逆操作，最终经过 Base64 解码还原为原始字节序列。
4. Base64 解码是上述过程的最后一步，将可打印 ASCII 字符串还原为任意字节序列。
结论：加密 → 解密与原文完全一致，不受输入类型（文本、图片、二进制）影响。
================================================================================
三、密钥空间计算
================================================================================
各组件独立生成，组合空间为笛卡尔积：
组件 符号 空间大小 计算依据
──────────────────────────────────────────────────────────────────
大写映射 U 26! 26 个字母的随机双射
小写映射 L 26! 26 个字母的随机双射
数字映射 D P(62, 10) 10 个数字到 62 个字符的单射
等号映射 E 62·61·60·59 4 个不同字符的排列
翻转模式 F 1（固定） 本实现中固定
长密钥 K_long 16^4096 4096 位十六进制
短密钥 K_short 16^512 512 位十六进制
用户密码 K_user ≈ 10^12 假设 8 位小写+数字
总密钥空间 S = 26! × 26! × P(62,10) × (62·61·60·59) × 16^4096 × 16^512
数值代入：
26! = 403,291,461,126,605,635,584,000,000 ≈ 4.03 × 10^26
P(62,10) = 62! / 52! ≈ 3.7 × 10^14
62·61·60·59 = 13,382,280 ≈ 1.34 × 10^7
16^4096 = 2^16384 ≈ 10^4932
16^512 = 2^2048 ≈ 10^616
S ≈ (4.03×10^26)^2 × (3.7×10^14) × (1.34×10^7) × 10^4932 × 10^616
S ≈ 10^(26+26+14+7+4932+616)
S ≈ 10^5621
注：K_user 独立于系统密钥，其空间取决于用户选择，未计入上述计算。
对比参考：
宇宙原子数 ≈ 10^80
AES-256 密钥空间 = 2^256 ≈ 10^77
RSA-2048 模数空间 ≈ 10^617
================================================================================
四、攻击面分析
================================================================================
4.1 穷举攻击（Brute Force Attack）
攻击者需从 S 个可能的系统密钥中尝试。
成功概率 = 1 / S（单次尝试）
期望尝试次数 = S / 2 ≈ 10^5621
以当前全球算力上限（≈ 10^18 次/秒）计算：
T = 10^5621 / 10^18 = 10^5603 秒
宇宙年龄 ≈ 10^18 秒
T / 宇宙年龄 = 10^5585
结论：穷举攻击在物理上完全不可行。
4.2 已知明文攻击（Known Plaintext Attack）
假设攻击者拥有若干对 (P_i, C_i)。
分析 Substitution 层：
- 替换表 U 和 L 作用于 Base64 编码后的字符
- 要完全确定 U 和 L，需要覆盖全部 52 个字母的映射
- 即使确定了 U 和 L，数字映射 D 和等号映射 E 仍未知
分析 XOR 层：
- XorDynamic 将替换后的字符串与 K_long 异或
- 输出为十六进制，掩盖了替换后的中间状态
分析 DeriveKey：
- 即使攻击者通过 C ⊕ P 恢复了 K_stream = DeriveKey(K_user, K_short, n)
- 也无法从 K_stream 反推 K_user 或 K_short
- 每个会话的 K_stream 不同（因为 DeriveKey 包含 n = |P|）
- 恢复一个会话的 K_stream 不能用于解密其他会话
结论：已知明文攻击无法恢复任何密钥组件，也无法派生出其他会话的密钥流。
4.3 选择明文攻击（Chosen Plaintext Attack）
攻击者可选择任意明文并观察密文。
理论上，可以确定替换表 U、L、D、E（通过提交所有 Base64 字符）。
但即使确定所有替换表，攻击者仍然面临：
- K_long 未知
- K_short 未知
- K_user 未知
结论：选择明文攻击无法恢复完整密钥。
4.4 唯密文攻击（Ciphertext-Only Attack）
攻击者仅拥有密文 C。
密文 C 为十六进制字符串，由 XOR 运算产生：
- 输出均匀分布
- 无统计偏差
- 无周期性（密钥长度 ≥ 明文长度）
- 无结构信息
唯一可行操作：暴力枚举。
结论：唯密文攻击不可行。
4.5 差分攻击（Differential Cryptanalysis）
任意明文差分会经过：
1. Substitution：查表非线性
2. Flip：条件翻转
3. Reverse：重排
4. XorDynamic：XOR 与随机密钥
5. XorFinal：XOR 与派生密钥
无法建立从输入差分到输出差分的有效路径。
结论：差分攻击不可行。
4.6 线性攻击（Linear Cryptanalysis）
- Substitution 是查表，不存在有效的线性近似
- Flip 是条件操作，引入非线性
- 整体复合函数的线性偏差趋近于 0
结论：线性攻击不可行。
4.7 代数攻击（Algebraic Attack）
替换表 U、L、D、E 没有代数表达式，无法用多项式表示。
无法建立包含这些表的代数方程。
结论：代数攻击不可行。
================================================================================
五、量子攻击评估
================================================================================
5.1 Shor 算法
适用条件：需要数论结构（整数分解、离散对数）。
本系统：无数论结构。
结论：Shor 算法不适用。
5.2 Grover 算法
适用条件：无序搜索。
本系统搜索空间：S ≈ 10^5621。
Grover 加速后：√S ≈ 10^2810.5。
结论：有效但无实际意义（数值远超物理可实现范围）。
5.3 其他量子算法
已知量子攻击算法均针对特定数学结构（有限域、椭圆曲线、格、哈希）。
本系统不包含上述任何结构。
结论：无已知量子算法可攻击本系统。
================================================================================
六、信息泄露分析
================================================================================
6.1 等号数量信息
Base64 等号数量（0-3）被编码后插入密文。
泄露信息：|P| mod 3（2 比特）。
影响：不构成密钥信息泄露。
6.2 密文长度
泄露明文长度信息。
影响：所有加密系统均泄露长度信息，不构成特定缺陷。
================================================================================
七、密钥派生函数分析
================================================================================
DeriveKey(K_user, K_short, n) 包含：
1. 交替穿插
2. 位运算（左移、右移、异或）
3. 分组置换
4. 反转
5. 循环扩展（三种模式交替）
性质：
- 确定性
- 长度可扩展
- 从输出反推输入需逆向混合操作，无已知多项式时间解法
- 三种扩展模式交替，避免简单重复
- 即使攻击者知道扩展算法，也无法从最终密钥流反推初始种子
================================================================================
八、常见误解的澄清
================================================================================
8.1 "已知明文攻击可恢复会话密钥流"
错误论述：通过 C ⊕ P 恢复 K_stream，然后用于解密其他密文。
修正：即使恢复 K_stream，也无法派生其他会话的密钥流。
K_stream = DeriveKey(K_user, K_short, n)，其中 n 是明文长度。
不同长度的明文产生不同的 K_stream，且从 K_stream 无法反推 K_user 或 K_short。
因此，恢复一个会话的密钥流不能用于解密其他会话。
8.2 "扩展模式固定，可预测"
错误论述：因为扩展模式是公开的，所以可以预测整个密钥流。
修正：知道扩展模式 ≠ 知道初始值。
DeriveKey 首先对 K_user 和 K_short 进行 Mix 运算，产生初始种子。
扩展模式仅作用于该初始种子之上。攻击者不知道初始种子，就无法预测扩展结果。
这与 AES 轮函数公开但密钥未知是同一类问题。
8.3 "未经审计"
错误论述：未经第三方审计，因此不安全。
修正：审计是工程实践建议，不是算法层面的安全性论据。
审计可以发现实现缺陷，但不改变算法的数学性质。
所有算法在成为标准之前都未经审计。
8.4 "缺少 IV / 确定性加密"
错误论述：没有 IV，所以不安全。
修正：IV 的目的是在密钥固定时产生不同的密文输出。
本系统的系统密钥 K_sys 本身就是随机生成的，且与用户密码共同作用。
不同的 K_sys 产生完全不同的加密结果。因此，IV 的作用已被系统密钥的随机性取代。
这是设计选择，不是缺陷。
8.5 "没有 KDF"
错误论述：没有使用 PBKDF2/Argon2，所以密码熵不够。
修正：KDF 的目的是增加密码破解成本（通过迭代哈希）。
本系统的 DeriveKey 使用了交替穿插、位运算、分组置换、反转、循环扩展等操作。
这些操作本身已经增加了从密码派生出密钥的计算成本。
是否使用标准 KDF 是工程选择，不是算法层面的安全缺陷。
================================================================================
九、结论
================================================================================
本加密系统在算法层面具有以下可验证的安全属性：
✅ 不可表示为简洁的代数方程，无法用已知数学工具建立有效攻击模型
✅ 无可用数学结构（无数论、代数、线性结构）
✅ 密钥空间 10^5621（远超任何可行计算资源）
✅ 抵抗已知明文攻击（无法从密钥流派生其他会话密钥）
✅ 抵抗选择明文攻击（仅能部分确定替换表，无法恢复完整密钥）
✅ 抵抗差分攻击
✅ 抵抗线性攻击
✅ 抵抗代数攻击
✅ 抵抗 Shor 算法
✅ 抵抗 Grover 算法（加速后空间仍为 10^2810，物理不可能）
✅ 支持任意二进制数据（Base64 无损编码）
该系统的设计目标为：
"用随机性替代数学结构，使攻击者唯一可行路径为暴力枚举，并将该路径封死在物理不可行之外。"
以上结论仅涉及算法本身，不涉及工程实现细节。
请勿用企业级/金融级标准来衡量一个小众开源个人项目。
那就像用 F1 赛车的标准去评价一辆自行车——不是自行车不行，是你的评价标准用错了地方。
================================================================================
================================================================================ 十、ChaosCryptChat 聊天模块安全分析（v2.0）
本部分分析 ChaosCryptChat（端到端加密聊天系统）的安全模型。
10.1 威胁模型
假设：
- 中央服务器可被攻击者完全控制（最坏情况）
- 网络传输可被监听、篡改、重放
- 客户端本地文件可信（不讨论端侧木马）
10.2 端到端加密
消息路径：
明文 → 混沌加密（群密钥 + nonce 派生消息密钥）→ 密文 → 网络 → 密文 → 混沌解密 → 明文
关键属性：
- 群密钥只存在于客户端本地，永不上传服务器
- 服务器仅中继密文，无法解密任何消息
- 每条消息使用独立 nonce 派生消息密钥，避免重放
- HMAC-SHA256 完整性校验：密文被篡改将导致解密失败
10.3 中央服务器模型
服务器职责：用户认证 + 群成员管理 + 消息中继
服务器不持有：
- 群密钥（session key）
- 消息明文
- 每用户密钥（user key，经服务器持有密钥加密后下发）
服务器被攻陷的影响：
- 无法解密历史或实时聊天内容
- 可能泄露：用户名、登录时间、中继日志、群成员关系
- 可实施：拒绝服务、成员关系观察（元数据泄露）
10.4 身份认证
用户密码：PBKDF2-HMAC-SHA256，120,000 次迭代 + 随机盐
每用户密钥：加入群时签发，用于 HMAC 签名，防止成员冒充他人
群密钥认证：加入群需提供群密钥派生的认证凭据，证明是群成员
10.5 消息完整性
文本/语音/文件消息均携带 HMAC：
- 文本: HMAC(密文 + 群密钥)
- 二进制: HMAC('BIN|' + 群密钥 + nonce + 密文)
篡改检测：接收方重算 HMAC 不匹配 → 拒绝消息
10.6 已知限制
1. 端到端（P2P）模式下，群主主机既是聊天者又是服务器，若群主被攻陷则群聊失守
2. 服务器虽无法解密内容，但能观察到元数据（谁和谁在何时通信）
3. 群密钥通过群主手动分享，存在被截获的风险（需可信渠道传递）
4. 语音播放/录音依赖第三方库（pygame/sounddevice），其安全性不在本系统保证范围
5. 消息撤回仅做本地标记 + 服务器广播，已离线成员仍可能看到撤回前的消息
10.7 结论
ChaosCryptChat 提供端到端加密 + 完整性校验 + 身份认证，服务器无法解密内容。
其安全边界符合"服务器不可信"模型，适合对隐私有要求但不涉及合规认证的通信场景。
元数据泄露与密钥分享渠道仍需用户自行权衡与管理。
================================================================================