I’ve been thinking about cryptography for some time, and I thought I’d post this here and see if anybody comes back with anything. Basically, I think there’s a very easy way to encode any data you want in a way that’s uncrackable for all practical purposes. I should mention that I am in no way a crypto expert, or a mathematical genius. This is more of a philosophical approach, and definitely being proposed by an amateur, so please bear that in mind before you use this method to protect your deepest darkest data.
The method is based on what I understand about brute force cracking of codes. Obviously, this won’t help (or will help less) if the key is already known, so for those of you putting password on post-its or using “password” or your birthday or whatever, I can’t really help you. Maybe. I’ll come back to that.
Anyhow, to crack something where the key is unknown, you basically try something as the key, and see if the results are intelligible (or have recognizable letter frequencies or whatever – some way for a computer to tell if the result looks like it might be real language). Obviously, using computers makes this much easier (as it does the encoding part of the operation). So, as I understand it – again, as a complete novice – the computer is going to try a key against your code, and see if it can get an intelligible result.
There’s another layer here where the algorithm is also unknown – you’d be trying multiple iterations of those as well. In many cases, though (like using a particular software package or coding function) where the algorithm is known, and only the key is needed.
But what if you run the encryption twice? I mean, encrypt a string of data, using your algorithm of choice, and you have a standard encryption that will resist analysis until the key is found – this is why keys are getting longer and longer as computers get faster. But if you then encrypted that string again, using the same key (or a different one, but that will be discussed later as well), then the attempt to check the validity of the key (to crack the code) would be checking against another encoded (unintelligible, non-language-patterned) string.
And why limit it to twice? The CPU load and time constraints are negligible – why not run the encryption 99 times, or 999 … You could also mutate the keystring based on the iteration you’re doing (possibly hashed with something else), and the result would be that much stronger. Then you just pass along the key and the hashing data to whomever is supposed to be able to read this stuff, and you’re good. You don’t even need a 4096 bit key anymore!
The reason I said before that this might even help people who just write their passwords down is that even if they did, the cracker would have to think of running the decryption more than once. It might be that they’d try the password, see that it didn’t work, and assume that you’re too smart to use such an obvious password lying around.
So, if this approach becomes common at all, it seems to me that anybody attempting to brute force crack (or, for that matter, known-password crack) something would have to attempt each possible password a near-infinite number of times in order to be sure they hadn’t just missed one repetition of the encoding. With a rotating password, this wouldn’t even work. The computational burden would increase dramatically, possibly to the point where cracking encryption becomes too unlikely to bother with.
The code to accomplish this, along with the rotating/hashing keystring options would be no big deal to write, but I thought I’d float the idea first and see if somebody can point out an obvious problem I’ve missed – not at all impossible. Otherwise, though, I’ll throw a PHP class together, and we can all encrypt ourselves to a fare-thee-well.
By the way, the 2n thing is about punning my last name (because that’s basically how we pronounce it) as well as the “encoding it twice” idea, and that it sounds like “2 encoding” as well as “tughan coding”. It just so very multilayered, I couldn’t resist!