Hash Based Encryption (fast & simple), how well would this compare to AES? [duplicate]

First of all, I know it's a very bad idea to invent your own encryption algorithm. It's better to use existing known, trusted, extensively tested and studied algorithms with a proven track record. The idea below is purely theoretical, from a studying point of view. I thought of a rather simplistic encryption method, and wondering what you people think of how (in)secure this is, compared to AES.

I propose the following symmetric encryption method:

Given any input data, and a password (each of arbitrary length), we encrypt the data as follows:

H1 and H are hashing functions (e.g. SHA256 or SHA3-512). H1 and H may be the same.

n1 and n are the number of bits of H1's and H's output (e.g. if H1=SHA3-512 then n1=512, and if H=SHA256 then n=256). Preferably n1≥n.

S = a randomly generated salt of 128 bits, which is written at the start of the output.

K = H1(S+password) where + means binary concatenation.

The data is processed in blocks of n bits (the last block may be smaller).

Block i is XOR'ed with B(i) = H(K XOR i) where i is the block index (starting at zero), represented as a simple binary integer, extended to n1 bits (to match K's size).

If the last block is m < n bits, only those m bits are procesed (the remaining n-m bits of the last B(i) are not used).

The decryption procedure is basically the same, except S is taken from the encrypted data instead of generated.

I would suggest H1 = scrypt, bcrypt, or PBKDF2 with moderate work parameters, and H = SHA256 or SHA3-256.

1. It's a stream cipher. Every block of n bits can be encrypted and decrypted completely independent of other blocks. This makes the algorithm suitable for streaming, parallelization, and if part of the data is damaged or missing, the rest can still be decrypted (except if the salt at the beginning is corrupted). Additional data can be appended later, and parts of the existing data can be replaced in-place.
2. Because of the random salt S, similar data encrypted with the same password will result in completely different outputs.
3. Even if you happen to know part of the input data, nothing is revealed about the rest of the data or the password.
4. It's fast, provided that H is fast.
5. Encryption and decryption are the same (only difference is generating a random salt vs reading it).
6. Other than the 128-bit salt, the encrypted data stays the same size (unlike certain other encryption algorithms, especially asymmetric).
7. No padding involved that can be abused to tamper with the data or partial decrypting by trial and error (some other encryption schemes have padding vulnerabilities).

marked as duplicate by fgrieu, Maarten Bodewes♦, Paŭlo EbermannMar 17 '14 at 14:11

• There are currently a LOT of encryption methods being studied - including all of these. Rather than just providing a scheme and saying "What do you think of this", nowadays the very minimum that would be expected from a scheme is at least some justification of why it's worth looking at – figlesquidge Mar 17 '14 at 12:13
• Good point. Mine is worth looking at because: (1) it's extremely simple, algorithmically. Unlike other ciphers it doesn't use complex multiple-round mixing and substitution functions. It only XORs the data with a pseudorandom generator. So the strength or security essentially just boils down to the PRNG. (2) Since I'm using a well known, thoroughly studied, established hashing function as PRNG, it greatly reduces the dependencies or vulnerabilities other than the hashing function. It basically reduces the attack possibilities to a hashing function like SHA256. – RocketNuts Mar 17 '14 at 12:29
• AES-CTR has all the stated properties, and is faster. Security does follow from the assumption that H is indistinguishable from a random function, K is wide enough, and a few other things. However this is not secure with the assumption on H that it is collision-resistant and (first and second) preimage-resistant, thus stating "H is a hashing function" is not enough. – fgrieu Mar 17 '14 at 12:29
• and (3) No security through obscurity (considering that using complex constructions or mixing multiple functions to construct an 'uncrackable' cipher method is also a form of obscurity). – RocketNuts Mar 17 '14 at 12:30
• Exact duplicate of this due to cross-post – fgrieu Mar 17 '14 at 12:42