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

[Ismail Kizir]

Natanael,

First, I really want to thank you, because you are giving your
precious time to criticise my work. I really appreciate it.
But, again, you are doing the same mistake at many points: This time,
you speak "without reading" :)

>Um; no. Every practical cryptosystem allows for changing keys, and
>many require new keys for each transaction. Look at OpenPGP, TLS, etc.

My algorithm is "fundamentally different" from all of those, because,
it dynamically "encrypts" the key itself "during a single
transaction"!
You see? You haven't read what I wrote.

>Salts aren't used in encryption. Salts (and peppers) are used in
>hashing. Maybe you refer to IVs, which is an inherent component in
>block chaining modes like CBC?

"My Salt value" is a randomly choosen 4 bytes for every "transaction".
My "salt" is neither salt,  nor IV nor "salt in hashing", nor "nonce"
in cryptology, but a combination of all them.
Because:
The first jump position, depends on the salt value. Changing the
initial position of the encryption gives a "completely different
output"! This is a precaution against, chosen ciphertext attacks.
Not finished!
I XOR all bytes of salt value with 8Bit CRC, which give me a
"completely different output" for a small change in key, as I am using
those salt values for every byte to be encrypted. This is a precaution
against "related key attacks"
Changing the "salt value"(or call it nonce value if you prefer) of the
algorithm doesn't just a multiplication of possibilities by 255^4; it
"completely" changes the result. Because, it "completely" changes the
jump path!

The algorithm is safe against: Cryptoanalysis like : Index of
coincidence, Kasiski, Vigenere Cypher. Because, there is no "pattern".
For example the most frequent letter "A", of Turkish alphabet will be
encrpyted as different values each time.

Most importantly; during a single transaction, the plaintext is
encrypted with the key, meanwhile, the key itself is encrypted with
the plaintext. This avoids "chosen ciphertext" attack, "ciphertext
only attack" or  differential cryptoanalysis.

Even if salting is not used, the algorithm guarantees us that it is
impossible to find out the key even if we have the cyphertext and
plaintext. Because, "there will be a lack of information". Let's take
the trivial example: We do at least 2 jumps. So, we XOR the plaintext
byte with at least 2 numbers. In this case, even if we have the
plaintext and the cyphertext, we may just obtain the XOR result of 2
unknown values.

I will keep you writing. But, for the moment, I am sure, if you read
carefully, you will understand that you missed some points about my
algorithm before writing me those lines.

Again, I want to thank you to give me your precious time. Please keep
criticising. Me too, I will think about what you write and give you my
answers.
Sorry about my English. My reading is OK but writing is terrible :)

Regards
Ismail Kizir

