Skip to content

Can you use traditional cipher be used in public key cryptography?

Featured Replies

I wanted to run a brainstorm to the community.

To have public key cryptography you need a one-way-function.

But what if you made a public key based on a known cryptography scheme?

For instance Gematria can be used to encrypt a message. What if Gematria was used to create a private key. And a public key was created by “many cycles” (iterations) of the private key.

The secret message (plain text) is then encoded by Gematria according to the private key.

Then knowledge of the private and public key decipher the message.

Is it possible or too easy to crack? It is dependent on the deciphering, but I think I have a simple enough scheme to work.

More details would be required to provide an answer; there seems to be a mixture of encryption, encoding and signing in your post.

On 8/27/2026 at 10:35 PM, Trurl said:

The secret message (plain text) is then encoded by Gematria according to the private key.

That defeats the principal property of public-key encryption.

Encryption:
plaintext --recipient's public key--> ciphertext
ciphertext --recipient's private key--> plaintext

Signature:
message --signer's private key--> signature
message + signature --signer's public key--> valid / invalid

Encoding:
data --encoding rules--> encoded data
encoded data --decoding rules--> data

  • Author

The protocols are the same in my example as your protocol.

I am just using a substitute cypher like Gematria to encipher the keys. It doesn’t have to be Gematria. It can be other established ciphers.

The goal is to simplify the encryption. By that I mean easier math and more security with less computation. I don’t even know if the idea is even a new concept. But I think the reason we don’t see it implemented is that when RSA was invented they didn’t have the computer language to run it.

  1. I am saying to make a private key:

     Make a cipher based on the key to any Gematria cipher.

  1. Make a private key:

     Run the private key through many iterations of Gematria ciphering.

  1. Encode the plain text with Gematria based on the public key.

As long as the public key can not reverse the ciphering text of the plain text, the private key can decode the ciphering text and we have a less computation encryption scheme.

On 9/1/2026 at 7:03 AM, Trurl said:

The protocols are the same in my example as your protocol.

You said (bold by me)

On 8/27/2026 at 10:35 PM, Trurl said:

The secret message (plain text) is then encoded by Gematria according to the private key.

My comment:

On 8/31/2026 at 9:50 PM, Ghideon said:

Encryption:
plaintext --recipient's public key--> ciphertext

If you encrypt with the private key then everyone with the public key can decrypt. There is a use case for encrypting with the private key but it is related to creating and verifying digital signatures.

Anyway,

On 9/1/2026 at 7:03 AM, Trurl said:

As long as the public key can not reverse the ciphering text of the plain text

This is what you need to describe in more detail. So far the idea you describe makes decryption trivial by using the public key.

Note:

On 9/1/2026 at 7:03 AM, Trurl said:
  1. I am saying to make a private key:

     Make a cipher based on the key to any Gematria cipher.

  1. Make a private key:

     Run the private key through many iterations of Gematria ciphering.

  1. Encode the plain text with Gematria based on the public key.

It is a little confusing; you have two private keys, the public key needs to be created somehow.

  • Author
16 hours ago, Ghideon said:

  On 8/27/2026 at 4:35 PM, Trurl said:

The secret message (plain text) is then encoded by Gematria according to the private key

#2 of my steps should say public key.

Make a public key:

Run the private key through many iterations of Gematria ciphering.

I am basing the fact that using the public key to encipher the plain text is a one way function.

So much so that it may even be difficult to decipher with the private key.

If Gematria is used as a cipher the plain text will not be deciphered knowing the public key even with also having the cipher text.

The hypothesis is the Gematria cipher can act as a one-way-function.

It is just a hypothesis. I have no experiment yet.

The reason why I believe you can’t reverse the cipher text with the public key is because the Gematria cipher relies on the plain text.

I know the idea is abstract. It may not work. But I see potential from this hypothesis. As you say if the public key reverses the cipher text it doesn’t stand. But if the plain text and public key is not a one-to-one function then we have hundreds of new public key encryption schemes.

@Trurl

Me thinks, you never did it in your life..

So, let's do it.

On Windows download VirtualBox, download some Linux ISO file, for example Ubuntu or Kali Live e.g.:

https://www.virtualbox.org/wiki/Downloads

