Take for example I have my social security and other personal information stored as a string that I am trying to encrypt on my local drive. My first method of encrypting the string is to use a password based AES algorithm, and would then simply paste the generated cipher text into a file where I can store it and decipher it later. My second method of encrypting the string is to make up my own algorithm which is much more simple -- I take that string and apply a few easy bit shifts mixed with some random bit additions, multiplications, and rotations. Later if I need to decrypt that string, I can apply the negation of my logic to attain my decrypted string.

Now that we have a string encrypted with the popular AES algorithm, and another string encrypted with my silly algorithm, they both look equally jumbled up and complex.

Now let's assume that someone wanted to decrypt my personal information, having access to the simple text file that I stored their cipher text in. The attacker does not know what kind of an algorithm I used on the ciphered text. Which cipher text is going to be harder to decrypt? Does the algorithm that I used for this scenario actually matter and why? If this was a poor example of where encryption algorithm strength may matter, could you explain a better scenario of where it would matter more?

I'm failing to see how a complex algorithm holds up better than a weaker OR self-made closed source one, since I'm assuming that an attacker will attempt to use brute force. Since I'm assuming they would attempt brute force then I'm also assuming they have no control over how random their guesses are, (possibly)rendering algorithm strength to be useless -- i.e. since both strings are jumbled up and look random, they both appear complex.

  • 1
    Take a look at: security.stackexchange.com/questions/18197/…
    – AstroDan
    Commented Jan 21, 2016 at 1:27
  • Thanks for the post. I understand the consequences of making your own algorithm and I'm not arguing that mine is better or worse. I'm simply trying to understand how it would make a difference for the specific scenario that I had posted. Commented Jan 21, 2016 at 1:45
  • See also this protected question/answer on why you should never roll your own crypto. Commented Jan 21, 2016 at 1:51
  • I regret to parrot my previous post -- I feel my question is different and requires a full read through. Commented Jan 21, 2016 at 1:55
  • Beside just saying not to roll your own crypto you should look at the concept of semantic security. This basically means given a ciphertext we cannot infer anything about the original message. If you cannot (formally) prove that your home-cooked algo is semantically secure it may leak information. Note that this is not a trivial task. Commented Jan 21, 2016 at 9:27

1 Answer 1


First and foremost rolling your own crypto is almost always a bad idea see Why shouldn't we roll our own?.

Now that that requirement is out of the way lets take a look at your question. In this case you have to ask what are you protecting against. The AES encryption (assuming that it is implemented correctly and there are no side channels) will protect your data from long term high resource attacks and from simple attacks like shoulder surfing. It should not matter if it is an attack of opportunity or a targeted attack, your data is safe.

All your home grown encryption can be counted on is a form of obfuscation. Tools like frequency analysis are very powerful. Looking like both strings are messed up is not enough. Shifting all letters in the answer makes it look all messed up. However this is trivial to break. It is normally not hard to find patterns that allow for complete decryption with only a small sample. All you can count on is resistance to shoulder surfing and unskilled attacks.

It also sounds like you have implemented both the AES and your algorithm yourself. This will likely open you up to increased risk of side channel attacks (timing, shadow copies ect.).

If you want an easy method for encryption you can use a project like KeePass or 7zip to store your data (with encryption). This way you have the benefit of a time tested and possibly open source project with strong crypto. Not to say that those attributes offer complete protection, just take a look at OpenSSL.

In the end you have to evaluate your threats and ask if you are will to settle for obfuscation or if you need full protection.

  • Thank you I really appreciate your answer. It hits what I was asking about and is pointing me to the tech that I'm curious about. You'd be surprised on how hard I had to dig to get this simple scenario that I painted, answered. Commented Jan 21, 2016 at 21:36
  • You are very welcome. You can mark the answer as accepted if it answered your question.
    – AstroDan
    Commented Jan 21, 2016 at 22:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .