实用密码学
范学雷
前 Oracle 首席软件工程师,Java SE 安全组成员,OpenJDK 评审成员
14948 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 24 讲
开篇词 (1讲)
课前必读 (1讲)
案例分析 (1讲)
实用密码学
15
15
1.0x
00:00/00:00
登录|注册

11 | 怎么利用解密端攻击?

你好,我是范学雷。
上一讲,我们讨论了对称密钥分组算法的 CBC 链接模式,还提到了异或运算的好处,以及它的风险。但是,我们又留了一个小尾巴,异或运算是怎样带来麻烦的?它是怎么影响 CBC 链接模式的安全性的?我们又有什么有效的办法可以规避异或运算的风险?
这两次讨论,有点烧脑,我们姑且把它当做一次打怪升级的过程。如果弄清楚这些问题,你就可以更得心应手地使用分组算法,而且毫无疑问地超越了大部分人对对称密钥分组算法的理解。
鉴于这两次讨论的难度,我觉得最好的学习方式,就是拿上纸笔,跟着我的思路,自己画一画攻击的流程。学习一段内容,就画一画这一段的思路,扎扎实实把这一段理解下来。
其实,这也是我们学习、理解所有密码学算法攻击的一个办法。密码学算法的攻击,大部分都超乎想象,意想不到。读一段、画一段,理解一段,是一个实用的方法,也是我自己使用的方法。
好,你准备好了吗?我们开始了。

怎么利用解密端攻击?

