New encryption block...

sarn via Digitalmars-d digitalmars-d at puremagic.com
Mon Oct 10 15:39:32 PDT 2016


On Monday, 10 October 2016 at 09:54:32 UTC, Era Scarecrow wrote:
>  The largest portion would be that much like a hash, one small 
> change will change the entire thing rather than a smaller 
> portion (with the original blocksize). The multiple 
> re-arranging and encryption steps is to ensure small changes 
> affects every other block it was part of.

With CBC block mode, for example, all blocks later in the data 
stream are changed if one block is changed.  Earlier blocks 
aren't changed because CBC processes data in a single pass (which 
is an important practical requirement for a lot of applications). 
  If you wanted all the blocks to change, two passes would be 
enough.

>  Just thinking that if someone makes a database of say the 
> first 4 bytes expected in a file format (like gzip, bzip2, 
> others, etc) then they can map most of the keys and immediately 
> know how to decrypt it (assuming it's of a particular 
> file/stream type).

Yep, this is one of the many reasons all secure block modes must 
use an IV (or equivalent).

BTW, if anyone's interested, here's a explanation of a real 
attack on short block size ciphers that doesn't assume background 
knowledge:
https://blog.cryptographyengineering.com/2016/08/24/attack-of-week-64-bit-ciphers-in-tls/
(The defence is to stop using crypto that was looking bad in the 
90s.)


More information about the Digitalmars-d mailing list