… What I’m proposing has little to do with CBC mode itself, it’s purely about obscuring the plaintext with truly random data to render most attacks against the cipher significantly more difficult or impossible to perform, at the cost of doubling the length of the ciphertext.

Thank you for the detailed response. I think I have it now, thanks.

Actually, I believe your method will significantly enhance security, because the block cipher’s diffusion insures that if someone can’t guess BOTH the truely RANDOM value you are appending in each block AND the cipher’s secure KEY then they see only garbage. So if you were using 64 bit random values with AES the total effective key length is 192 bits for AES128 and and 320 bits for AES256.

The method I proposed has about the same 2:1 time penalty, but does not have the 2:1 space penalty, and potentially could add even more to the security of the combined cipher.

That method is to hide a strong CBC block cipher under a second layer of encryption, and keep the IV secret. In this approach, the first block of the first layer cipher is literally encrypting in OTP mode, which insures the security of that block, and since the second layer of encryption hides the ciphertext output from that first block, which in turn is used as the IV for the second block, we can’t gain a starting point to break that block either… and so on, and so on, for ALL the remaining block.

This works because that first block is REALLY encrypted using the IV as a One Time Pad. — not some cheesy ‘psudo-OTP’– or ‘virtual OTP’,– or shake-oil OTP, it’s LITERALLY a One Time Pad – because if you keep the IV secret, then XOR combine that IV with your plaintext before encryption – you have just created a true one time pad (at least for that first 128 bit block) – and all the cryptanalysis in the universe can’t recover that first block by any method better than pure guesswork – it is absolutely secure in an information theoric sense.

So don’t underestimate a strong block cipher in CBC mode with secret IV, double encrypted under a second strong, but unrelated cipher.

So tallying things up security wise, with the adversary left to guess, potentially two 256 bit cipher keys – PLUS a 128 bit secret IV, the total effective key approaches 640 bits.

Which may not be ‘unconditionally secure’ – but should be good enough in any practical sense.

]]>In the key schedule a constant is XORd, which allows x to map to x.

There are bigger concerns with AES than that. How about that with a probability of 1020/4228250626, if you change all 4 bytes in one input word, only one byte will change after the first round. If only one byte changes in the first round, exactly four bytes change in the second round, and exactly 16 bytes change in the third round. It isn’t until the fourth round that that probability goes away. By changing all four bytes of one input word, you also have a higher probability (which I can’t be bothered to consider how to compute, but it’s pretty small, although higher than it should be if it was random) that after the fourth round exactly four bytes will have changed in such a way that at the end of the fifth round only one byte will have changed.

]]>@Anura said:

Given any bijective, nxn bit function f, there exists a value a such that x = f(x^a) for every x

Yes, using exclusive or, we can change any value to any other value.

The XOR operations you speak of are based on bits derived from a key expansion performed using the SAME flawed S-Box, leaving the possibility that this S-Box arrangement is part of the technique the NSA used to insert a back door in AES by creating a subtle interaction between the key schedule rounds and the cipher decryption rounds which allows the NSA to crack the cipher at will.

To do this they would use a round by round iterative key search, which takes advantage of interactions between the derangement permutation in the S-Boxes used in both key scheduling and encryption rounds using something like Turing,s ‘don’t eat fruit of the poison tree’ technique. In this algorithm, you set up some assumptions (which could be random guesses) then continue to add additional guesses until something doesn’t match, then prune the whole tree. The advantage of this technique is that by quickly pruning away all the can’t-be-correct assumptions it zeros in on the remaining correct answer in something like sqrt O^^{(n/2)} time. If the this is possible, you could search through a full 2^128 keyspace with 2^64 effort. For this type of shortcut algorithm to work though, you need conditions where the falsehood of a given state ‘X’ in the assumption tree excludes all the previous others as well – Which I suspect may be exactly what the oh-so-carfully contrived mathematical structure of AES was designed to allow.

Isn’t the AES S-Box permutation a fixed derangement where no 8 bit input value can EVER permute to the same value? – Ooops!

Ehh, that’s not really a problem. What happens immediately before the Sbox? An XOR operation to a subkey. Given any bijective, nxn bit function f, there exists a value a such that x = f(x^a) for every x.

]]>@ Clive said:

“The real problem however is not the maximum run length but how you would check and reduce the length from your generator without upsetting the overall statistics of the pad.”

Indeed, I was thinking the same thing.

From an information theoric point of view, ** any** deviation from a pure random distribution should actually start to degrade the security of the system, not improve it (though that would be difficult to explain to a general who sees words like “attack” leaking into his cipher text encrypted messages).

