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

Question

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:

                 ____
                |    |
Password - |+|--| H1 |----k----
Salt -------^   |____|         |     ___
                               |    |   |
                              (+)---| H |----
i------------------------------^    |___|    | 
                                             | 
Data[i]-------------------------------------(+)-- Output_i

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.

Properties/advantages:

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).

Answer 1

If $H$ is SHA-256, the security of your scheme might be inferred from the assumption that there are no related key attacks against the SHACAL-256 cipher. (This, in turn, is a topic that is the subject of e.g. this paper.)

Intuition: Let $K$ be your derived key and define $K_i = K \oplus i$. Let $E_k$ be the SHACAL-256 cipher. In such case, $H(K_i) = E_{K_i}(initstate)$.