[Cryptography] A new, fast and "unbreakable" encryption algorithm

Natanael natanael.l at gmail.com
Wed Nov 18 18:30:26 EST 2015


Den 18 nov 2015 23:07 skrev "Ismail Kizir" <ikizir at gmail.com>:
>
> Hello,
>
> I've developed a new encryption algorithm, which dynamically changes
> the key according to plaintext and practically impossible to break. I
> also opened to public with MIT&GPL dual License.
> It is also quite fast; ~80% faster than the fastest mode of AES
> without cpu instruction set support.
> I will present a paper on Turkish National Inet-tr 2015 Symposium on 3
December.
>
> It is a very simple and yet efficient logic. Anyone who looks at the
> self documented(in English) C code at
>
http://ismail-kizir.blogspot.com/2015/11/hohha-dynamic-xor-algorithm-source-code.html
>  may understand why and how it is unbreakable.
>
> I simply use the key as a jump table and, with every encrypted byte, I
> change the jump table(the key) as a result of 3-4 parameters including
> the last plaintext byte itself. Briefly, I encypt the plaintext with
> the key and also dynamically encrypt the key with the plaintext.
> The code is self documented in English.
> On Linux simply
> gcc HohhaDynamicXOR.c -O2 -Wall
> ./a.out
> will make integrity checks and print benchmarks. It is production ready.

> 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 to
> plaintext during encryption process: Impossible!

This looks like a hybrid of a stream cipher and a block cipher in something
like CBC cipher mode, continously updating secret state derived from the
key and mixing it into new blocks.

Your problem is that this very certainly will have detectable biases and
fall to cryptanalysis by making simple assumptions about byte distribution
in longer ciphertexts, such as by guessing location of known headers and
statistics on unencrypted plain English in ASCII and more. Somebody else
here is probably capable of producing a proof of concept for cracking it.

Oh, and you're just using XOR to update the state? That's flawed from the
same reason OTP only works if the OT in the abbreviation is satisfied (one
time pad). In other words, if you only encrypt a plaintext as long as the
key at most.

Not to mention your jumps will make it weak to side channel analysis.
Really really bad for long ciphertexts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151119/a4029659/attachment.html>


More information about the cryptography mailing list