The Enigma cipher in WW2 was broken in large part EXACTLY because of a similar weakness; No letter in the Enigma cipher ever encrypted to itself, and therefor the cipher differed from a truly random permutation. Enigma used a continuously changing permutation that mathematically would be hard to break even today were it not for that one flaw.

Ironically, the no-letter-encrypting-to-itself flaw resulted from a unique patented feature of the Enigma design that it’s creators were apparently quite proud of; namely its ‘reflector’ design; which had the desirable feature of making the machine swap letter pairs so the exact same cipher process could be used for encryption and decryption, but which required that each of the rotors that acted as Enigmas ‘s-boxes’ be wired as a derangement, which is a degenerate form of permutation where no letter could be swapped with itself.

Thank goodness that no one today would be stupid enough to design a cipher with a s-box permutation that is a derangement, because then in every cipher round the S-Box function would leak the same kind of “can’t get there from here” information, that lead to the Enigma’s downfall.

Yep, it’s sure great that we learned our lesson from Enigma, and no one would be that dumb these days … Oh, wait a minute! Just remembered something… Isn’t the AES S-Box permutation a fixed derangement where no 8 bit input value can EVER permute to the same value? – Ooops!

]]>Sorry, I was writing a quick note late at night when I was pretty tired. What I’m proposing has little to do with CBC mode itself, it’s purely about obscuring the plaintext with truly random data to render most attacks against the cipher significantly more difficult or impossible to perform, at the cost of doubling the length of the ciphertext.

Generate two IVs equal to the block length, IV_{0} and IV_{1}

Compute r_{0} = LEFTHALF(ENC(IV_{0}))

Pad the message M to a multiple of one half of the block size, and break up into n chunks, each equal to half the block size (m_{1} through m_{n}).

Prepend each message chunk m_{i} with random data of equal length, r_{i}, and XOR the message chunk with the previous chunk of random data: p_{i} = r_{i} || (m_{i} ^ r_{i-1}).

P = p_{1} || p_{2} || … || p_{n}

Then encrypt the data: ENC-CBC(IV_{1}, P)

Again, the purpose is not to try to increase the keyspace, the purpose is simply to provide better resistance to known plaintext attacks by reducing the knowledge of the attacker. You don’t actually need two IVs, now that I think about it a bit more, just use r_{0} = LEFTHALF(DEC(IV_{1})) – just like with CBC or CFB mode, the IV simply acts as if it was the first block of the message.

The problem with trying to keep posts short to not upset other readers is what has caused the confusion 🙁

I’m well aware of the difference between the key space size and the permutation space size. I’m also aware that the majority of the permutations are “not good” from a cryptographic view point with such minor issues as half of them are bitwise inversions of each other, likewise value wise etc. Thus those considered suitable candidates for a crypto system by their value maps are small. An even smaller number is the subset of those that are suitable by output value difference between any two maps at any offset in the counters, this is a much harder problem to check, and I’m not aware of any short tests or explanations as to which members fall into this very reduced set, which you cover with “So if the cipher is worth a damn, uncorrelated permutations will be the rule, not the exception.”

What I’m talking about is finding the exceptions or proving they don’t exist, no matter how rare they might be.

There is an old joke of “In nature only three numbers make sense, zero, one and infinity”, what it is actually talking about is that something does not exist, there is only one example of it or there is an unknown number of examples. I’ve shown for the random permutation map there is a known bound on the run length. I’ve further shown that this bound does not apply when the output of two maps are XORed together. I’ve also shown that there is atleast one case which applies to every map that produces an endless output of zeros. Which shows that you cannot just randomly select two maps and two starting points, you have to perform a check. This takes us from no checks into one check, but it in no way rules out the further as yet unknown possibly heading for what seams like an infinite number of checks.

I’ve indicated but not proved that we should expect to see atleast a run length of double the maximum bound for a single map or for that matter a series chain of maps (think 3DES in CTR mode as an example). What I have not shown nore even proved –except for one degenerate example– is if the XOR of two or more map outputs actually has an upper bound on repeted patterns shorter than the expected repeated time of (2^N)^2.

Which brings us around to why I consider a doubling of a zero or other pattern run length degenerate.

It’s because the context of the use of the output of this XOR of maps generator is to be used directly as a “Real world One Time Pad” without human or other inspection between generation and actual use.

Look at it this way the single AES128 bit map can only produce a maximum run length of just under 3/8ths of a K of fixed pattern. This means that with a plain text alphabet of 2^5bits size like Baudot 75 charecters would be either visable as is or XORed under a repeating pattern. With the two or more XORed map generator this would be somewhere between 150 or all charecters going out to the world sight unseen in clear text or XORed under a repeating pattern. Almost the first automatic test a cryptographer does on an unknown cipher text is check for XOR under a repeating key…