还记得 CBC 模式吗?攻击者既可以攻击它的解密端,也可以攻击它的加密端。针对解密端的攻击,最常见的方式,就是给定密文数据,观测解密运算是成功还是失败。
那么,解密端是怎么知道解密是成功还是失败呢?到目前为止,在我们已经讨论过的密码学技术中,我们唯一能够利用的,就是数据补齐方案。我们先来看看,数据怎么补齐?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入介绍了解密端攻击CBC模式的内容,包括攻击方式、补齐预言攻击的原理和攻击路径,以及阻断补齐预言攻击的有效方式。文章还讨论了TLS 1.2中使用CBC模式加密的数据包设计中的一些问题,包括传递明文的初始化向量、初始化向量的必要性以及每次加密都使用初始化向量的原因。通过本文的讨论,读者可以深入了解CBC模式存在的攻击方式以及防范措施,对于对称密钥分组算法的攻击方法和安全性问题感兴趣的读者具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《实用密码学》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(13)

  • 最新
  • 精选
  • maver
    老师好!预言攻击这种攻击手段的攻击点是数据补齐,那么它是否只能破解密文的最后一个数据分组,无法破解密文中前段的数据分组呢?

    作者回复: 最后一个数据分组破解了,前面的数据分组破解起来难度就很小了。参考下一节里的讨论的破解思路。

    2020-12-23
    2
    2
  • 温度
    我想用4行来总结下攻击的逻辑: 已知AES解密公式:C(n-1) ⊕ T(n) = P(n)。 我们可以穷举修改C(n-1)分组的尾字节,让服务端解密,并观察结果。 若正好解密成功,根据补齐规则,“明文”尾字节基本断定为0;又根据归零律,可知T(n)尾字节必然等于改后的C(n-1)尾字节。 根据AES公式,将T(n)尾字节跟C(n-1)原始尾字节异或,即可得真正明文P(n)尾字节。

    作者回复: 👍

    2023-06-12归属地:浙江
  • Reol
    老师我有一点不太明白,关于使用不同初始化向量IV抵御补齐预言攻击。 文章原文“如果加密端和解密端每次运算(一次运算可以包含多个数据分组)都重置初始化向量,并且使用不一样的初始化向量。只要使用了不同的初始化向量,每一次运算的最后一个密文分组都是不同的,这样就不能重复的使用这个密文分组反复运算,从而切断了补齐预言攻击的路径。” 1)我对补齐预言攻击的理解:攻击是仅在解密端上反复篡改同一份密文来观察解密的结果(不涉及加密端),由于解密需要用和加密相同的IV,那么每次在解密端解密这份不停篡改的密文,应该要使用同一个IV。这样理解对吗? 2)我不明白为什么 “只要使用了不同的初始化向量,每一次运算的最后一个密文分组都是不同的,这样就不能重复的使用这个密文分组反复运算”。使用不同IV产生不同密文分组,在前面专栏讲的是为了防止攻击者根据密文数据是否相同,来猜测和寻找明文数据(比如HTTP协议的头部数据),只与加密端相关吧? 但是我只在解密端攻击,怎么就不能重复的使用同一个密文分组反复运算呢,前后因果我联系不上? 难道是让解密端不接收相同的密文或者相同IV吗(同一个密钥周期,解密端储存每次接收的密文或IV,若和以往解密重复则拒绝此次解密?)

    作者回复: 你想的有点深了,手动点个赞啊。你的理解没有问题,一个合格的解密端实现,一般不允许有重复的IV,否则的话,大概率是有漏洞的实现。这也是密码算法实现的难点之一,也就是说怎么保证解密端能够保证IV不重复,并不是特别容易。其他的地方,我们还有类似的讨论,你前后翻翻看看。

    2021-08-22
    2
  • 落点
    老师您好, 如果我们修改倒数第二个密文分组的最后一个字节,那么解密后的最后一个明文分组应该只有最后一个字节受到影响。 卡在这篇读了好几遍了,始终没有明白为什么从倒数第二个密文分组的最后一个字节可以破解最后一个明文分组的最后一个字节?

    作者回复: 想一想XOR是怎么工作的。

    2021-07-20
  • 彩色的沙漠
    老师好!看了好几遍有点理解了,我描述一下你看对不对 CBC存在“补齐预言攻击” 前提条件是解密端判断解密失败是看补齐数据格式是否正确来判断的。假设CBC模式设计之初不是通过检验补齐数据格式对不对来判断解密是否失败,则就不存在“补齐预言攻击”这个说法对吗? 攻击的思路是修改倒数第二个密文分组的最后一个字节开始,一次改变一位,观察解密端提示成功(修改的数据符合数据补齐格式),就可以计算出来最后明文分组对应的数据。从而知道最后的明文分组数据,其他明文分组数据这个思路不行。

    作者回复: 是的。

    2021-01-05
  • Geek_9ed1d3
    范老师, 您好, 使用不同初始化向量来阻断补齐预言攻击没看太明白。 接收解密方是需要记录跟踪每一次运算的最后一个密文分组从而确认它们都是不同的吗? 谢谢。

    作者回复: 如果每次加密运算都使用一个不同的初始化向量,那么前面的密文分组就和这一次的加密运算没有关系了,因此也就没有使用了,从而阻断了攻击。

    2020-12-21
  • 天天有吃的
    回去补补基础了,看了五六遍了,解密那段过程每一小段都好像可以理解,串起来就没法连起来理解; 过几个月再来刷吧

    作者回复: 这是这个专栏最难的文章,多看几遍吧。

    2020-12-21
  • Litt1eQ
    iv是为了防止同样的明文得到相同的密文这种情况 一般来说iv是随机生成的 所以传输两段相同的内容采用不同的随机iv的话 得到的密文也会大不相同 因此攻击者无法判断这两段密文对应的明文是否是同一个 因此明文传输iv是安全的(我目前的理解)感觉这个和加盐十分相似 比如做对用户名密码保存哈希值 如果加盐之后再次保存哈希的话 被撞库的概率就很低了

    作者回复: IV也可能使用序列数。明文传输iv是安全的,主要是因为攻击者没有办法在只知道IV和密文的情况下,破解出密文。如果IV没有有效信息,就可以公开。

    2020-12-18
  • ifelse
    针对解密端的攻击,最常见的方式,就是给定密文数据,观测解密运算是成功还是失败。--记下来
    2022-11-08归属地:浙江
  • ifelse
    学习打卡,这节有点硬,比较难啃
    2022-11-08归属地:浙江
收起评论
显示
设置
留言
13
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部