(170 MB for Windows, 110 MB for Linux - but if you have Linux you don't need to install VirtualBox in the first place)

https://old.kali.org/kali-images/kali-2024.4/kali-linux-2024.4-live-amd64.iso

Create VM with 4GB RAM, disk space is irrelevant - you will use Live Linux i.e. without installation (it will be a way quicker). 10-15 seconds to start, instead of 15-30 minutes to install it.

You need to have openssl installed. Kali and probably most of other distributions have it built-in so nothing needs to be installed.

To create private key with RSA algorithm you open Terminal and use:

openssl genrsa -out private.key 4096

4096 is the number of bits / 8 = 512 bytes.

Example private key file:

-----BEGIN PRIVATE KEY-----
MIIJQgIBADANBgkqhkiG9w0BAQEFAASCCSwwggkoAgEAAoICAQCiC9MUyjygZWGB
F9g9EysaNp46O0NEOUTJmlnzV6WlXvKqn1ggPGmFzGxUB4UPTOrFdMGGrZRPwPLP
6X7VZTRZTrEiu48qrkP/dCOX79XHCcgK0iBTuDPjM9KZLiovg3EjS1CrWC4swcKx
UF0wpL7QwQIlfKyYThL2FPmVIf4hPWDvvaEYb64C+onxTlqVPuHl4K3va//tXl92
tdVR9mzrVLAsneyj5aUlQUiVgl0eTzaRUG4TYU5bC9SW406A6bA2ev04ChrhG5oI
wa62Gf/C7o6ZYnlmrjTw1yMfzrDwBsuyr+RIvH6YubM8ISArwhPQ4aQMR/iq7SWA
PYnQi3JjkQwbRW0QmI3wgFMmW3ML/kmvd6Gqn9x49nuo3yarttUPVkLhtF0pDNLY
1UawXpJ2WK4X1hL1zJ0HLCQBAzY4jvZG3TEI6cL7RueVCE7e8TwwANPVVB9J/YEj
PX6J2sf9uvIqktKaJunZDxR2sliTGvZyJj9+8xIss1U0lYoEO5K/XiYua3g7PBLC
Se1o4w03dUgb/kwSgnSWahv1Z7zhqea+e2WOTH4YWY0Cy+NBFYQ2WmBcVHNKyij/
5MSVisbSAevZSFY+5UEjsOiFz4nyapXpg04q7p5WwmxVlRuQ6vlDn7DeOSiRS7HY
uyZZuCJOqO2jdO2vWX1wWdjj27MBNwIDAQABAoICABulEccns00XzpkT5M+SkBVi
QP8lMhYXAQ21t+fESZ2bQ6HpGkMxmzz4wXhaahBQqnKyNvvPbBBpFeNzbbBhGhus
SZrnzYZWAYK4oQPgJiPVHtv9ugceUzfNFP4N+qNtdKU1SZdZrVL0YU8XqzZLvMPn
UYLssJMxKpnxvRx8lpq8Gmf7/VoqX1Dhxhu1Js30UtyBRpskXR51LasWXUSk2jMR
mRabgI37dP+UkhnzighMMj57LrQ+svvkWkm9kJx8gZPhyoY/bxN9PnuE81XcvJ3Y
TdqMCrMCQETgJv1bqSLhvemHiVYBVkWe1J2K9y6P5wqJHA/+TUV3vKCSnwrFZ2eg
GLw+OhGO+v321qv1wRXJ4qAoF4812P1XZRf7WV3A3S1MX37lGqxu8PH9VFhbjmX5
9tTehwdXtqjNHZRShjh2yz/AHJVdF1oRrwIf7GyyN4aE+/aRU0r6MhuTbJan1tWW
RbC8sC0DYQI3/BQlHfoD+yRHmeMwW8uZgVhGfQtT5WYOvPA8dnn4qd65GrJAtL9w
Y6a0PWDvBV75+eJ9Ho+k8BfINHP7T8fejJpGUjeEiJrbv3qB+wMmF0tjFqymHgXr
/8ezN1Eb14g9N1ZTzryqEdp6MEz64SqRI0wZFmsc1mTcPiuPVHqYJrvEmu37NcmI
dKSC69tDrcaxcw1HivwBAoIBAQDkcmU04pucCZUzIx1uoJ1IG1jBjaVvcaxiDlu/
pamO8x+GO1bNRHQfCrkwpl92NZ1RrOLoDK3haPiNArK7hudmCihEaDbDNYhxbD/l
eoYYaUSjRqE/gu243s4VB2pWG76bmjGp5QwPZl9i1zPoJmRMKb1Uzfp7moK9O2RP
UGWMFgfCllv6AEY935GL4BXFIy/pxCA069GozQIIxs5W4BQcfZK+AqVN7sG2ATyg
gIgu8T6avMi/SvbrLUdv6oe76oOegcHee596Z1sU4Z268opBFEfb1pzxCszNKkDB
H5p7+yyczc/0sdMhQwhlC9J1xLD8ci68cVJcqzbETkQzQXU3AoIBAQC1lzgWDUiw
5gN+0FR5t7vLi78Ai7gKL6ECagqQEbE4lmhC3NhQsilhYUtzQKvD56AzPBQq2k9p
eAbLxULf+7mATcwRV0xQRwOCAkq7HclWM+25PjgRxlXMygqSAVyqlyvrvSdqnlxz
K3fo7rWxqLqkDB0V5tLZVGFtnPA1QEaRVoyJBtpMloyFrHp7mGeFM9uIpsAhhw9N
qrGTz/BI4P+d4Tnt2pyGFM/5V3s6tDR4WFeq4vYEj/2pU1BEK9wI45wFJ32u3X0l
/BfLCGTU2yvVO8h2sKT8h/ole3qP5kwnc2ASjyplev3xQGRYpvE5MHUbLH8RkdMu
XpBKOkXXoNQBAoIBAQCt9ttRSZu8WKPQvFXmb9M2HPUa9/XahxMB3PNLXylfHY+N
FdUFHbLcDLt368pYZ320u9ZTZYxoUhqsrzhSi+ndD7EYXtANGdAcp5WE+CfzoP5O
5DNY/ShwluMSqoH0rs4ZCnP1b+IePBQ5Xa4+hDXutf5i/TRZOhGDbx31NEEQS5p/
OSczm0/iQEVC4lNRu3j6KItqIYaYZ/27l0F8cMl/5LSBk9w0G7RSGGEFzLtoG/hT
t52b5sdf0ixLcqsIlA7E/wUWmseYW+rFXQZTXe2gn4QVSjpbaKELP7juGFX5Qg34
HtbU/THNa5GR+U28txscMwuaHyXcQdnD5eITsi5DAoIBABFahTKeTF8TbCwXTqtf
IqQ+E5/CunDGwnVPmvjPqAcHYKlbH5T+obO7r5ExEfkjzox25lp+CG7E2KlqjYyI
Kt8XEDRsCk/1qWEoROoC27XQOpykVIlmUdbDTCVN2gQ3dCwQJI8s2RrsgYYSIez7
efKpcbIhH+9DABiQkegU32mOQtnpfL0q+fzgUcgz9VimbwltHhlWJeE/Ob8tdQIR
9nupBXc0mBa8MG/cq1sd05HYp3AeRnKDLDOdUaNiKaHz1nornvgyFH6ny8JMaA5r
b5HuJ6coFGxJtl8UoM7VrFtszDaZ1exix5fhlnVeZtkXR2m0Y+RS8kKRKOrfDMOh
jAECggEAX5f1KbYaZkx72M3MAfKZh237bgKPuJ+a7CtgU62ZknHqnFsoNvHD1uTz
T/fxWW9xgyBX3tcaOse+PaYQliIiSu4A0HnN0sawKeFvLOIet3ushtenTgkCBbGl
c8jWcrJe3Yk0bf61Vekse+kW6GAAQffJU0/85GWbHyU71xHmpZfgm8G4rdt7iRry
ygjargCzUFzbIkKaq6ctXjlmxwp3PFYsn+65Yo4EYQ5Fsp+YYc8BvdmB/h0FC34x
+LwWzWsqBDCDqvgFS1KX1Zr3aZdCn5NejDzESj0dEf4IWqc9JLkybDbwJ26o0rgv
TNlh3K5wYBLgldBnXcy7gjTJoKP1Jw==
-----END PRIVATE KEY-----

Public key is derivative of private key:

openssl rsa -in private.key -pubout -out public.key

i.e. private key is input parameter to public key generation procedure.

Example public key file (matching the above private key):

-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAogvTFMo8oGVhgRfYPRMr
GjaeOjtDRDlEyZpZ81elpV7yqp9YIDxphcxsVAeFD0zqxXTBhq2UT8Dyz+l+1WU0
WU6xIruPKq5D/3Qjl+/VxwnICtIgU7gz4zPSmS4qL4NxI0tQq1guLMHCsVBdMKS+
0MECJXysmE4S9hT5lSH+IT1g772hGG+uAvqJ8U5alT7h5eCt72v/7V5fdrXVUfZs
61SwLJ3so+WlJUFIlYJdHk82kVBuE2FOWwvUluNOgOmwNnr9OAoa4RuaCMGuthn/
wu6OmWJ5Zq408NcjH86w8AbLsq/kSLx+mLmzPCEgK8IT0OGkDEf4qu0lgD2J0Ity
Y5EMG0VtEJiN8IBTJltzC/5Jr3ehqp/cePZ7qN8mq7bVD1ZC4bRdKQzS2NVGsF6S
dliuF9YS9cydBywkAQM2OI72Rt0xCOnC+0bnlQhO3vE8MADT1VQfSf2BIz1+idrH
/bryKpLSmibp2Q8UdrJYkxr2ciY/fvMSLLNVNJWKBDuSv14mLmt4OzwSwkntaOMN
N3VIG/5MEoJ0lmob9We84anmvntljkx+GFmNAsvjQRWENlpgXFRzSsoo/+TElYrG
0gHr2UhWPuVBI7Dohc+J8mqV6YNOKu6eVsJsVZUbkOr5Q5+w3jkokUux2LsmWbgi
Tqjto3Ttr1l9cFnY49uzATcCAwEAAQ==
-----END PUBLIC KEY-----

To encrypt a file, so it is not possible to read it without private key, you use:

openssl pkeyutl \
  -encrypt \
  -pubin \
  -inkey public.key \
  -in file.txt \
  -out file.enc \
  -pkeyopt rsa_padding_mode:oaep \
  -pkeyopt rsa_oaep_md:sha256

To decode you need your private key:

openssl pkeyutl \
  -decrypt \
  -inkey private.key \
  -in file.enc \
  -out file.txt \
  -pkeyopt rsa_padding_mode:oaep \
  -pkeyopt rsa_oaep_md:sha256

What knowledge do you have after a real life testings?

Public key must have enough information to be able one-way encode a file.

Private key has enough information to either encode and decode a file.

Public key is derivative of private key.

ps. Generated example private and public keys are base64 encoded to be readable by a human. Ask ChatGPT/Gemini how to generate binary files instead, if you want to use binary and eventually write your own RSA encryption/decryption.

6 hours ago, Trurl said:

the plain text and public key is not a one-to-one function

Public key encryption is a one-to-one function. It must be. Otherwise, it wouldn't be possible to decrypt the encrypted message. For example, the RSA (Rivest–Shamir–Adleman) cryptosystem works because prime factorisation is unique (up to order) but extremely difficult (for very large numbers). Starting from the private key it is easy to obtain the public key, but obtaining the private key from the public key is extremely difficult even though it is in principle possible to do so (by brute force).

It seems to me that you don't have a proper handle on how public key encryption works in general. Consider a two-way conversation between Alice and Bob. Alice uses Bob's public key to encrypt all of her messages to him. Bob uses his private key to decrypt all of Alice's encrypted messages. Similarly, Bob uses Alice's public key to encrypt all of his messages to her. And Alice uses her private key to decrypt all of Bob's encrypted messages. So, both Alice and Bob must each have their own public key and private key pair. Alice must somehow have access to Bob's public key, and Bob must somehow have access to Alice's public key, but neither Alice nor Bob share their private keys. Also, there is a function that inputs the plaintext message and the public key and outputs the corresponding encrypted message, as well as a function that inputs the encrypted message and the private key and outputs the corresponding decrypted message. These functions are shared between Alice and Bob so that in principle Alice and Bob do not need to use the same cryptosystem (Alice and Bob can each send their own encryption function along with their public key to the other person). The encryption and corresponding decryption function do not need to be the same function. However, one can curry the encryption function with the public key to produce another function that simply inputs the plaintext message, one can curry the decryption function with the private key to produce another function that simply inputs the encrypted message, and that these two single-input curried functions are the inverse of each other.

So, for a given cryptosystem, the curried encryption and decryption functions are each members of a one-parameter family of single-input functions. Each curried decryption function is the inverse of a corresponding curried encryption function. The parameter of the curried encryption functions is the public key, and the parameter of the corresponding curried decryption functions is the corresponding private key. Furthermore, the public key and corresponding private key must be related to each other such that the public key can be easily obtained from the private key, but the private key cannot be easily obtained from the public key, requiring that the private key be created first and the public key be obtained from that.

From the above, I think it should be clear that creating a cryptosystem is far from straightforward. Nevertheless, there are cryptosystems other than RSA, and these may have the advantage over RSA by not being vulnerable to cracking by quantum computers.

13 hours ago, Sensei said:

On Windows download VirtualBox

Note to @Trurl if you happen to be on MacOS you can run the bash commands in the terminal directly (openssl is usually preinstalled)

  • Author

Thanks guys for all the positive critiques. Sensei is right I need to get my hands dirty and get computational.

But a should note this is not my go to RSA problem. This is trying to use established ciphers to form less computational public key systems.

KJW is correct that it might be easy to encrypt such messages but may prove impossible to decrypt them.

Anyway I am working on a bunch of stuff, but here is a better explanation of what I was attempting.

Here is my reasoning why non-one-to-one ciphers lead to public key cryptography schemes:

There are 2 keys. The plain text is not known.

Take Caesar’s scytale. Alice enciphers her message with the public key. (As defined previously.) This plain text is now the cipher text. Eve has the public key but this key only is useful if Eve has the plain text because Alice is using the public key to encipher (a none one-to-one function. (This can be Gematria or other compatible non one-to-one cipher function.)

Caesar holds the private key. Just as Eve has the cipher text she does not know the shape of the scytale, the private key. This private key is the secret that went through a given number of iterations of Gematria ciphers to form the public key.,This is the foundation of this proposed one way function works. That is you can use the public key to find the private. Will cycling through Gematria enciphers be labor intensive enough to obscure the private key?

There are only 2 keys but the pubic key is used in a Gematria cipher of the plain text. That is the hack. So Eve knows the public key but the cipher text is a non one to one cipher. The cipher text becomes its own public key.

So I hope we can use the private key which is the original Gematria key before we created the public key from the private key to decipher the encrypted message from Alice.

This starts to look like the sort of post seen in physics, where someone has an idea and "just wants somebody (else) to do the math".

The answer is "no". A traditional cipher uses a key to encrypt and the same key can decrypt.

RSA is quite amazing in that anyone can use the public key to encrypt, but not decrypt, and only the private key can decrypt.

Your suggestion for generating a public key from a private key will not give a simple cipher RSA-like features.

And anyway, why do we need "less computational public key systems"?

As for the title of the thread "Can you use traditional cipher be used in public key cryptography?". Assuming @Trurl means symmetric encryption (encryption that lacks public keys) when saying "traditional" then the answer is trivially "yes". The TLS* protocol (earlier versions named SSL) uses public key encryption during handshake to communicate symmetric session keys that are more efficient for the payload traffic.

On 9/6/2026 at 9:13 PM, pzkpfw said:

And anyway, why do we need "less computational public key systems"?

Good question. One reason is edge devices with limited compute power needing secure communication, for instance battery powered devices communicating with cloud services. Looking at statistics (according to google) RSA and Elliptic Curve Cryptography (ECC/ECDSA) run nearly neck-and-neck in active internet SSL/TLS certificate usage. Without interpreting the statistics; short version: Elliptic Curve Cryptography provides same level of security as RSA with shorter keys and with less computation, a possible drawback is there may be compatibility issues with older clients.

Side note for the curious: this bash command shows the this forum supports elliptic curves:

nmap --script ssl-enum-ciphers -p 443 www.scienceforums.net

(the above may require installation on windows. Tested on macOS.)

On 9/4/2026 at 8:34 AM, KJW said:

I think it should be clear that creating a cryptosystem is far from straightforward

I totally agree. even if (and that is a huge if) the idea would provide a crypto there are other issues such as (not a complete list)
-establishing identities: How do I trust the issuer the keys? What is the identity of the sender? (everyone havs the public key). what do I do if the sender claims they did not send a message? What do I do if the private key is stolen?
-Text: focuses on text but secure communications needs encrypted traffic regardless of content; documents, images, audio, video, ...
-Language: The description does not work for different character sets

On 9/6/2026 at 5:41 AM, Trurl said:

Take Caesar’s scytale

No such thing exists as far as I know, you seem to be mixing different historical concepts. Scytale is associated with Sparta and is a transposition chipher. Caesar cipher is a substitution cipher associated with Julius Caesar.

On 9/6/2026 at 5:41 AM, Trurl said:

Here is my reasoning why non-one-to-one ciphers lead to public key cryptography schemes:

There are two possible interpretations :
1: your idea describes something that is trivial to decrypt; just by looking at the public key.
2: your idea generates some kind of a lossy encoding, not an encryption. If there is no one to one mapping between plaintext and encryption then no one, not even the intended receiver, can decrypt the message regardless of possession of public, private or both keys. This mans the idea can not be used in the context of encryption.

*) "the S in HTTPS" in layman's terms, used heavily in secure internet communication

Edited by Ghideon

  • Author

This is why I think it had potential:

The protocols have to work or the math is meaningless. The math of mapping out the Gematria ciphers through many iterations is the most difficult math of the protocol.

Taking the Gematria cipher again and again. Say 3 cycles of Gematria.

I designed it based on the fact that you need 2 private keys. Alice and Caesar’s.

To decipher the cipher text created by Alice we take the public key and the difference of Alice’ Gematria encoded cipher text and compare it to the value if Caesar’s private key as if it would have made one more iteration!

The newest post doesn't answer earlier objections, and:

15 hours ago, Trurl said:

I designed it based on the fact that you need 2 private keys. Alice and Caesar’s.

Two parties need one private key each to be able to communicate bidirectional. For sending messages in one direction then only the receiver needs their private key to decrypt incoming messages that was encrypted using the public key. Note: No-one needs someone else's private key. No-one needs two private keys*.

*) of course there are practical implementations where organisations use multiple private keys but that is out of scope for this simple case.

  • Author

