24小时热门版块排行榜

返回列表

sadpencil

新虫 (初入文坛)

应助: 0 (幼儿园)
金币: 38.5
帖子: 10
在线: 4.2小时
虫号: 24667289
注册: 2020-11-30
专业: 信息安全

[交流] 不要再数国自然申请书的 filecode 的分隔符个数了已有1人参与

本人是做应用密码学研究的，最近也比较焦虑，但看了大家对 filecode 的讨论感觉没有分析到点子上。我直接说结论：不要再数这几个特殊符号的个数了，有意义的只有我后面提到的密文字节长度 y、密文改动开始位置 y'、filecode 的改动时间。

1. ((jtjc)) 代表 base64 编码中的 +，%2f 代表 base64 编码的 /，这俩都不是什么分隔符，其出现次数没有意义；%3d 是 base64 编码中的 =，其出现次数也没有意义。

2. 计算密文字符长度 y：把 filecode 字符串按 1. 的规则进行查找替换后，记该字符串的长度（必被4整除）为 x，那么对应的密文字符长度 y 等于 3x/4 - p，其中 p 是末尾的 = （也就是 %3d）的个数。这个 y 必定是 16 的倍数。

以我的 filecode 举例，我的 filecode 变化过，但 x 都等于 152，且 p 都是 2，也就是说对应的密文字符长度 y = 112。这个 112 代表了 7 组 16 字节数据。

3. 计算密文改动开始位置：对比你自己记录的两次 filecode 字符串（请先按 1. 的规则进行查找替换），记录从第几个字符开始发生变化，这个字符的位置我们记为 x'。计算 y' = 3x'/4。如果 y' 不是 16 的整数倍，它应该相当接近 16 的某个整数倍，找到这个数字记为 y'。

以我的 filecode 举例，我的变化前后的 filecode 的前 128 位字符相同，因此 x' = 128，y' = 96。这意味着密文这 7 组 16 字节数据的前 6 组没有任何变化，只有末尾的 16 字节可能存在任何改动。注意，我们只能知道改动的开始位置这一个信息，永远无法得知这个改动是改动了 1 个 bit，还是 16 字节全部改掉，这个信息你是完全无法通过 filecode 获得的。

假设说你的 x = 152, y = 112, x' = 84, y' = 64，那么代表你的 7 组 16 字节数据中的前 4 组是没有任何变化的，第 5 - 7 组这 48 个字节既有可能只改动了一个 bit，也可能全部改掉了，我们永远无法知道。

注意：只要 filecode 的某一位字符开始改动，后面的剩余部分应该会全部变化，其内容是不包含任何信息的。有的帖子会把 filecode 分为“固定段”和“非固定段”，其真正有用的信息就是 filecode 的改动开始位置。大家不要再看非固定段有什么字符了，这部分不包含任何信息。

知道 filecode 的改动开始位置改了有什么用呢？我们不妨假设这么一种情况：我们假设这个数据是由个人信息+状态+时间戳拼接而成，那么如果 y' = 96，说明末尾的时间戳改了，意义较小；如果 y' = 64，说明中间的某个状态改了，这个就要格外关注了。

4. filecode 的改动时间：这个得你自己查 filecode 的时候顺便把时间记下来。

联合 3. 和 4. 两个信息，你才能得到最准确的判断。

对命题 1 的证明：我们知道 + 的 url 编码是 %2b，再对字符串 %2b 做 base64 编码即可得到 jtjc，而两层括号可能是程序员为了避免 jtjc 被识别为普通的 base64 字母部分而引入的转义字符；%2f、%3d 由 url 编码易知。

对命题 2 的证明：由 base64 编码规则易知。

对命题 3 的证明：观察不同人的、同一人的不同时期的 filecode 的 base64 解码结果可知，其字节数组的特征与 aes-128-cbc 加密高度相似，而且密钥、初始向量应该是固定值。因此所有结论可由 aes-128-cbc 的性质得出。

回复此楼