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

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

    共 2 条评论
    2
  • 温度
    2023-06-12 来自浙江
    我想用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)尾字节。

    作者回复: 👍

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

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

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

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

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

    作者回复: 是的。

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

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

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

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

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

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

    
    
  • ifelse
    2022-11-08 来自浙江
    针对解密端的攻击,最常见的方式,就是给定密文数据,观测解密运算是成功还是失败。--记下来
    
    
  • ifelse
    2022-11-08 来自浙江
    学习打卡,这节有点硬,比较难啃
    
    