Caesar has a private key.

He uses Gematria (or similar crypto scheme) to run the private key through many iterations.

A given number of iterations where the complexity is enough becomes the private key.

Alice takes her key. Which is the second private key. For her use only. She uses a cipher, say Gematria and encrypts the message according to the public key and her private key.

Caesar uses the public key and extends his private key one more iteration. This is what his cipher would look if he extended it one more time.

Caesar then subtracts the value of the extended of his private key from Alice’s private and the public key. This is Alice’s plain text.

Not a damn thing Eve can do about it.

That is the protocol. It is public key but not based on current models. I am not trying to rebuild RSA. This relies on ciphers. I used Gematria in my protocol. It needs a ciphers to work. A cipher that wasn’t public key is transformed.

It is a signal processing system. But it relies on the difference of each private key being found based on the way they react to the public key. It is a radar system.

16 hours ago, Trurl said:

Caesar has a private key.

He uses Gematria (or similar crypto scheme) to run the private key through many iterations.

A given number of iterations where the complexity is enough becomes the private key.

Caesar now have two private keys. Gematria is a concept from numerology (not cryptology). I begin to think this was posted in the wrong section…

  • Author

Don’t be deterred by the Gematria. Any strong 2 key system should work as I mentioned.

I just used Gematria in the example because it works well with the protocol.

