# Roll your own encryption - with a twist

I am familiar with Schneier's Law:

Any person can invent a security system so clever that he or she can't imagine a way of breaking it.

I have read the many posts on this exchange littered with questions about how to write your own security algorithm, and have read the obvious responses as to why it's a terrible idea outside of a thought experiment.

This question aims to be different, though will probably be equally ignorant as all the rest. Nevertheless, I am interested in what you all have to say.

When I think of encryption, I think of it roughly like this:

``````(data) * (algo % key) = (encrypted data)
``````

in other words, take some data, add a password through an algorithm, and you get encrypted data.

But what if the algorithm itself was the password? What if you wrote a simple, small program that would modify the data you gave it, then destroyed the program after each use?

For example's sake we will keep it very simple. You have a string of words such as

``````"My name is Alice"
``````

Let's then presume you write a very, very simple program that takes this string and modifies it:

``````std::string input="My name is Alice";
std::string output;
std::string oginput;

for(char& c : input) {
output += (c + 1);
}

for(char& c : output) {
oginput+= (c - 1);
}

std::cout<<output<<std::endl;
std::cout<<oginput<<std::endl;
``````

Output:

Nz!obnf!jt!Bmjdf

My name is Alice

The Idea is simple - add 1 to each char to encrypt, subtract 1 from each char to decrypt. This kind of program is simple enough that the idea of what it does can be remembered, and is simple enough to re-implement - even if your syntax or means (functions instead) are different. Even a more complex idea, can still be simple enough to remember how to implement - even if it is a page or two of code to do so.

