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