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

[Michael Kjörling]

On 19 Nov 2015 02:06 +0200, from ikizir at gmail.com (Ismail Kizir):
> You just took the example I gave to explain the "base" of the algorithm.

You haven't explained anything. You haven't cited any previous works,
you haven't given any examples of attacks, you haven't explained how
the algorithm works (and again, no, C code _does not count_), you have
not explained how your algorithm is similar or different to anything
else, you use terms (nonce, salt) that are not commonly used in
discussions of encryption algorithms without even telling us
specifically what you mean, and you have no previous track record of
contributing here.

You haven't even told us some of the most _basic_ parameters about
your algorithm: number of rounds, length of key, and specific
performance (for example, cycles per byte on a given architecture). If
you have, then please, do point it out, because I haven't seen it. (If
you have, well, nobody is perfect; I might have missed it somehow.)

> Do you really think that I went to public without taking precautions
> against "wannabee cryptoanalysts"?

Nobody has analyzed your algorithm (unless there's something in the
moderation queue that I have yet not seen, but that's doubtful).
People are looking at how you present it.

> And I don't claim that's perfect.
> There is always a room for optimization and better security. But ... :

Then describe specifically what that would involve, and explain why
you did not make those changes before proposing your algorithm.


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

Actually, there are many more. Key space, _effective_ key space, basic
operation (encryption or decryption) complexity, key setup complexity,
block size, ... And that's just some I can think of off the top of my
head.

Given infinite memory, every encryption algorithm short of a one-time
pad is trivially breakable. If you can store 2^256 (keys) rows of
2^128 (blocks) columns of 128 bits (block size) each, breaking AES-256
becomes an exercise in _table lookup_.


On 19 Nov 2015 02:25 +0200, from ikizir at gmail.com (Ismail Kizir):
> If you examine well the code, you will see that there are plenty of
> carefully taken precautions against cryptoanalysis.

Cryptanalysis is not something you worry about in code, it's something
you worry about in algorithm design. In code, you might worry about
things like side-channel attacks, timing attacks and so on, but the
algorithm can be designed in a way that makes these attack vectors
more or less difficult to avoid.

> And as a last statement, I will give you various options for better
> security/speed ratios for your taste:
> Just change one line:
> 
> ...
> Body[M]++;
> Body[M] = ROL32_1(Body[M]);
> ....
> As you see, there is room for better "scrambling" and "optimizations"

Doesn't this change the algorithm, since the _only_ description of the
algorithm we have so far is this _one_ _implementation_ of it? What
are the security implications of this change? If it is a beneficial
change that you know about, why did you opt against it?


> The base of the algorithm is very very very strong. You will admit it
> if you carefully examine it.

Nobody (to within experimental error) is going to wade through over a
thousand lines of C code to figure out how your algorithm works. The
onus is on you to describe how it works.

If your algorithm was accepted for anything resembling a serious
cryptography conference, you should have all this material already
because it should have been the first things asked for when you
submitted the paper to be presented at the conference if it wasn't
already in that paper.

-- 
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)