Gematria is consider numerology but is really a cipher language.

Read the Wikipedia article. As early as 88 B.C. It was used to hide scripture in plain text. The Hebrew people could be killed sharing scripture.

I hypothesized that it did have a higher meaning to them assigning words to numbers. But remember these were intelligent people they may have disguised there ciphers as religious meaning to broaden the cipher’s skills across the believers. It is a brilliant move to spread secrets across those who share your views while preserving the cipher’s effectiveness.

Caesar in my example did not use a Caesar cipher because it is insecure. Sure he could use some type of geometry or increase his alphabet. But the Gematria a more robust, established system.

To be honest I haven’t tested the Gematria yet. I just wanted to create a protocol that would enable private keys to become public cryptography systems.

But it may turn out that Gematria is to Caesar’s protocol as Morse code is to simplify the alphabet.

4 hours ago, Trurl said:

Read the Wikipedia article. As early as 88 B.C. It was used to hide scripture in plain text.

I did read the article* and no such thing is mentioned.

4 hours ago, Trurl said:

Don’t be deterred by the Gematria. Any strong 2 key system should work as I mentioned.

I just used Gematria in the example because it works well with the protocol.

As pointed out by several members above you have no working protocol for encryption. The receiver gets a message that is ambiguous. In Gematria different texts can produce the same numerical value and this can be used to imply mysterious connections or meanings, I suggest you open a thread in religion of this is you area of interest.
In computing a related concept is "hash collision"**. Hash functions and cryptographic hash functions have many uses, for instance in relation to protecting sensitive information. There are interesting mathematical aspects better left for some other thread.


