New encryption block...

[Era Scarecrow via Digitalmars-d]

On Monday, 10 October 2016 at 03:15:07 UTC, sarn wrote:
> End users won't want to permute+encrypt multiple times unless 
> you can show there's a benefit in the speed/security tradeoff, 
> so you'll need to think about that in the design.

  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.

  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). The 
larger block size also allows for multiple keys so you could push 
past far past the limitations of a single block cipher.

  As for a specific example, not really. Something fairly small, 
so personal documents and the like or archives, unlike say 
multi-media where it doesn't contain any personal data 
(probably). The only other idea is another multi-step process 
used for when generating hashes/keys or the like which is to slow 
down or make it annoyingly difficult to brute force passwords 
from a hashfile. Alternatively with the salting having it for 
encrypted communication would help hide sentences/replies where 
you reply the same thing over and over again.

Y>Do you have the stuff?
M>Yes
Y>Did you stash it in the place?
M>Yes
Y>Do you like Lasagna?
M>Yes

or something like that :P

  Oh well. My question was mostly an idea, having something to 
look over for block ciphers will be an interesting read (when I 
get to it)