Thus in this context of talking about OTPs for real world use, any generator that can increase the length of a pattern is degenerate when compared to one that does not.

When generating real world OTPs the practice is generally to stop any run lengths of more than a “word” in size of the plaintext alphabet, where the definition of a word is that specified by the ITU, of five charecters. Thus with 5bit Baudot you would be looking at a run length of no more than 25bits, and 35bits with 7bit ASCII.

The real problem however is not the maximum run length but how you would check and reduce the length from your generator without upsetting the overall statistics of the pad…

]]>No offense, but I couldn’t make heads or tails out of your CBC mode comments.

Under normal conditions, CBC adds security only by ‘whitening’ the input to the block cipher so that replicated values are avoided. This lets us avoid issues with watermarking, where the cryptanalyst knows for example that the first block of cipher contains know plain-text ‘x’ and notes that this encrypts to a now-known cipher-text of ‘y’, then can search for all cipher-text blocks containing ‘y’ and map them back to ‘x’ which IS possible in ECB mode. It also prevents chosen plain-text attacks, since the IV ‘whitening’ prevents the potential attacker from controlling the actual final bytes that are encrypted.

But CBC normally does NOT add any additional bits to the ciphers key strength, because the IV’s for the first block are usually disclosed, even for the first block, and even if not, all subsequent blocks just use the previously encrypted blocks value as the next block’s IV.

So if you want to try a possible key against block (N), you just decrypt (N) with your candidate key then XOR out the IV using the value retrieved from the previous (N-1) block, and *BINGO* you are either looking at your expected plain-text (in which case your key guess is correct) or you are looking at garbage (in which case it’s not).

But with multiple encryption layers, things are different if we use CBC in the first layer, then hide this under a second layer of encryption, because in this case the attacker can NOT read ANY IV values directly, which means that if we hide the initial IV, the attacker has to try to guess the IV’s used for each block which is essentially impossible under the obfuscation layer provide by the second cipher.

So in simple terms:

With single encryption, CBC only prevents watermarking and chosen plain-text type attacks and adds nothing to the key strength.

…but with at least two layer multiple encryption, by using CBC in the bottom layer with a cryptographically secure hidden initial IV, we see a significant strengthening of the composite cipher (making your comments about the difficulty of cryptanalysis with randomized data perfectly correct, but ONLY for multi-layer encryption)

As you your comments about RC4, sorry I don’t agree that it should be ‘depreciated’ and scrapped. RC4 has been subject to cryptanalysis for more than 20 years now, and it’s strengths and weaknesses are well understood at this point, and it would be a shame to throw that away because of a bad rap created by cryptographic vulnerabilities caused by poorly conceived, flawed RC4 protocol implementations.

This would be like scrapping AES, because it was vulnerable to the BEAST attack.

A cipher that you can fully implement in about 10 lines of code, that has survived 20 years of rigorous cryptanalysis can’t be all bad.

So, Instead of scrapping RC4, I think it just needs to be UPDATED to fix minor implementation issues that should have been ironed long ago.

Changes, like specifying that compliant RC4 implementations MUST provide a –skip parameter so we can avoid the small biases and key correlations in the initial output rounds (this was recommended by the author more than 20 years ago!). Skipping these bytes takes a fraction of a millisecond on a modern PC, so the performance hit is negligible.

So don’t knock good ole’ RC4, because if you just respect it’s requirements and limitations (which mostly involve obeying Obama’s rule – “Don’t doo stupid S#%t”) then RC4 can continue to provide very good security.

Another RC4 family steam cipher I would like to see given more study and possibly standardized is RC4A, which builds on the strengths of RC4 with almost none of the weaknesses. RC4A has been reported to still have tiny remaining biases, but I have found that with a proper key schedule, they are orders of magnitude below the levels needed to mount any kind of practical attack (even when given an oracle of.millions to billions of bytes of keystream, as in those ridiculous TLS type RC4 attacks). Frankly, one of the biggest advantages that a new RC4A standard would give us is that it would be a NEW standard, so we could start with a clean sheet of paper, and FIX things (like skipping initial output bytes) that should have been fixed in RC4, but never were, because it was already in use.

I am also interested in the chacha/sulsa family. I like that you can random-access the stream, but have been waiting for more cryptanalysis before jumping in with both feet

]]>Yup I think I got caught on that as well when the question first appeared…. Also due to another issue –smart phone on the move– I’ve just lost a longish message I was posting to Steve Z…

So not a good start to the day for both of us 🙁

]]>