I had an idea for safely transmitting sensitive data online, and I wanted an expert opinion.

Would it be safe to encrypt data (for simplicity at this point just use plain text) with a ruleset (an array with specific instructions on how each letter should be encrypted by any means).

Of course, you can guess the ruleset. So my idea is that you keep on changing this ruleset.

The server controlling the data makes a new ruleset every time someone sends a new piece of data, the server then encrypts this with the RSA public key it was given to by a client.

The whole point is that if an attacker gets 1 - through the RSA encryption and 2 - through an equally complex custom encryption. He will only be able to receive one message before having to try the custom encryption all over again.

You could add layers to this and have multiple rulesets being sent and those same rulesets being encrypted by the previous ruleset. (For example if I have 2 rulesets, I send one ruleset encrypted just by RSA and another encrypted by both the first ruleset and RSA, and that second ruleset will decrypt the message. So a hacker would have to guess through the RSA, the first ruleset, and then the second, since only one message is the starting point of decryption.)

So more rulesets = more security. Since the hacker sees 1-An RSA encrypted ruleset, 2-A second ruleset, and 3-the triple encrypted text. He will have an 33% chance of starting to decrypt the correct message on the first try to start the chain reaction of decrypting all the messages, where the client has to try them all but with the private key, so it’s much faster than the attacker. (This is assuming the hacker was able to receive the first and second encrypted keys sent when the user first makes a connection. These keys will be abandoned once they are used one time)

With even more rulesets, there is a smaller chance the attacker guesses which message is the starting point of decryption. The keys are sent at random, so it makes it harder for the hacker to just start with the first key.

Obviously this is not fast. But my idea is that having to solve a new custom encryption method 5 times for only one specific question would be quite annoying for a hacker.

I’m not an expert on any of this, I kinda just had a thought and wanted an expert opinion on this concept.

  • 1
    $\begingroup$ Note that when a cryptographer sees "33% chance" it registers as - oh, it possibly adds ~1.6 bits of security... that's not much... $\endgroup$
    – Maarten Bodewes
    Commented Sep 2, 2023 at 10:42

1 Answer 1


TL;DR: you'll need to trust RSA or another asymmetric primitive.

What you are describing is a common idea that starting cryptographers come up with.

Both sides of course need to know the possible rule-sets and how to choose between the rule-sets given the current state. This makes the rule-sets basically "the algorithm", even if it is a very complex one.

According to Kerckhoff's principle the algorithm is the part that should not be considered secret, as that would amount to having one secret master key that nobody should be able to detect - but which invariably leaks some way or the other. Modern (symmetric) ciphers work using public algorithms and secret keys.

If we assume that the "algorithm" is known then some kind of secret information is required to choose between the rulesets given a specific state. This information then is of course considered "the key". So now there we have a more common specification for the cipher consisting of an "algorithm" and "key".

Now we need to know if there is any benefit to using this newly defined cipher. I'd argue that it is very dangerous.

Let's list some issues with the idea:

  • Probably a table of mechanisms is required; tables are considered very time sensitive allowing for side channel attacks.
  • Branching between various schemes is both very expensive and also sensitive to timing attacks.
  • The amount of complexity is probably much higher than normal ciphers, which generally use a small set of operations on purpose.
  • There needs to be a description on how the key bits are used within the various schemes and how those operations are not time-sensitive.

In the end what you're describing is a symmetric cipher with some spectacularly bad properties. For ciphers the complexity should be in the randomness of the key rather than in the algorithm description.

If you'd be using RSA with a padding scheme such as PKCS#1 or OAEP then an attacker can simply verify that the padding is correct, and all this effort would be wasted. If you'd use RSA-KEM then an attacker can still try and find the private key and try to decrypt using the resulting symmetric key.

So in the end you'll have to rely on a separate symmetric key for your scheme to work. If you've shared such a key then you'd not need RSA in the first place, making the whole idea a non-starter.

  • $\begingroup$ PS I'd think about this for a day or two before commenting. It usually takes some time for this to sink in, ask me how I know. $\endgroup$
    – Maarten Bodewes
    Commented Sep 2, 2023 at 10:39
  • $\begingroup$ Basically the way to improve this is not to send the algorithm but just the keys, and also to use some form of encryption without padding. What if I wanted to use different forms of encryption for each user, maybe before a user downloads my software, I share a list of encryption methods that the server can assign a user? $\endgroup$
    – user111164
    Commented Sep 2, 2023 at 20:06
  • $\begingroup$ Just sending some form of encryption without padding is not going to safe you, as long as you just rely on the one private key for decryption. In that case an adversary will always be able to create some kind of verification method that they guessed the correct key. If you're afraid that RSA will give way then you can derive a symmetric key based on two KEM algorithms, preferably one that is quantum safe. $\endgroup$
    – Maarten Bodewes
    Commented Sep 2, 2023 at 21:55

Your Answer

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