哪些特定攻击可能的细节取决于握手协议协商的 MAC 算法输出的 MAC 标记的确切大小，以及在 MAC 计算中包含正好 13 个字节的报头数据这一事实（因此我们的标题）。
此外，我在伦敦大学皇家霍洛威学院的网站上阅读：
TLS MAC 计算包括 13 个字节的标头信息（5 个字节的 TLS 标头加上 8 个字节的 TLS 序列号）这一事实部分地使攻击成为可能。
据我了解，攻击是基于填充机制、使用 CBC 操作模式的事实以及 MAC 计算时间（和压缩函数）的差异。我无法弄清楚 MAC 标头的大小如何影响。
谁能解释一下幸运十三这个名字的含义？
谢谢你。
META：这不是一个编程问题，更适合security.SX，我们已经对BEAST和POODLE等相关攻击有Qs。我想我记得在 Lucky-13 上看到过一个，但在搜索中找不到，所以我建议迁移这个。
称其为“幸运”就像他们所说的“密码学家之间的幽默感”，但伪标头为 13 个字节的重要性在您引用的段落之前的段落中进行了概述：
对于某些精心选择的消息长度以及使用 HMAC-SHA1 MAC 算法时，包含至少两个正确填充字节的 TLS 消息的处理速度将比包含一个正确填充字节或格式不正确的填充的 TLS 消息稍快一些。
并在论文的第 4.2 节中详细说明：当使用 CBC+HMAC-SHA1 密码套件时，如果攻击者系统地篡改了 64 字节（不包括 IV）密文：
当（被篡改的）解密以有效的 2 字节或更大的填充结束时，对包含 64-2-20+13=55 字节或更少字节的数据执行 HMAC（并且 >2 填充 -> <55 HMAC 很快变得非常不可能） ;
否则在 56 或 57 个字节上执行 HMAC。
由于 SHA-1 完成的 MD 填充（参见 2.1），后者需要比前者多一个压缩功能，现在是他们统计增强和检测的附加压缩功能的时候了。这给出了一个填充预言，可以从中恢复明文。
此处 13 的“幸运”是 13 加 9 仅略大于 20。正如他们在 4.3 中指出的那样，如果 SSL/TLS 的设计不同，12 会更加幸运。