-1

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.

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).
Cryptographeur
  • 4,317
  • 2
  • 27
  • 40
RocketNuts
  • 1,387
  • 1
  • 11
  • 23
  • 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 – Cryptographeur 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
  • @fgrieu Agree on the "H is a hashing function" not being enough. Let's say H = SHA256 or SHA3-256. Furthermore H1 = PBKDF2 with Hash function = HMAC_SHA512, the specified password, the generated 128-bit salt, 10 iterations, and output size = 512 bit. S is generated as a concatenation of system time in microseconds, current cpu cycle count, /dev/random, current process/thread ID, and some generic pseudorandom generator, altogether hashed with SHA256 and truncated to 128 bits. – RocketNuts Mar 17 '14 at 12:44
  • @fgrieu Disagree on AES-CTR being faster. This depends on the implementation of H, and particularly with SHA256 or SHA3-256 (or even more: Skein-512 which was also a final SHA3 candidate) this can be faster than the mixing/permutation rounds in AES. – RocketNuts Mar 17 '14 at 12:45
  • Some benchmarks(link): 111 MiB/s for SHA256, 139 MiB/s for AES/CTR with 128 bit key. Performance is quite similar in this benchmark; but the security issue stands, due to possible linear characteristics. As far as I know, no one has checked for SHA256. – tylo Mar 17 '14 at 12:53
  • @Henrick Hellström (comment from duplicate thread) How do you mean, related key attacks against the SHACAL-256 cipher? Notice that in my case the attacker has no influence on the keys hashed by H. – RocketNuts Mar 17 '14 at 13:08
  • B(i) may be made less vulnerable to linear characteristics without significant performance loss by doing stuff like rotating K over (i%n) bits. And optionally even XOR'ing it with a fast K2 hashed every n rounds, although this starts to defeat the simplicity purpose. – RocketNuts Mar 17 '14 at 13:12
  • @tylo Thanks, good comparison. I believe Skein-512 (which would also be a very viable choice for H) can about 6 cycles per byte (twice as fast as the fastest AES variant in the benchmark table). But you're right about the unknown risk of linear characteristics. – RocketNuts Mar 17 '14 at 13:16
  • This exact algorithm you are proposing was already discussed at Is SHA-256 secure as a CTR block cipher?. – Paŭlo Ebermann Mar 17 '14 at 14:14

1 Answers1

2

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.

Community
  • 1
tylo
  • 12,654
  • 24
  • 39