*) https://en.wikipedia.org/wiki/Gematria Edited on 26 August 2026 21:04 (utc)
**) https://en.wikipedia.org/wiki/Hash_collision

On 9/10/2026 at 12:50 PM, Trurl said:

Caesar has a private key.

He uses Gematria (or similar crypto scheme) to run the private key through many iterations.

A given number of iterations where the complexity is enough becomes the private key.

Alice takes her key. Which is the second private key. For her use only. She uses a cipher, say Gematria and encrypts the message according to the public key and her private key.

Caesar uses the public key and extends his private key one more iteration. This is what his cipher would look if he extended it one more time.

Caesar then subtracts the value of the extended of his private key from Alice’s private and the public key. This is Alice’s plain text.

Not a damn thing Eve can do about it.

That is the protocol. It is public key but not based on current models. I am not trying to rebuild RSA. This relies on ciphers. I used Gematria in my protocol. It needs a ciphers to work. A cipher that wasn’t public key is transformed.

It is a signal processing system. But it relies on the difference of each private key being found based on the way they react to the public key. It is a radar system.

Sorry, but I'm not understanding how this works. The purpose of Alice's public key is for anyone who wishes to send an encrypted message to Alice to use that key to encrypt their message before sending it to Alice. As a public key, it is not a secret and is available to everyone. But because it is Alice's public key that encrypted the message, only Alice's private key can decrypt the message. And as a private key, it is a secret known only to Alice. That is, Alice's private key is not known to the person who sent her the encrypted message, nor to anyone who intercepts this message.

