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

[Michael Kjörling]

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)