New encryption block...

[sarn via Digitalmars-d]

On Sunday, 9 October 2016 at 20:33:29 UTC, Era Scarecrow wrote:
>  Something coming to mind is the idea of making a small 
> algorithm to be used with other already existing encryption 
> functions to extend the blocksize of encryption with minimal 
> complexity growth. In theory this would extend a blocksize of 4 
> or 8 bytes, to say 64 bytes. Not only that each stage could use 
> a different encryption type (or all the same).

Do you have an application in mind?  There are plenty of good 
algorithms to choose from today that already have a block size 
that's big enough (unlike, e.g., DES, which was too small).

>  Then encrypted again. Preferably a the rearranging is complex 
> enough to do several steps before calling it done.

Remember, you have a few baselines to compare against for speed 
and security:
1. Encrypting once with something well accepted like AES-GCM or 
AES-CBC
2. Encrypting multiple times using other algorithms

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.

>  Lastly there could be an optional salt block. Such a block 
> would allow multiple instances/results of the same encrypted 
> data and plenty of dummy data too, helping to hide identically 
> encrypted data up to the combinations of the size of the salt.

This sounds like the IV in off-the-shelf block modes:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

It's really not optional, though, because there are many attacks 
on encryption with poor IVs.

If you're interested in this stuff, I strongly recommend these 
challenges:
http://cryptopals.com/