For Alice to reply with an encrypted message, she would have to use the public key of the person who sent her the message to encrypt her reply. This public key is available to her because it is a public key that is not a secret.

The masterful brilliance of public key encryption is the existence of public keys that are not secret, and of course the underlying mathematics that support this existence. That is, it is the existence of keys that are not secret and can encrypt messages that allow secret communication to take place across public channels. Without effective public keys, secret communication would have to be across private channels vulnerable to interception. Note that it is the requirement of the sender to have the receiver's key that makes this key public.

Edited by KJW

If you generate private and public keys and then use the RSA algorithm without padding - that is:

openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -pubout -out public.pem
openssl pkeyutl -encrypt \
  -pubin -inkey public.pem \
  -in test.txt \
  -out encrypted.bin \
  -pkeyopt rsa_padding_mode:none

Encrypting the same text with the same public key yields the same output file; this means that very short text messages in known languages can be recovered using a brute-force method based on a dictionary of words or sentences.

A key aspect is adding a random padding:

openssl pkeyutl -encrypt \
  -pubin -inkey public.pem \
  -in test.txt \
  -out encrypted.bin \
  -pkeyopt rsa_padding_mode:oaep

Edited by Sensei

On 9/10/2026 at 4:50 AM, Trurl said:

Not a damn thing Eve can do about it.

