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

Ismail Kizir ikizir at gmail.com
Wed Nov 18 19:06:01 EST 2015


Sorry Natanael,

But your mail is a good example of "speaking without thinking"!
You just took the example I gave to explain the "base" of the algorithm.
Do you really think that I went to public without taking precautions
against "wannabee cryptoanalysts"? And I don't claim that's perfect.
There is always a room for optimization and better security. But ... :

There are 2 factors which influences security:
1. Key length L
2. Number of jumps J

Every byte to be encrypted, has "( L!(L−J)!) " possibilities to choose
for "each jump". So, which mean ( L!(L−J)!)^J possibilities for all
jumps. For each jump we make an XOR with a different element of the
key body. The first jump step is the last plaintext byte and the
following jump steps are key body bytes.
Every byte used for a jump is incremented by a factor of last
plaintext byte. So, the impossibility borns from that question: "Which
key?"; because the key at the first byte encyrpted is very different
from the key at end of the encryption.
I repeat: I think you speak without thinking too much.
I copy here the hand optimized function for 2 jumps:

uint64_t xorEncryptHOP2(uint8_t *K, uint8_t *Salt, uint8_t
KeyCheckSum, size_t InOutDataLen, uint8_t *InOutBuf)
{ // Encrypts or decrypts message and returns checksum of the InOutBuf
BEFORE encyption
  // SaltData is a 4 bytes uint8 array! IT IS NOT READ ONLY! IT WILL
BE MANIPULATED BY THE FUNCTION!
  register uint32_t M;
  register size_t t;
  register uint8_t XORVal, LastVal = 0,TmpVal; // Last PLAINTEXT byte
processed. It will be an input parameter for the next encrytpion
  register uint64_t Checksum=0;
  register uint32_t BodyMask = GetBodyLen(K); // +1 because we will
use this "Mersenne number" for & operation instead of modulus
operation
  uint8_t Body[MAX_BODY_SIZE];

  memcpy(Body,K+SP_BODY,BodyMask);
  BodyMask--;

  Salt[0] ^= KeyCheckSum;
  Salt[1] ^= KeyCheckSum;
  Salt[2] ^= KeyCheckSum;
  Salt[3] ^= KeyCheckSum;

  // Initial position of the pointer is dependent on actual salt value
  M = BodyMask & Salt[0];
  //printf("xorEncrypt BodyLen: %u KeyCheckSum: %u Salt:
%u\n",BodyLen, KeyCheckSum,Salt);
  for (t=0; t<InOutDataLen; t++)
  {
    // First jump step is previous plaintext byte
    XORVal = Body[M];
    M = (M + LastVal) & BodyMask;
    // All following jumps are based on body values
    XORVal ^= Body[M];
    M = (M + Body[M]) & BodyMask;
    MakeXOREnc(InOutBuf,XORVal,Salt,KeyCheckSum,Checksum,LastVal,TmpVal,t);

    PlainTextChecksum += InOutBuf[t];
    TmpVal = InOutBuf[t];
    XORVal ^= LastVal;
    XORVal ^= *(Salt + (LastVal&(SALT_SIZE-1)));
    InOutBuf[Counter] ^= ((uint8_t)(XORVal));
    LastVal = TmpVal;

    Body[M] += LastVal; // And we increase the key elements at
position M by a factor of Last plaintext byte
  }
  return Checksum;
}

Regards
Ismail Kizir

On Thu, Nov 19, 2015 at 1:30 AM, Natanael <natanael.l at gmail.com> wrote:
>
> 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.


More information about the cryptography mailing list