0
$\begingroup$

How secure would the following logarithmic encryption algorithm be when tested under the same conditions as high end encryption algorithms (AES, RSA etc...).

Note: For smaller text the text will be padded to form a minimum length of 1024 bits.

For encryption:
1. Generate random numbers as same length as the message. R = [5, 13]
2. Turn message characters into ordinal numbers. M = [97, 98]
3. Encryption algorithm is as follows: M^x = R; to solve this: x = log(R)/log(M)

For decryption:
1. To find the original ordinal number again: M = x_sqrt(R, x); x_sqrt is to find the nth_root of a number, where R is the the radicand and x is index.

Example:
R = [13]
M = [98]

Encryption:
M^x = R
: 98^x = 13
: x = log(13) / log(98)
: x = 0.559425856

Decryption:
M = x_sqrt(R, x)
: M = x_sqrt(13, 0.559425856)
: M = 98

Improve this question
$\endgroup$
7
  • 2
    $\begingroup$ Well - seems you have to learn a lot yet. It works another way around. you have to (mathematically) proof your algorithm is secure (you can design a system that you cannot break, but difficult that nobody can break). I immediately see at least two ways how to completely break the encryption. E.g. having the x as whole number it reveals a lot about the key and the plaintext. As well - you are using a simple log function (not discrete), otherwise you wouldn't able to decrypt (when properly done). I suggest you to read about the cryptography or follow some course first to get some real basics. $\endgroup$
    – gusto2
    Apr 22, 2016 at 10:17
  • $\begingroup$ If you have small keys then brute forcing is always an option. Key size should not be related to message size. If that would be the case, how would you encrypt small messages? $\endgroup$
    – Maarten Bodewes ♦
    Apr 22, 2016 at 10:38
  • $\begingroup$ @GabrielVince The x isn't a whole number. It's a fraction. $\endgroup$
    – J. Doe
    Apr 22, 2016 at 10:46
  • $\begingroup$ @MaartenBodewes The idea was to pad a message to a certain length, say the minimum length would be 1024 bits? $\endgroup$
    – J. Doe
    Apr 22, 2016 at 10:47
  • $\begingroup$ Fractions and certainly floats are pretty tricky because of rounding errors and suchlike. There is a good reason why almost all cryptographic functions work with (positive) integers instead. @MrCyber I didn't see any mention of padding or hybrid cryptography (which may be needed for larger plaintext?) in the question. $\endgroup$
    – Maarten Bodewes ♦
    Apr 22, 2016 at 10:49

1 Answer 1

Reset to default
2
$\begingroup$

I'll assume R is secret, and is the key; and the ciphertext is given as a list of values x in decimal, as in the example given x = 0.559425856.

This is totally insecure: even without knowledge of R, it is trivial to reduce candidate plaintext letters to almost nothing, just by knowing the corresponding x. e.g. if we assume R is an integer in range [2..127], and x = 0.559425856, the only pair (R,M) possible is (13,98). That can be seen by tabulating x by increasing values as follows

 x               R        M
0.557913767     10       62
0.558189871     13       99
0.558248536     14      113
0.558830625      9       51
0.558890092     11       73
0.559030886     15      127
0.559300193     14      112
0.559329667     12       85
0.559425856     13       98
0.559944654     15      126
0.559957234      8       41
0.560120590     10       61
0.560365305     14      111
0.560680089     13       97
0.560692653     11       72
0.560823605     12       84
0.560868731     15      125
0.561444177     14      110

The problem can NOT be fully fixed by giving just enough decimals of x to allows decryption (here, x = 0.559 would do if we round to the nearest), for that still allows to reduce the possibilities in the plaintext a lot.

A lesser problem is that if the plaintext gets known, it is trivial to find R. Hence R can not be reused for different plaintexts. Hence this is not a cipher by the modern definition of that, which requires that there's a key reusable for several messages. That also makes use of the system impractical, as the OTP is; but at least that one is secure.

Also, the ciphertext is larger than the plaintext; another problem that the OTP does not have.

Improve this answer
$\endgroup$
2
  • $\begingroup$ What will the effect be if we make R a fraction of any value? Will that to some degree increase the strength of the algorithm? $\endgroup$
    – J. Doe
    Apr 22, 2016 at 12:10
  • $\begingroup$ @MrCyber: if R had enough decimals, that would markedly improve, but not fully fix, the total insecurity that we have now (the minimum and maximum for R will remain a weakness allowing sizable information about M to leak from x). That would also markedly increase the size of R, which is a serious problem since we need to move Rsecretly to the receiver side. $\endgroup$
    – fgrieu ♦
    Apr 22, 2016 at 13:38

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.