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/