So if you take this algorithm in your head, write a program that modifies a chunk of data in some way, then destroy the program (let's assume the code, compiled program, obj files, etc. are not stored on the hdd or saved in any way - they are 100% gone forever).

Now you are sitting with a random blob of data `Nz!obnf!jt!Bmjdf` with no starting point to plug it into, no known algorithms to decrypt it against w/ a bunch of keys, etc. You have just taken an input, turned it into gibberish in a certain way that only you know how to reverse, and destroyed any cookie crumbs along the way.

Is this a viable form of encryption for the technically inclined? Of course this example is simple enough to crack, patterns can be found, etc. But a series of small changes to the data in a secret order, and maybe multiple iterations, add up to a lot of entropy very quickly.

• Sounds like combining "rolling your own" with "security through obscurity". – Anders Jun 15 '16 at 19:33
• I'm not a crypto expert, but the first thing that comes to mind is Kerckhoffs's principle: the algorithm shouldn't be secret. Plus, how would you use this algorithm to communicate with someone else? – A. Darwin Jun 15 '16 at 19:37
• @A.Darwin I think of this more as storing personal data in a way only the individual that stores it can access. No interest in communicating it to someone else. – RollYourOwn Jun 15 '16 at 19:41
• Ok, but how would you remember which encryption algorithm you used to encrypt a particular message? After a while, you need to write down a list, and at that point your system becomes as secure as the algorithms you chose. – A. Darwin Jun 15 '16 at 19:43
• @RollYourOwn for arguments sake is impossibly long. This is nothing more than roll your own encryption with a simple cipher. Even if you argue anything else, what you are doing is rolling your own encryption. That is never a good idea. Encryption only works when everyone knows it can't be broken easily. If anyone figures out how to break your encryption then you're up a creek. It's why we moved to having something be a seed for the encryption so that it can be different for everyone, and thus hard(almost impossible) to guess. – Robert Mennell Jun 15 '16 at 20:02

The flaw in your thinking is here:

You have just taken an input, turned it into gibberish in a certain way that only you know how to reverse...

Compare that to using a tried and true strong encryption with a long decryption key that only you know what it is.

It's possible that your algorithm is equally as secure as the tried and true algorithm, but it also might not be (and very likely is not). So why bother? In both cases something must be kept secret by you, so you gain nothing except more risk.

Moral of the story (since this comes up so often):

When you have a flat tire, you could hire a really strong guy to lift and hold your car for you while you change the tire, or you can use a tire jack.

• Haha, I like the analogy. I just felt for the extra paranoid that is afraid the NSA has a quantum computer churning away at keys for known algorithms (or more likely a farm of gpus the size of a small city), would eventually find their data cracked (if there is even a small flaw that would weaken the algorithm). If you take the algorithm away, they can't spread it across a GPU farm to try and crack a key. It's like instead of fixing your flat tire with a jack or a strong man, you abandon the car entirely and take a wormhole home instead. – RollYourOwn Jun 15 '16 at 20:27
• @RollYourOwn: it's still possible to break encryption even if you don't know anything about the encryption algorithm. Case in point - the Allies broke numerous Nazi encryption schemes in WW2 without ever having the actual hardware to analyze. That's the whole field of cryptanalysis for you :) – tonysdg Jun 15 '16 at 21:35
• @RollYourOwn Quantum computers have very little impact on symmetric ciphers like AES. They are only really scary for certain types of asymmetric cryptography like RSA and DHE. – forest Jul 30 '18 at 2:15

The algorithm in your example is basically a really simple Caesar Cipher with a fixed key (1), and no, that's definitely not secure. An attacker could determine what algorithm you used rather easily just by analyzing the ciphertext. Other schemes you might come up with could very well have similar vulnerabilities which would let a cryptanalyst reverse engineer the algorithm from the ciphertext in a similar way.

So no, rolling your own crypto isn't a good idea, regardless of what measures you take to keep the algorithm secret (including erasing it after each use).

• So this would hold true even if you added complexity beyond a simple Caesar cipher and did something such as bit-shifting and such to change every bit uniquely, but in a programmatically reversible way? Even if your sample size to test against and figure out patterns consisted only of the single blob of data? – RollYourOwn Jun 15 '16 at 20:11
• Never rely on the inability of EVERYONE ON THE PLANET (including cryptography experts and geniuses who have time on their hands) to figure out the "clever trick" you (a single person, I assume with average or slightly-above-average intelligence, and not a cryptography expert, who has other things to do), used to hide your data. If you can prove that analysis of your ciphertext is computationally infeasible, then sure, it might be OK to use on your own. But I'd guess you cannot actually write out code for something that complex in one shot, quickly, every time you need to decrypt. – Ben Jun 15 '16 at 20:32
• @RollYourOwn It sounds like you're progressing from a Caesar Cipher to a Vigenère cipher. In other words, you're moving from cryptography that was probably broken 2000 years ago to cryptography that was broken about 150 years ago. By modern standards, it's still laughably weak. – Gilles Jun 15 '16 at 20:36

It is not a viable encryption method for the technically inclined.

1) All parties that you will give the ciphertext to will need to know the encrypt/decrypt steps. This already ensures that it's not just you who knows the algorithm.

2) You will not be doing this by hand. You will need to turn your algorithm into a software product, that will be distributed amongst your users.

3) You have no control over the software package given to the users. This opens the risk of point 1).

Result 2) You have no way of knowing if someone has broken your algorithm.

• I didn't make myself clear in that this was for individual use only. No interest in giving to other people to decrypt or access or distribute. No software except what is repeatedly written from scratch again by the individual encrypting it to begin with, then its promptly destroyed. – RollYourOwn Jun 15 '16 at 20:19

Using bad, untestable encryption to send secret messages isn't the only risk of this scheme.

Like any other computer program, at one level your key becomes an algorithm that tells someone else how to compute it. Even if you were able to come up with an algorithm as good as AES (sorry, you're not), you would need a language to express it so you could share it. This language would have to be processed by the receiver in order to decrypt messages. And this language, requiring the implementation of branching logic, would be Turing-complete, and so it would be vulnerable to a whole new class of attacks that would have nothing to do with your encryption scheme!

Consider: An attacker could send a false decryption key to a victim, claiming that a legitimate message follows. The victim puts the false key in his decryption routine. The attacker sends the message, and the victim tries to decrypt it. The combination of false key and tampered message causes your decryption engine to execute enough custom rules to generate the code needed to execute an exploit, and then delivers the shellcode to provide a backdoor.