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

[Michael Kjörling]

On 19 Nov 2015 04:07 +0200, from ikizir at gmail.com (Ismail Kizir):
>> 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"!

Neither of those are algorithms. They don't have keys, in a strict
sense. They do specify ways of agreeing on keys to be used with
agreed-upon algorithms, like how my web browser used TLS to agree on
AES-128-GCM and a shared 128-bit key with a web server just now.


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

So it's an IV. If it isn't, you need to explain how it is not, rather
than handwave the issue away with basically "it's something different
that I cannot explain". Nobody is going to be satisfied with such a
non-explanation.

> Changing the
> initial position of the encryption gives a "completely different
> output"!

Any encryption algorithm that does not meet this design criteria is so
fundamentally broken that it should never get past the first brief
review by the person designing it. It's called the avalanche effect,
and is caused by diffusion; on average, a single bit change anywhere
in the key or an input block should cause about half the bits of the
output to change.

> This is a precaution against, chosen ciphertext attacks.

_How?_ Don't just say "this is a precaution against X"; _explain_ how
your algorithm without this step is vulnerable to X, and how your
algorithm _with_ this step is _no longer_ vulnerable to the same
attack.

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

Again, any encryption algorithm that does not give a huge change in
the output for a small change in the input is fundamentally broken.
This is not a point of advantage, it is an absolute requirement.

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

Where did you get the number 255 from? And why is the number of
outputs not modulo the block size (which in your case sounds like it
is 8 bits, but you haven't been explicit about that)?


> The algorithm is safe against: Cryptoanalysis like : Index of
> coincidence, Kasiski, Vigenere Cypher. Because, there is no "pattern".

Excuse me? Are you actually comparing your work, which you propose as
a serious cipher, to a simple polyalphabetic substitution cipher from
the mid-1500s, which you call a _cryptanalytic attack_ worthy of
consideration today?

> For example the most frequent letter "A", of Turkish alphabet will be
> encrpyted as different values each time.

Again, this is an absolute requirement in any serious cipher. An
encryption algorithm can be generalized as a mapping from plaintext
blocks p to ciphertext blocks c (and vice versa) with the key k being
the selector: e(p,k) = p->c where the operation of the "->" mapping is
selected based on k. If you change either p or k, then the output
_must_ change. Because we generally want d(e(p,k),k) = p in encryption
algorithms (that is, that the encryption is reversible, not a trap
door function), the mapping "->" must operate on a strictly one to one
basis, selected only by the key.

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

In the words of Wikipedia: "In CBC mode, each block of plaintext is
XORed with the previous ciphertext block before being encrypted." What
you describe sounds awfully similar. Updating the internal key state
while working is not unheard of; consider RC4 for just one example.
Again, _how_ does this help protect against the attacks you list? Show
how your algorithm without any specific step is vulnerable to some
attack, and how introducing the specific step _at the very least_
renders that attack inconsequential.


> Even if salting is not used,

...which it isn't in encryption. Again, salts are used in hashes, and
even there, not in algorithms, but in implementations.

> the algorithm guarantees us that it is
> impossible to find out the key even if we have the cyphertext and
> plaintext.

Again, this is a trivial requirement of any serious encryption
algorithm. Ideally, there should exist no attack better than
exhaustive key search; in practice, we usually find some attacks that
moderately lower the complexity (like how 128-bit key AES can be
broken in 2^126.1 computational complexity using the biclique attack,
rather than with 2^128 complexity in an ideal 128-bit key algorithm
with results expected after about 2^127 operations). Generally
speaking, any algorithm that has any practical attacks significantly
better than exhaustive key search is considered fundamentally broken.

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

No. For any two eight-bit quantities A and B, there exists an
eight-bit value C such that A xor B = C. (This is trivial boolean
algebra.) For three values A, B and C, we have A xor B xor C = D, and
can thus reduce to A xor E = D for E = B xor C. Merely successive xor
operations are thus equivalent to one xor operation with some other
value, no matter how many xors you stack on top of each other.

Using plain xors will also likely leak internal key state with any
reasonably guessable plaintext. For example, if you have a US-ASCII
plaintext input and a completely random key, the output ciphertext
will have the high bit of each byte set to the corresponding bit of
the internal key state, and the remaining bits will have their search
space vastly reduced. Encodings like UTF-16 will only exacerbate this
effect in most cases. A serious encryption algorithm must be equally
secure regardless of the plaintext.


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

I still haven't seen any description of how your algorithm actually
works.

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