AES(128或者256)加密是否扩展数据?如果是这样,减多少?

时间:2020-03-06 14:21:49  来源:igfitidea点击:

我想在软件产品中添加AES加密,但是我担心会增加数据的大小。我猜想数据确实会增加,然后我必须添加压缩算法来进行补偿。

解决方案

AES不会扩展数据。而且,输出通常是不可压缩的。如果打算压缩数据,请在加密之前进行压缩。

但是,请注意,AES加密通常与填充结合使用,这将增加数据的大小(尽管只有几个字节)。

我相当确定AES加密不会对要加密的数据添加任何内容,因为这会泄露有关状态变量的信息,这对于加密来说是一件坏事。

如果要混合使用压缩和加密,请按此顺序进行。原因是加密数据(理想情况下)看起来像完全是随机数据,并且压缩算法最终将使数据变大,这是因为它无法实际压缩任何数据以及任何压缩文件格式附带的簿记开销。

如果需要压缩,请在加密之前进行压缩。

AES不会扩展数据,除了最后一个块末尾的一些填充字节外。

生成的数据无论如何都不能压缩,因为它们基本上是随机的,没有基于字典的算法能够有效地压缩它们。最佳做法是先压缩数据,然后再加密。

不会。唯一的变化是少量填充将数据与块大小对齐

但是,如果要压缩内容,请注意,应在加密之前执行此操作。加密的数据通常应该与随机数据没有区别,这意味着它不会压缩。

@freespace和其他人:我从密码学类中学到的一件事是,我们不应该在加密之前就压缩数据,因为某些可重复的压缩流块(例如节头)可能会使破解加密变得更加容易。

通常在加密之前先压缩数据。此后再压缩是行不通的,因为AES加密的数据似乎是随机的(对于任何好的密码,除了任何标头和其他内容以外)。

但是,压缩可能会在某些情况下引入旁通道攻击,因此我们必须分析自己的用途。最近有报道称这种攻击是针对加密的VOIP的:要点是,不同的音节在使用VBR压缩时会产生比特率的特征变化,因为某些声音的压缩效果更好。由于数据以其生成的速率传输,因此某些(或者全部)音节可以通过充分的分析来恢复。解决方法是或者使用(效率较低的)CBR压缩,或者使用缓冲区以恒定速率传输,而不管编码器发出的数据速率如何(增加延迟)。

AES将16个字节的输入块转换为16个字节的输出块。唯一的扩展是将数据向上舍入到整个块。