missed that one; simple: Eve impersonates Caesar during key distribution and gives Alice Eve's public key while claiming it belongs to Caesar. Alice then encrypts using Eve's key, for which Eve has the corresponding private key. How does Alice authenticate that the public key actually belongs to Caesar?

In established public key cryptographic protocols this problem is well-known and solutions exist.

8 hours ago, Ghideon said:
  On 9/10/2026 at 12:50 PM, Trurl said:

Not a damn thing Eve can do about it.

missed that one; simple: Eve impersonates Caesar during key distribution and gives Alice Eve's public key while claiming it belongs to Caesar. Alice then encrypts using Eve's key, for which Eve has the corresponding private key. How does Alice authenticate that the public key actually belongs to Caesar?

In established public key cryptographic protocols this problem is well-known and solutions exist.

@Trurl, it should be noted that this is a separate problem to the one public key cryptography intended to solve. Public key cryptography intended to solve the problem of an eavesdropper listening in on a private communication between parties, not a man-in-the-middle attacker who intercepts and possibly alters messages between parties who believe they are communicating with each other instead of communicating with the attacker.

From reading https://en.wikipedia.org/wiki/Man-in-the-middle_attack, it appears to me that while there are approaches to solving the man-in-the-middle attacker problem, there does not appear to be solutions without their own vulnerabilities to attack. Also, solutions appear to be based on technology and protocols rather than mathematical theory, as is the case with public key cryptography.

