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).
  • $\begingroup$ 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 $\endgroup$ Commented Mar 17, 2014 at 12:13
  • $\begingroup$ 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. $\endgroup$
    – RocketNuts
    Commented Mar 17, 2014 at 12:29
  • $\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
    Commented Mar 17, 2014 at 12:29
  • $\begingroup$ 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). $\endgroup$
    – RocketNuts
    Commented Mar 17, 2014 at 12:30
  • $\begingroup$ Exact duplicate of this due to cross-post $\endgroup$
    – fgrieu
    Commented Mar 17, 2014 at 12:42

1 Answer 1


Worth reading:

Can I use HMAC-SHA1 in counter mode to make a stream cipher?

This is basically the same construction with the difference that you don't call it counter mode and don't assume a specific hash function.

However, you should read both answers to that topic, because the second one (0 upvotes, not the accepted answer) has a very reasonable quote from Applied Cryptography:

While these constructions can be secure, they depend on the choice of the underlying one-way hash function. A good one-way hash function doesnot necessarily make a secure encryption algorithm. Cryptographic requirements are different. For example, linear cryptanalysis is not a viable attack against one-way hash functions, but works against encryption algorithms. A one-way hash function such as SHA could have linear characteristics which, while not affecting its security as a one-way hash function, could make it insecure in an encryption algorithm such as MDC. I know of no cryptanalytic analysis of particular one-way hash functions as block ciphers; wait for such analysis before you trust any of them.

I took the liberty to highlight a few critical points. Additionally, I don't think that you gain any advantage of using this over AES. OFB and CRT are basically just stream ciphers, and even in CFB and CBC corruption of a single block just makes this and one adjacent block impossible to decrypt.

Overall, it's a nice idea, but I can't see any advantage over using "conventional" algorithms.


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