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.


  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).
  • 1
    $\begingroup$ Off-topic, should be on crypto $\endgroup$
    – deed02392
    Mar 17, 2014 at 11:38
  • $\begingroup$ Why will you use the "H" algorithm and what security does it add? What is the difference between using the "H" or put directly the K xor'ed with the data? I don't think you are providing any extra security there just making it more complex without having to. $\endgroup$
    – kiBytes
    Mar 17, 2014 at 11:42
  • $\begingroup$ Directly XOR'ing K with the data will cause repetitive patterns in the output if there are repetitive patterns in the input. It would suffer from the same vulnerability as ECB mode (bit.ly/OvsEXZ). Applying H is a fast, easy yet secure way to (pseudo)randomize the cipher for every single n-bit block. $\endgroup$
    – RocketNuts
    Mar 17, 2014 at 12:05
  • 2
    $\begingroup$ 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. $\endgroup$
    – fgrieu
    Mar 17, 2014 at 12:41
  • 2
    $\begingroup$ In general, hash functions are not fast compared to block ciphers. So at least the fast part is incorrect, and I'm not sure this is more simple than e.g. AES-CTR, which does approximately the same thing while using a block cipher. $\endgroup$
    – Maarten Bodewes
    Mar 17, 2014 at 12:50

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

  • $\begingroup$ According to this the SHACAL variant based on SHA-256 is named SHACAL-2, not SHACAL-256. $\endgroup$
    – fgrieu
    Mar 17, 2014 at 13:05
  • $\begingroup$ @Henrick interesting, thanks, I suggest we discuss further in the other thread so I'll reply there. $\endgroup$
    – RocketNuts
    Mar 17, 2014 at 13:06
  • 1
    $\begingroup$ @fgrieu: You are right, related key attacks against SHACAL-2 is an independent topic, and it has been studied. $\endgroup$ Mar 17, 2014 at 13:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.