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