Edited by KJW

1 hour ago, KJW said:

Public key cryptography intended to solve the problem of an eavesdropper listening in on a private communication between parties, not a man-in-the-middle attacker who intercepts and possibly alters messages between parties who believe they are communicating with each other instead of communicating with the attacker.

Good point! I could have clarified the separation. In real application of public key encryption there are complete ecosystems, Public Key Infrastructure (PKI). trurl's posts mixes cryptographic concepts (for instance encryption/decryption) and infrastructure concepts (key generation, key exchange etc). I think the following clarifies:

9 hours ago, Ghideon said:

In established public key cryptographic protocols infrastructures this problem is well-known and solutions exist.

And as you say there are other vulnerabilities related to this, beyond attacks based mathematical properties.

  • Author

You guys are right I don’t have a digital signature. You could use other systems to exchange keys. If Eve does impersonate Caesar, Caesar can add more public keys at different iterations of the key cipher.

I will work on this.

On 9/11/2026 at 11:37 AM, KJW said:

For Alice to reply with an encrypted message, she would have to use the public key of the person who sent her the message to encrypt her reply. This public key is available to her because it is a public key that is not a secret.

I am saying Alice encrypts the public key. The difference between what was just encrypted and the next iteration of the public key compared to Caesar’s secret key is the plain text.

I still have the impersonation problem, but if we can compare keys in this way the protocol should work.

On 9/11/2026 at 4:01 PM, Sensei said:

Encrypting the same text with the same public key yields the same output file; this means that very short text messages in known languages can be recovered using a brute-force method based on a dictionary of words or sentences.

You are right Sensei, this also is a problem. This is why the Caesar cipher is insecure. I know the terminology of hash, padding, a SHA, but not the actual setup. What is salting? I was under the impression that if I had the protocol and the cipher these things were already established.

By changing iterations based on Caesar’s private key you could establish impostor Eve by establishing a secure key that is secured non publicly. After this was established you have security. This digital signature is tricky and I don’t know if I can make it happen.

Wait a minute. Caesar is the recipient of the message. Eve can impersonate Alice, but Caesar would just get an incorrect plain text.

The whole point is that Caesar gives his public key and have a secure message sent to him. If you publish your public key doesn’t it mean anyone with that public key can send you a message. Even a dog turd.💩

Alice can just like Caesar publish a private key.

On 9/13/2026 at 5:51 AM, Trurl said:

What is salting?

A password salt is a unique, random string of data added to a plaintext password before it is run through a cryptographic hash function. The salt is stored together with the hashed value for (password+salt). The hash function is one-way, there is no feasible algorithm that can retrieve the original password from the hash. When logging in, the system takes the stored salt, combines it with the entered password, hashes it again, and compares this hash value to the stored hash value.

Without salt an attacker can retrieve the list of hashed passwords from a system and use a list of hashes (a "rainbow table") for common passwords and run a comparison. With salt generic precomputed tables are ineffective because each password has a unique salt so the attacker must recompute guesses separately per account.

Note that salting is about hashing, rather than reversible encryption.

On 9/13/2026 at 5:51 AM, Trurl said:

If you publish your public key doesn’t it mean anyone with that public key can send you a message.

Yes, that is the point with public key encryption.

On 9/13/2026 at 5:51 AM, Trurl said:

Even a dog turd.

Establishing the identity of the communicating parties is already an integrated part of currently established protocols and commonly used public key infrastructures.

Openssl was shown above and here is a command to verify identities, in this case www.scienceforums.net

host=www.scienceforums.net

openssl s_client \
  -connect "$host:443" \
  -servername "$host" \
  -showcerts \
  -verify_return_error \
  -verify_hostname "$host" </dev/null

For testing and education badssl.com provides intentionally incorrect settings. Example: Use the above command with the following host to see that you get a "hostname mismatch"

wrong.host.badssl.com

(I think a complete explanation of certificate chains, issuers, trusted root certificates etc is off topic here)

Edited by Ghideon

Create an account or sign in to comment

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.