On Thu, Nov 19, 2015 at 1:21 AM, Michael Kjörling <michael at kjorling.se> wrote:
> On 18 Nov 2015 23:15 +0200, from ikizir at gmail.com (Ismail Kizir):
>> 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.
>
> Are you saying that you expect us to wade through 1,152 lines of C
> code to figure out how your "simple" algorithm (implemented in "self
> documented" code) works? And what on Earth is Base64 doing in there?
>
>
>> 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.
>
> Sounds a bit like cipher block chaining, doesn't it? Except in this
> case the block is a single byte, which massively limits the amount of
> diffusion you can get.
>
>> On Linux simply
>> gcc HohhaDynamicXOR.c -O2 -Wall
>> ./a.out
>> will make integrity checks and print benchmarks. It is production ready.
>
> Um, no. Running a random application doesn't really prove anything,
> and it _certainly_ doesn't prove that the algorithm is in any way
> secure. I see _no_ past contributions here at least from you; you're
> giving us over a thousand lines of code, with several numerical tables
> with somewhat random-looking constants, and you're doing a fair bit of
> funny stuff in there with arrays and pointers. At least I am not going
> to be reviewing that code at the drop of a hat to make sure there's
> nothing odd going on in there before I run it on my system, so I'm not
> running it.
>
>
>> I know that a lot of people thinks that there is a "new amateur in
>> town claiming having invented an unbreakable encryption" :)
>> That's why, I am trying to explain all my logic, publicly to professionals.
>> It's not rocket science. You will "just understand" when you read:
>
> You haven't explained anything, and you definitely isn't being very
> specific. What problem do you see with common algorithms? How does
> your algorithm address those without being worse in other regards
> (confidentiality, performance, etc.)? What types of attacks does your
> proposed algorithm withstand? What types of attacks is it vulnerable
> to? How does your algorithm work, _specifically_? (Hint: C code is
> _not_ a lingua franca of cryptography.)
>
>
>> 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!
>
> Um; no. Every practical cryptosystem allows for changing keys, and
> many require new keys for each transaction. Look at OpenPGP, TLS, etc.
> In practice symmetrical algorithms tend to be used with a new key for
> each message. While the input key is often unchanged within a given
> message, I don't see how your system is any different in this regard;
> every encryption or decryption needs the input plaintext/ciphertext
> and a key, as a starting point. An attacker can pick a key for a given
> ciphertext just as well as the intended recipient can.
>
> Key schedules is an old concept. Some algorithms, like Blowfish, even
> use a slow key schedule to slow down attackers while providing good
> performance for normal use.
>
> The combination of single byte blocks and mutating the internal key
> state sounds suspiciously like 8-bit RC4.
>
>
>> 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,
>
> Salts aren't used in encryption. Salts (and peppers) are used in
> hashing. Maybe you refer to IVs, which is an inherent component in
> block chaining modes like CBC?
>
>> the last byte we encrypted,
>
> So, then, more or less 8-bit-block CBC.
>
>> the key checksum(against related key attacks) etc.
>
> An attacker using a related-key attack can just as easily pick related
> keys taking any additional generated "key" material into account. A
> key checksum might be useful in some specific cases, but not for added
> security (unless you can describe the threat model it protects
> against, and how it protects against that, _without_ making other
> types of attacks easier). Related-key attacks aren't very useful
> outside of highly specific situations; other types of attacks are more
> interesting to look at. Also compare DES' 56-bit keys which were
> commonly expressed as 64 bits with the parity bits all set to zero (or
> parity, like a checksum).
>
>
>> 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!
>
> At the very least parts of the plaintext is assumed to be known to the
> attacker. You'd be surprised how much can be guessed based on
> metadata. File headers are trivially guessable, and even if not, there
> is only a small number in common use. Salutations don't come in too
> many different variants. And so on. The intended recipient obviously
> can't have the plaintext any more than an attacker does; they will
> have the ciphertext (which is fully known to the attacker) and the key
> (which the attacker can guess). Don't say "impossible"; state the
> specific work factor for the best attack you have been able to devise,
> against full round _and_ reduced round variants of your algorithm, and
> describe the attacks in question as well as their requirements (memory
> and encryption operations) and constraints ("works only if the
> numerical values of the two related keys have a multiplicative product
> ending in 7 in hexadecimal, and then only during the full moon").
>
>
>> I just want Linux uses a "strong encryption algorithm" to prevent
>> States, besides inalphabet kids, from reading your files :)
>>
>> I believe this algorithm is the future of the encryption.
>
> So what exactly is _wrong_ with RSA, DH, ECC, AES, 3DES, IDEA,
> Threefish, Salsa20, or any of the huge number of existing, well
> studied, well understood algorihms by people known in the field? And
> how are you fixing those issues with your algorithm, again, without
> introducing new issues?
>
> Let alone actual implementations using those.
>
> Read through what Bruce Schneier has written in 1998 at
> <https://www.schneier.com/crypto-gram/archives/1998/1015.html#cipherdesign>.
> There is even a handy-dandy checklist in there. It probably isn't
> perfect (nothing is), but it's a good start. Let's hear what you have
> to say about each of those points.
>
> --
> Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
>                  “People who think they know everything really annoy
>                  those of us who know we don’t.” (Bjarne Stroustrup)
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography