Hello Sandy, I agree every word you wrote. That's why, I am trying to explain all my login publicly to professionals. It's not rocket science. You will "just understand" when you read: Until today, we were looking from the "wrong side" I guess. We were all thinking that we must have a "fixed" key which must never change! Why? I begun to ask that question: "Why the key must be fixed?" and changed the paradigm. And I decided to dynamically update the key in encyption and decryption process. The essential logic of the algorithm is using the key as a "jump table" which is dynamically updated with every "jump" we make. To understand better how it functions, suppose that we don't have a complex function. Given the key body length(L) is a power of 2, and M is an integer to tell us where we are in the "key body": We just take the byte at position M of the key body, we XOR that byte with the byte to be encrypted(X). We increase the byte at position M and "jump to" (M+X)%L So, every time we encrypt a byte, we also change the key. It's a bit more complicated than this. But essentially this is the base logic. In real function, we do more complex operations with more variables like the salt(or nonce) value, the last byte we encrypted, the key checksum(against related key attacks) etc. Briefly, to decypher a ciphertext, a cracker needs to find out the key, and, to find out the key, cracker needs to find out the plaintext, because the key is dynamically updated according the plaintext during encryption process: Impossible! If you want to learn about the details, just take a look at the source code I've published on this blog. I believe this algorithm is the future of the encryption. Use it! And please, let me know if you use: ikizir@xxxxxxxxx On Wed, Nov 18, 2015 at 9:31 PM, Sandy Harris <sandyinchina@xxxxxxxxx> wrote: > On Wed, Nov 18, 2015 at 12:10 AM, Ismail Kizir <ikizir@xxxxxxxxx> wrote: > >> I've developed a new encryption algorithm, which dynamically changes >> the key according to plaintext and practically impossible to break. > > There is a very long history of crypto whose author considers is > secure being quickly broken. This happens to nearly all methods > devised by amateurs and quite a few from professionals. > > Despite that, amateurs like me & (I presume) you keep trying. > This is probably a good thing. Here's one of mine: > https://aezoo.compute.dtu.dk/doku.php?id=enchilada > >> I also opened to public with MIT&GPL dual License. > > This is excellent. Many people make claims for their > algorithm without publishing details, which is ludicrous > since no-one can analyze it without those details. You > have avoided that pitfall. > >> I will present a paper on a Turkish National Inet-tr 2015 Symposium > > A paper describing the design would make analysis > much easier than doing it from source code, and > like every other algorithm yours will need lots of > analysis before it might become sensible for > people to trust it. > > I suggest you subscribe to the crypto list: > http://www.metzdowd.com/mailman/listinfo/cryptography > > Once your paper is published, post a link there > to invite analysis. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
