I need an opinion of encryption method I thought of in High school

Question

First, I'm really not into cryptography, but have some basic knowledge. This was a thought experiment (and later exercise for my programming skills), but even though it was long time ago and I tried to speak about it with some people, I didn't get any feedback that would dismay or confirm strength of this concept. So, dear experts, please can you assess this model as valuable, already invented or shallow. Thank you in advance!

It may look it has similarities with classical PRNG stream chipper, but there is a conceptual difference that makes it (possibly) stronger. Text is encrypted based on index location of first found character in PRNG stream (i.e. letter 'D' is found in a stream after 26 generated numbers for that seed and 26 is written into temporary file, than letter 'e' is found after 12 next generated numbers (or ASCII code equivalent) and so on. Now, we don't stop here because it would be pretty easy to brute-force all seeds and stop when we find few meaningful letters (dict or similar). We repeat the process for temporary file (26,12, ...) with same seed. Part of the passcode is dedicated not for seed but for depth (number of depth levels). In this way brute-force decrypter wouldn't know should it skip any of tested seeds or it should use "decrypted" numbers as base for next level of decryption. 5, 10, even 200 levels would be easy for decryption with known pass (seed), but extreme for brute-force.

As I was advised, I'll try to be much more elaborate, so I'll start with example (the idea itself is really simple):

We have text file with following content we want to encrypt:

"Hello World"

The passcode is 5-123456

Encryption app encrypts in following manner:

• It uses second part of the pass (123456) as a seed for PRNG and firs part (5) as a depth level (will explain later)
• Program starts to generate RND from this seed in sequence and checks if first character ('H') ASCII is matched (RND is limited to generate numbers fro 0 to 255).
• Lets say this is the sequence of numbers generated: 21 4 154 (72) 35 66 (101) 100 72 (108) 22 8 9 23 (108) 55 …..
• After 4 generated numbers we have a match of character H (72), after 3 more we matched e (101), next 3, ther is l (108), 5 l(108) and so on.
• We put sequence 4,3,3,5 into temporary file (or array or anything). Here we have encrypted data, but this is piece of cake for brute-force app that finds "Hell" in dict.
• So we do it again, now with "4,3,3,5,…" as our input data. We are going through PRNG sequence searching for ASCII of 4, 3, 3, 5.
• Now things are getting really complicated for brute force engine beacuse there is no dict with "4, 3, 3, 5,…" in it. Of course, it could try using positions from all possible seeds in first run and look what chars it returns in second against dict, but we will do it 3 more times as '5' in our passcode means 5th level of depth and that many runs we'll use in encrypting our text.

It is now 2ˆ32 * 2ˆ32 * 2ˆ32 * 2ˆ32 runs it has to go and it doesn't know how to optimize(where to stop) because there is no dict for random numbers sequence.

I hope this is extensive enough to explain the idea, but of course I'm here if there is additional info needed.

Thank you in advance for assessing this idea of mine.

Regards,

Nenad

Answer 1

Well, it's a given that a newbie cipher is either insecure or overcomplicated. You, sir, are on the overcomplicated side.

Now, your cipher sounds simple; however, consider what a computer would need to actually encrypt with this cipher. It would need to seed a PRNG, generate an expected 256 times the plaintext length (so to encrypt a 11 character "Hello world" message, we'd need (on average) to generate almost 3k of PRNG data), and then go through that data, and compare each byte to the next plaintext character. If we make the wildly optimistic assumption that a CPU can generate a byte of PRNG data and test it in a single cycle, well, you're taking an expected 256 cycles to encrypt each byte; in contrast, AES can be done in about 17 cycles. And, this is all assuming a depth of 1; if you increase it, well, that increases your encrypt time as well.

In addition, your cipher has another problem; ciphertext expansion. To encrypt a character 'H', you scan the PRNG for the next occurance of 'H'; however, the character 'H' might not show up in the next 256 characters. Instead, we might have to scan (say) 519 characters before we stumble across an 'H'. This means that the ciphertext would need to be 519; however, 519 can't find into a single byte. That means that we need to encode it somehow, and that encoding is going to be longer than the original plaintext. A variable length encoding may reduce this expansion; however if it is only 20% per depth, that means that a depth of 5 more than doubles the ciphertext, while a depth of 200 means that to encrypt a single character, you'll expect to need about 6 Petabytes; that sounds a tad excessive.

As for cryptanalytic results, well, if the PRNG is Mercenne twister, and depth is 1, you can recover the passphrase if given the encryption of a known large plaintext. That's because with known plaintext and depth of 1, you're leaking byte values of the PRNG stream at known locations; with Mercenne twister, that is enough to recover the original state. On the other hand, if the PRNG is cryptographically secure, then the construction is safe (albeit far more expensive than just a standard stream cipher).