AES ECB experiment

Question

Generally speaking, ECB mode shouldn't be used. ECB seems to be more of a basic building block than anything else. Because I thought it would be interesting to experiment with encryption (this method isn't something I want to use in actual software for release), I came up with the following method for using ECB and want to know if it's any good:

1. Generate initialization vector -> IV.
2. SHA256 password -> key.
3. Join IV and key and run through SHA256 -> newKey.
4. Encrypt one block of plain text with newKey.
5. Run newKey through SHA256 -> newKey.
6. Goto 4 until done.

Is this any good at all? If not, what are some of the most immediate problems with this?

Answer 1

What you have devised is no longer ECB.
ECB encrypts multiple blocks using the same key.
The reason we have modes of operation is so that we can encrypt multiple blocks using the same key in a way that is secure, that is identical blocks of plaintext do not encrypt to the same ciphertext block, among other properties.

What you have devised uses a different key for each block, which is derived from a master key, and requires a full invocation of SHA-256 for each block. This should be (see below) as secure as CBC mode, except that is is substantially, hilariously, slower.

The other performance issue you have is with random access. In order to get to later blocks, you need to derive the key for all prior blocks. If you want to start deriving key material before the data is available, you need to store it, lots of it, 1GB of plaintext takes 2GB of key material for AES-256.

One of the possible issues you will run into is that you need to create new key material for each block, and you need to save the key material in accessible memory in order to do that. Single key modes of operation allow the key material to be derived and stored in CPU registers, and stay out of regular system memory if the implementation and hardware supports it, which modern processors do.

So, while this may be secure from a ciphertext perspective, it will not be easy to secure from an implementation perspective. Add that to the crippling performance issues, and this has no advantages over CBC mode. Depending on plaintext and implementation, it may be less secure than ECB in practice.

Answer 2

It's not ECB, but you "invited" another mode of operation. The best idea to describe your algorithm is as a stream cipher with an other function than XOR to interleave your key stream with the plaintext: The "IV key hash" generates a key stream like a good stream cipher should, and encrypting the plaintext with the key stream block is like XOR in a normal stream cipher.

Yes, you solve the problems of the ECB mode:

• The same plaintext blocks will encrypt to the same cipherblocks. << Not in this cipher, because the key changes for every block.
• Malleable: You can interchange different blocks to change the meaning of the plaintext << Not with your cipher, because the block would be decrypted with the wrong key.

Has your cipher other problems? Yes:

• It needs one hash operation and one block cipher encryption for every block encrypted. That's pretty slow. Modes like CTR or a "real" stream cipher are normally much faster.
• As soon as the key hash repeats (for any instance of the cipher), you will get the same key stream for the block cipher. If you want to solve this problem don't just hash the previous hash, but hash the previous hash + the key + the iv + a counter (the position of the block you want to encrypt, 1 for the first block, 2 for the second, ...). This would slow the cipher down even more, through.

In my opinion this is much slower, but should be more secure than the other common modes of operation (CBC, CTR, of course ECB, ...) - at least if the implementation is correct and secure against other ways to get the key material. (Don't take this as advice to use this cipher. There are much better alternatives, and "more secure" doesn't get you anywhere if the original system is already secure.)