# Encrypting a message by calculating the digits of a complicated irrational number

I have no background in cryptography at all so excuse my ignorance if this is a silly question. I was pondering ways in which I could encrypt a message and I came up with the following idea:

1. Me and my friend agree on some 'complicated' irrational number. For example $$\log(\tan(\sqrt{123e}))$$.

2. Using our computers, we can calculate an arbitrary amount of decimal points of this number.

3. Convert this number into Base 26.

4. Shift the 1st character of our message by the first digit after the decimal point of $$\log(\tan(\sqrt{123e}))$$ in Base 26, and the 2nd character by the second digit and so on.

Does this allow me to write an arbitrarily (or infinitely) long message, with no way of an outsider cracking the code except for 'guessing' my irrational number?

Edit: To clarify, I am only using the specified irrational number as an example. I do not even necessarily need to use known math operations such as logs, trig or roots. I just need a way to calculate an irrational number with a predefined method.

That method is doomed, if only because $$\sqrt{123\,e}\approx6\pi-0.56\ldots$$, therefore $$\tan(\sqrt{123\,e})<0$$, therefore $$\log(\tan(\sqrt{123\,e}))$$ is not a real number.

Another issue is with "the first digit after the decimal point of (the absolute value of the irrational) in base 26": this digit is not evenly distributed among the 26 possible values. Some variant of Benford's Law will apply.

Even if we mostly fix this (e.g. by ignoring the four left digits starting with the first non-zero digit ignoring the decimal point), you'll find that for most real numbers defined by a short mathematical expression, the cost of computing an extra digit grows more than linearly with the index of the digit (One should be happy if it's only with the square of the index), making the method impractical for long messages. As pointed in comment memory requirements also increase. If we used fixed-size floating point numbers (as considered in that other answer), these performance and size problems would vanish, but then a pattern would quickly appear in the base-26 digits.

And then it's about as easy to brute-force irrational numbers with short expression as it is to brute-force passwords in traditional cryptography. Because messages are typically redundant, it's possible to test if a guess of a key/password/irrational constant with short expression is the right one, and then fully decode the message.

The method is not stated for multiple messages for the same key, a practical necessity.

And it does not provide integrity: knowing that the message is PAUL, it's easy to turn the ciphertext so that it decrypts to JACK.

Thus all in all, the method is neither well-defined as is, nor practical, nor safe. Practical password-based cryptography (with Argon2 for key stretching, and AES-GCM for the rest) does much better on all criteria when the correspondents agree on a mere passphrase.

• It also requires a growing amount of memory because irrational numbers by definition do not repeat, so any finite-memory state machine cannot calculate irrational numbers beyond a certain point. Commented Jun 24 at 21:34

With carefully chosen functions and attention to numerical stability, this could work as a keystream generator. Normal 64-bit hardware floating point calculations wouldn't have enough state to be secure. You would likely need a software-based arbitrary precision library, and configure it for at least 256 bits of precision.

But we already have much more computationally efficient keystream generators that are less likely to have properties that make cryptanalysis possible. When a new keystream generator algorithm is proposed, it takes years of research for the scientific community to be convinced of its security. A custom algorithm made by non-expert is often only secure in the way that no-one bothers to spend enough time to break it.

• Nitpick: if one uses fixed 256-bit precision, I'm afraid the generated keystream repeats after 256 characters, or is it 6656.
– fgrieu
Commented Jun 24 at 9:27
• @fgrieu 2 to the power of 256 which is a lot. (divided by 8 or not divided by 8, it's still a lot) Commented Jun 24 at 10:42
• @Stack: With 256-bit mantissa there are over $2^{256}$ numbers that can be coded, but that does not tell the period of the expression as digits is anywhere near $2^{256}$. E.g. in Python3, try import math and print("%.70f" %math.cos(1)), yielding 0.5403023058681397650104827334871515631675720214843750000000000000000000. The first 18 digits or so are enough to predict all the other ones, and past some point they are all 0.
– fgrieu
Commented Jun 24 at 12:07

Also Rounding errors.

Computers and languages can calculate trigonometric functions differently. And sometimes they're wrong. sin(PI) = 0 on an Arduino Uno, whilst Math.sin(Math.PI) = 1.2246467991473532E-16 in Java. And Math.sin(100 * Math.PI) = 1.964386723728472E-15. Both are wrong as mathematically $$\sin(x\pi) = 0$$ where $$x \in \mathbb{Z}$$. Thus one party may not be able to decrypt the other's messages. That's why there aren't many floating point cryptographic primitives.

Doomed?

Point 1 is not entirely doomed if you ignore the mathy bit. Your 'secret' irrational number is represented as \log(\tan(\sqrt{123e})) in the TeX language. Which in UTF-8 language is [92, 108, 111, 103, 40, 92, 116, 97, 110, 40, 92, 115, 113, 114, 116, 123, 49, 50, 51, 101, 125, 41, 41]. That's 832 bits of information. And that makes a pretty good pass phrase. Then with that pass phrase make a cryptographic key using a key derivation function. And finally use that key with conventional authenticated cryptography, such as AES-GCM.

• Rounding errors are an issue, but there are arbitrary precision floating point libraries. Then speed is the problem! "832 bits of information" is very overrated. I'm seeing $\log(\tan(\sqrt{123e}))$ as applying a sequence of 4 operators to a 3-digits number: times $e$, $\sqrt\,$, $\tan$, and then $\log$ (of the absolute value so that it yields a real). If we have 64 operators to choose from, we end up with less than $\log_2(10^3\times64^4)<34$ bits of information to describe all expressions of this form. Even if we had 64 forms of comparable complexity, that's within 40 bits of information.
– fgrieu
Commented Jun 23 at 14:47
• As an aside, even if we count UTF8 characters that could be encoded but are invalid, we get to a mere $2^7+2^{11}+2^{16}+2^{21}$ UTF8 characters, thus with at most 23 such characters we get to less than 485 bits of information encoded in an at-most-23 characters (up to 92-byte) UTF8 string, not 832 bits. And a minuscule fraction of these are a valid LaTex expression for an irrational number.
– fgrieu
Commented Jun 23 at 15:13
• What about a computer program that generates an irrational number (not using the normal math operations)? Commented Jun 23 at 17:01
• @Cristof012: yes generating the expression for the irrational number is possible, and (together with a few adjustments like removing the few leftmost base26 digits) makes the method secure. But you need to securely transmit the mathematical definition of the generated number to the other party, just like a passphrase long enough to be secure. And that does not solve the issue that the longer the message, the more each extra character tends to cost.
– fgrieu
Commented Jun 23 at 19:06
• @fgrieu Whereas I'm suggesting in my answer that $\log\hamster(\tan(\sqrt{123e}))$ is a good pass phrase, whist not necessarily mathematically correct... Commented Jun 24 at 12:32

If you can calculate the number, and I know which number it is, then I can calculate the number. And if you have a number that is very hard to calculate then you spend a lot of effort on it - even if nobody ever attacks it.

All cryptography tries to find keys that are affordable for you to create (for example, if you need two 1,024 bit primes, that’s not exactly cheap, but nothing that your computer or phone cannot handle). And that are then substantially harder to break, so for an attacker breaking your keys isn’t necessarily impossible, but too expensive.

In your case you don’t have the cost difference between your cost and the attacker’s cost.