[Cryptography] RFC: block cipher randomization

[Jerry Leichter]

> Please review my proposals for block cipher randomization. 
> Any feedback would be very appreciated.
> https://github.com/gluk256/misc/blob/master/encryption/randomization.md <https://github.com/gluk256/misc/blob/master/encryption/randomization.md>
It doubles the size of the data to be encrypted while protecting against - what, exactly?

Analytic attacks the depend on some property of the cipher are likely unaffected.

Known plaintext attacks may or may not be affected.  Probably not - many of them only need to know a small amount of the data.

Chosen plaintext attacks are probably affected, assuming they need to choose the entire contents of a block.

Brute-force attacks are essentially unaffected:  A brute force attack needs some way to judge whether the decryption is likely successful, which means that the plaintext has some recognizable format - more generally, that it's entropy is low.  For example, that it's English text.  That will stand out pretty trivially even if half the bytes are random noise.

As steganography, it's pointless:  Either the attacker has a way to decrypt the data, or he doesn't.  If he doesn't, the cipher text is "just random noise" either way.  If he does, it's not clear what this has accomplished.  Sure, if the "random bytes" are actually the encryption of the real information, *and the attacker doesn't know this game is being played*, he'll miss it - but there are plenty of much easier ways to do steganography *when the attacker doesn't know it's there*.

I just don't see this adding enough value to make up for the cost of (a) cutting the encryption throughput in half just to start with; (b) adding the cost of generating random bytes at the same rate as the data rate; (c) adding the cost of computing the gamma function.

Meanwhile, it's not really "harmless".  For one thing, it's providing a potential covert channel *to an attacker*!  Someone who can influence the "random" bytes can slip information out under your nose - at the same rate as you *you* can send data!

Also, there's a long history of attacks against protocols that insert data that's unpredictable to the receiver - hence *uncheckable by* the receiver.  Other than a covert channel, no attacks come to mind immediately - but that doesn't mean they aren't there.
                                                        -- Jerry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160627/746fc35f/attachment.html>