1
$\begingroup$

So I'm trying to design/make my own encryption algorithm and I believe it to be ok. I'm not saying it's extra secure but I know it's not useless so, what I was wondering is if there are any specific tests I can carry out in order to try and get a better representation of how secure my algorithm is.

Here is some data from tests that I have carried out:

  • Repeated blocks of data are different from each other
  • 1-bit change in password will completely change the result
  • 1-bit change in input text completely changes the output
  • even if you encrypt the same file with the same password you will get a different output each time because each encryption gets a different random salt
  • when tested over a large number of files matching bytes in both encrypted and unencrypted file that matched in the same place was 0.3% random is about 0.34% other encryptions get about 0.28-0.29%

here I have tried to layout the mode of operation for my algorithm. I believe it to be closest related to a PCBC mode of operation but there are some differences in the way I have laid mine out

Mode of Operation

Improve this question
$\endgroup$
7
  • 4
    $\begingroup$ "Anyone can create an algorithm that he himself cannot break" - Bruce Schneier $\endgroup$
    – user80567
    Dec 17, 2020 at 20:49
  • $\begingroup$ completely change the result means every bit is changed. If you change every bit (e.g. 10100110 --> 01011001), this means your encryption is just logical negation funciton. A good encryption algorithm should NOT completely change the result, but should change about 50% of bits. I'd suggest you revise your question and adjust properly. $\endgroup$
    – mentallurg
    Dec 17, 2020 at 21:17
  • 1
    $\begingroup$ This is more of a Cryptography question than an Information Security question, but I'm sure it's already been asked on the Cryptography SE site. $\endgroup$
    – Mark
    Dec 17, 2020 at 21:18
  • $\begingroup$ @mentallurg I'm not sure what you mean... if I change 1 bit in the password. the output field is not just 1 bit different. it changes quite a bit $\endgroup$
    – PyroDeathAdder
    Dec 17, 2020 at 21:29
  • 1
    $\begingroup$ @PyroDeathAdder: Now you say quite a bit, you don't say completely. Don't you any difference between completely and quite a bit?`:) If change of 1 bit leads to changes of 50% of bits in the result, then this can be a good algorithm. Changing everything is too much and thus bad. Changing quite a bit is too little and is also bad. The number of changed bits should be about 50%. Example: If your message consists of 1000 bits, then changing 1 bit of password or 1 bit of original message should lead to changes of ~500 bits in the encrypted message. $\endgroup$
    – mentallurg
    Dec 17, 2020 at 21:33

2 Answers 2

Reset to default
3
$\begingroup$

TLDR: There are no tests that prove that some algorithm have particular strength.

Statistical metrics can only prove that an algorithm is weak. If the metrics give "good" results, it does not mean anything. Example: If your algorithm produces encrypted messages that are indistinguishable from a random stream of bytes, you can get "good" metric values. But if this algorithm uses effectively only the first 40 bits of the 128-bit password, it can be relatively easy brute-forced.

Brute-forcing as iterative trying of all possible values is not used in serious cases, because it may require the computational power of the whole planet and even 1 000 000 000 years may be insufficient to try all possible password candidates.

Instead, first the analysis of the encryption algorithm should be done to reduce the amount of work needed for decrypt. For instance, if some algorithm uses 128-bit passwords, a straight forward brute-forcing may need 2^128 "units of work", which means that it is practically impossible to find a password. But if somebody finds a way (an algorithm, an "attack") to exclude many passwords or in some other way to reduce the number of "units of work" from 2^128 to only 2^40, then this will require little resources and it can be successfully brute-forced.

Finding ways to reduce the amount for work needed for brute-forcing is a very complex activity. It cannot be formalized fully. This is the reason why we need cryptographers.

What can you do? Such question was already answered many times on Crypto SE: Pay a professional cryptographer who will analyze your algorithm. If there are some trivial weaknesses, they will be found. But even if not found, it does not mean there are no any weaknesses.

Improve this answer
$\endgroup$
0
$\begingroup$

NIST has definitions for things like this. Here is an example:

security strength

Definition(s):

A number associated with the amount of work (that is, the number of operations) that is required to break a cryptographic algorithm or system.

Using that definition you could compare your algorithm to an accepted standard, like AES, by making a simple password that can be brute-forced in a reasonable amount of time on the most powerful computer you have access to. Then perform that same attack on the same password using the same dataset with the other algorithm. Compare the time required to breach. You would have to repeat this process at multiple password lengths (key sizes) to show how they scale with size. An algorithm may not scale linearly.

For a more detailed breakdown read this: https://csrc.nist.gov/csrc/media/publications/conference-paper/1997/10/10/proceedings-of-the-20th-nissc-1997/documents/128.pdf

Improve this answer
$\endgroup$
4
  • $\begingroup$ Guessing passwords doesn't do anything to demonstrate the security of the cipher. Best case, you are measuring algorithm running time * size of key space. $\endgroup$
    – bmm6o
    Dec 18, 2020 at 1:24
  • $\begingroup$ So how would you test "the amount of work (that is, the number of operations) that is required to break a cryptographic algorithm" ? $\endgroup$
    – HackSlash
    Dec 18, 2020 at 16:34
  • $\begingroup$ The other answer goes into more detail, but the short answer is that there are no such tests. "Test" implies assessing the algorithm as a black box, but what you need to do is analyze the internals of the algorithm for weaknesses. And even then, you might only demonstrate resistance against known attacks. $\endgroup$
    – bmm6o
    Dec 21, 2020 at 17:08
  • $\begingroup$ This one is good to: Cryptographic Algorithm Metrics Pilot Investigation[csrc.nist.gov/files/pubs/conference/1997/10/10/… $\endgroup$
    – lsalamon
    Nov 9 at 16:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.