Why shouldn't we create our own security schemes?

I see a lot of questions around here about custom crypto and custom security mechanisms, especially around password hashing.

With that in mind, I'm looking for a canonical answer, with the following properties:

  • Easy for a newbie to understand.
  • Clear and explicit in why rolling your own is a bad idea.
  • Provides strong examples.

Obligatory xkcd.

  • 4
    For reference, D.W. posted a great starting point here.
    – Polynomial
    Commented Aug 6, 2012 at 15:41
  • 36
    A couple people that thought they knew enough got together and created an encryption scheme called WEP for wireless networks. You can crack WEP encryption in just a few minutes. A "roll your own" methodology was used. Read about it, I'm just reminding you of this (you probably already know).
    – Everett
    Commented Aug 7, 2012 at 1:55
  • 16
    @Everett - Was WEP "roll your own"? In hindsight, yes it was weak and flawed (attacks quickly found), but it was the product of a large consortium of industry representatives creating a standard. Many of the attacks focused on WEPs small keys (and hence small and repeated IVs) (partially because strong encryption was illegal in the US for export at the time ). (I guess the industry "rolled their own" then and did it wrong again with WPA, and the WPS part of WPA2).
    – dr jimbob
    Commented Aug 7, 2012 at 5:04
  • 3
    @Ramhound I'm aware, I'm just asking the question for the sake of having a go-to answer. It'd be great if you could offer a second answer to compete with dr jimbob's.
    – Polynomial
    Commented Aug 7, 2012 at 12:32
  • 3
    That's not a security scheme, that's a system design. A security scheme is mechanism or set of mechanisms aimed at solving a single security problem, e.g. a hashing scheme, a symmetric crypto scheme. You choose which schemes to use in your system design, but you should never invent your own security schemes.
    – Polynomial
    Commented Aug 8, 2012 at 5:46

11 Answers 11


You can roll your own, but you probably will make a major security mistake if you are not an expert in security/cryptography or have had your scheme analyzed by multiple experts. I'm more willing to bet on an open-source publicly known encryption scheme that's out there for all to see and analyze. More eyes means more likely that the current version doesn't have major vulnerabilities, as opposed to something developed in-house by non-experts.

From Phil Zimmermann's (PGP creator) Introduction to Cryptography (Page 54):

When I was in college in the early 70s, I devised what I believed was a brilliant encryption scheme. A simple pseudorandom number stream was added to the plaintext stream to create ciphertext. This would seemingly thwart any frequency analysis of the ciphertext, and would be uncrackable even to the most resourceful government intelligence agencies. I felt so smug about my achievement.

Years later, I discovered this same scheme in several introductory cryptography texts and tutorial papers. How nice. Other cryptographers had thought of the same scheme. Unfortunately, the scheme was presented as a simple homework assignment on how to use elementary cryptanalytic techniques to trivially crack it. So much for my brilliant scheme.

From this humbling experience I learned how easy it is to fall into a false sense of security when devising an encryption algorithm. Most people don’t realize how fiendishly difficult it is to devise an encryption algorithm that can withstand a prolonged and determined attack by a resourceful opponent.

(This question has more discussion of the above quote.)

If you are not convinced of "Don't Roll Your Own [Cryptography/Security]", then you probably are not an expert and there are many mistakes you likely will make.

Is your application robust against:

  • Timing Attacks. E.g., to the nanoseconds do completely-bad keys and partially-bad keys take the same amount of time in the aggregate to fail? Otherwise, this timing information can be exploited to find the correct key/password.

  • Trivial Brute Force Attacks; e.g., that can be done in within seconds to years (when you worry about it being broken within a few years). Maybe your idea of security may be a 1 in a billion (1 000 000 000) chance of breaking in (what if someone with a bot net tries a few billion times?). My idea is to aim for something like 1 in ~2128 ( 34 000 000 000 000 000 000 000 000 000 000 000), which is roughly ten million billion billion times more secure and completely outside the realm of guessing your way in.

  • Attacks on user accounts in parallel; e.g., you may hash passwords with the same (or worse no) 'salt' on all password hashes in the database like what happened with the leaked LinkedIn hashes.

  • Attack any specific account trivially simply. Maybe there was a unique random salt with each simply hashed (e.g., MD5/SHA1/SHA2) password, but as you can try billions of possible passwords on any hash each second, so using common password lists, dictionary attacks, etc. it may only take an attacker seconds to crack most accounts. Use strong cryptographic hashes like bcrypt or PBKDF2 to avoid or key-strengthen regular hashes by a suitable factor (typically 10(3-8)).

  • Attacks on guessable/weak "random" numbers. Maybe you use microtime/MT-rand or too little information to seed the pseudo-random number like Debian OpenSSL did a few years back.

  • Attacks that bypass protections. Maybe you did hashing/input validation client side in web application and this was bypassed by the user altering the scripts. Or you have local application that the client tries running in a virtual machine or disassembles to reverse engineer it/alter the memory/ or otherwise cheat somehow.

  • Other attacks, including (but not attempting to be a complete list) CSRF, XSS, SQL injection, network eavesdropping, replay attacks, Man in the Middle attacks, buffer overflows, etc. Best protections very quickly summarized.

    • CSRF: require randomly generated CSRF tokens on POST actions; XSS: always validate/escape untrusted user-input before inputting into the database and displaying to user/browser.
    • SQLi: always use bound parameters and limit how many results get returned.
    • Eavesdropping: encrypt sensitive network traffic.
    • Replay: put unique one-time nonces in each transaction.
    • MitM: Web of Trust/Same as site last visited/Certificate issued by trusted CA.
    • Buffer overflows: safe programming language/libraries/executable space protection/etc).

You are only as strong as your weakest exploitable link. Also just because you aren't rolling your own scheme, doesn't mean your scheme will be secure, it's quite likely that the person who created what you rolled out was not an expert, or created an otherwise weak scheme.

  • 42
    The biggest problem I notice among beginning coders, is that they don't take security risks seriously. If I mention what kind of weaknesses some system has, the common response is rolling their eyes... The attacks are real and do happen, and if you can't even apply proper security at school then how's your application supposed to fare when it's live for hundreds of customers? :/ The only way to convince them is usually providing examples, and best of all a live demo. So if you have examples... I think it'd be a nice addition!
    – Luc
    Commented Sep 21, 2012 at 19:41
  • 74
    In other words: a scheme isn't secure until it has been extensively attacked.
    – gaborous
    Commented Jul 16, 2015 at 17:38
  • 16
    Everyone including the most experienced, mathematically well versed cryptographers can produce an encryption algorithm that they truly cannot break. And then someone else gets a look at it and finds the elephant. Commented Dec 11, 2015 at 3:26
  • 4
    Bruce Schneier has an article "Memo to the Amateur Cipher Designer". It highly discourages one's rolling one's own cipher. But this leads naturally to the thinking that everything of crypto is to be done by the experts and others should only watch what they are doing. If that's so, I like to ask why we should even take our time to watch what they do at all, since everything is taken care of for us in the best way, The experts surely have vast and profound knowledges, but there is a minute albeit non-zero probability that hints and questions of the laymen could benefit the work of the experts. Commented Apr 10, 2016 at 14:27
  • 9
    @Mok-KongShen, nobody is saying not to learn and play with cryptographic ideas. We/they are saying, don't rely on your amateur schemes being secure. If you read Bruce Schneier's article, you'll see he does recommend some positive courses of action, not just "leaving it to the experts." For example, he recommends you start with cryptanalysis, and also break existing schemes that are already broken without "peeking" at the answers. The point is, familiarize yourself with what exists before inventing new things. This is applicable to many fields of endeavor.
    – Wildcard
    Commented Sep 19, 2017 at 0:48

There is a house in my area with a really nice deck outside the second story family room. It looks swell, until you go underneath and see how it was constructed. It seems the homeowner decided he did not need to pay big bucks to a builder or architect to tell him how to build a deck. He built it himself and it looks like a chaotic spider web of 2x4’s underneath. It PROBABLY will be fine. Personally, I would rather not risk life and limb on an amateur construction job like that.

I think that if you want to develop an algorithm to do encryption, you should do so and have a good time of it. I would not recommending using it to hide your online bank statements but if you want to encrypt your girl friend’s love letters on your home computer, that should be fine—provided your wife is not a cryptanalyst.

There is a story in “The American Black Chamber”* about the Navy developing their own ciphers. The Navy would show their new cryptosystem, pleased with themselves and Yardley, the Army analyst, would promptly break the code, explaining what they had done wrong. They would offer to fix the code but Yardley pointed out that while they could fix specific weaknesses, without a solid understanding, they were going to always have a problem. Their system was intrinsically flawed. It is a little like patching a leaky roof. You can patch forever but the water is still going to find its way in. If you don’t want to get wet, the roof needs to be constructed by somebody that knows more than a little about roofs.

Did I ever tell you about the do-it-yourself brain surgery I performed on my late mother-in-law? Everything went fine until she went and died. Seriously, few of us would trust our health to an amateur doctor; do you really want to trust your secrets to amateur software? I hate to admit it but I buy a lottery ticket every few months. I fully expect to lose but the potential payout is huge. I can play the odds and maybe I will come out ahead. If I don’t, I am out a buck. Why play the odds on encryption? The payout is not there.

Regards, /Bob Bryan

  • Recommended: Herbert O. Yardley, “The American Black Chamber” -- A book as interesting today as when it was written in 1931. “The American Black Chamber was filled with good stories well told, as well as frank descriptions of Yardley's successes in cryptanalysis. It was a best-seller in 1932 -- overseas as well as domestically.” From NSA: Pearl Harbor Review - The Black Chamber
  • 9
    So basically, you are saying don't worry about security because he can leave security in the hands of others that know security. Because other people are more trustworthy with his own security. Sounds perfectly logical (insert sarcasm here). He can learn the basics of cryptography and begin building his own system. All of the best cryptographers started somewhere. Instead of giving him/her a crap story about how futile it may be as a beginner, why not, instead, ADVOCATE that they continue to learn and test and present the system to the public for testing.
    – Yokai
    Commented Apr 9, 2017 at 10:19
  • 6
    What was the problem with the do-it-yourself brain surgery? You seem to be placing it as an example of a failure, but I am unable to find the problem in the given scenario. Commented Apr 17, 2017 at 20:49
  • 6
    Especially as it was the mother-in-law
    – Aganju
    Commented Apr 18, 2017 at 11:09
  • 1
    @Yokai, I think that's what he is already saying. Roll your own crypto as a learning process, then throw it away and use something experts have been testing for years.
    – NH.
    Commented May 29, 2019 at 20:05
  • 1
    @Yokai The point of this is that you shouldn't attempt to design your own scheme for production. Experimenting on your own and trying to break the things you make (or post it online for others to try to do so) is 100% recommended and there's nothing wrong with that, but using that experiment to encrypt your customers' credit card numbers is obviously problematic. Commented Oct 5, 2021 at 20:13

Bruce Schneier wrote back in 1998:

Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break. It's not even hard. What is hard is creating an algorithm that no one else can break, even after years of analysis. And the only way to prove that is to subject the algorithm to years of analysis by the best cryptographers around.

Cory Doctorow dubbed this concept "Schneier's Law" in a 2004 speech:

Any person can invent a security system so clever that she or he can't think of how to break it.

As a follow-up, this, again from Schneier:

When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.

Phil Zimmerman also wrote in his original PGP papers:

When I was in college in the early seventies, I devised what I believed was a brilliant encryption scheme. A simple pseudorandom number stream was added to the plaintext stream to create ciphertext. This would seemingly thwart any frequency analysis of the ciphertext, and would be uncrackable even to the most resourceful Government intelligence agencies. I felt so smug about my achievement. So cock-sure.

Years later, I discovered this same scheme in several introductory cryptography texts and tutorial papers. How nice. Other cryptographers had thought of the same scheme. Unfortunately, the scheme was presented as a simple homework assignment on how to use elementary cryptanalytic techniques to trivially crack it. So much for my brilliant scheme.

  • 8
    It would be really nice to know what that "introductory cryptography text" is :)
    – ithisa
    Commented May 8, 2013 at 15:19
  • 1
    the implied answer here is that since a PRNG would produce 'random' noise, the ascii text could be subject to frequency analysis and other similar approaches? Commented Jan 9, 2017 at 23:31
  • 1
    @haventchecked I think rather that PRNGs themselves are fairly easy to crack, as discussed in this answer and its links. Commented Nov 6, 2018 at 4:18

The original post asked for an example:

The Babington Plot is a good story of a bad cryptosystem causing problems. Mary Queen of Scots was imprisoned by her cousin Queen Elizabeth I and was communicating with people on the outside via encrypted letters. The alphabet was replaced with a cryptoalphabet of squiggles, crossed circles and triangles with extra letters assigned for common letters, like e,t,i and o so the meaning of letters could not be found quickly by frequency analysis. They also added a few null characters which were ignored on the decryption to throw off analysts. The problem was that The Queen had a very competent cryptanalyst on her staff in the person of Thomas Phelippes who was able to decrypt the messages as they were intercepted.

As things progressed, Mary went along with a plot to have her escape and take over the throne. When The Queen’s agents intercepted the last letter from Mary before passing it on, they added an encrypted sentence asking for the names of those involved in the plot “so they can be properly rewarded.” Mary’s correspondent dutifully answered and The Queen’s agents had everybody involved executed.

When my kids were small, I would send them cryptograms with their lunch (with a key (using a Vernam cipher)). Generally, they were jokes but they were never of any importance. In a case like that, roll your own is fine. If you are plotting to overthrow The Queen of England (or the Shah of Iran or the slowly reforming Thug-ocracy in Myanmar), I would suggest that you make sure that what you are using cannot be easily decrypted. As Bruce Schneier said, anybody can come up with a cryptosystem they cannot decrypt, but coming up with one nobody else can decrypt is harder.


I'll give an example of something that happened here where I work. A coworker of mine was responsible for designing a password storage system (long story, don't ask) for company FTP accounts. I was asked to take over, and the first thing I saw was:

public string Encrypt(string rawText)
    // homebrew code here
public string Decrypt(string encrypted)
    // homebrew code here

I immediately ripped them out, replacing them with standard cryptographic library calls - and when I was questioned, I replied:

"You never roll your own encryption routine."

My coworker fought me on this for hours. He'd spent a lot of time on it, making it perfect, so that an attacker couldn't possibly have any way of breaking it. At one point, they even said, "This is more secure than AES256, because nobody knows how it works."

At that point, I knew two things:

  • My coworker was a perfect example of the Dunning Kruger effect (a lack of knowledge on a subject making it more likely to overestimate their own ability)
  • My coworker had to be corrected. Not just because they were "wrong", but because they were responsible for architecting other systems, and I didn't want them to keep home-brewing encryption.

So I put aside the code. And instead, I tried code-breaking the routine by simply calling the Encrypt() function and examining the output. I'm a novice - I'm not a cryptoanalyst - but it only took me 4 hours. I demonstrated the crack to them, walked them through my steps, and reiterated: Never roll your own encryption. Hopefully they'll take it to heart and never do it again.

So it boils down to:

  1. How confident you are on the security of your encryption has no bearing on how secure it actually is.
  2. Never roll your own encryption (can't be repeated often enough...)
  • 7
    Maybe you're our third-party provider? We're stuck using a program that does just this. It took me 30 minutes to decrypt all of our system's encrypted passwords (including the master password used by our third-party provider for all their clients). I then dug into their program logic and found something like 30 lines of code that basically does this: https://xkcd.com/153/. Better yet, a portion of the program (created in 2015) actually stores passwords in plaintext. Talk about security fail.
    – ctwheels
    Commented Apr 30, 2018 at 16:00

In cryptography you don't have just one opponent who attacks you in the way you expect him to. This is what makes it hard to reason about, because you have to think of absolutely EVERYTHING.

But really, nobody can possibly outsmart every possible opponent. The best we can do is utilize our common knowledge and existing research as much as possible and take baby steps to build from there, attack vector by attack vector.

This is how a lot of problems at the brink of human ability are approached, be it research in physics or playing chess on the highest level.

In theses areas you can also ignore what other people are working on and devise your own strategies and theories, and if you meet your first skilled opponent, you will be obliterated by the state of the art in more ways that you can count.

Humans are too stupid to do cryptography alone.

  • Eh, just use a one time pad. :P (Kidding.)
    – Wildcard
    Commented Sep 19, 2017 at 0:51
  • 1
    That TL;DR is one of the most quotable quotes from a SE full of quotable quotes. Commented Nov 21, 2018 at 18:34

Actually, Roll Your Own crypto, then throw it away.

As Crypto Fails calls out, it is a little harsh to say that you can't write any crypto code at all. The main problem is to not take that code and use it anywhere (in released software).

You should definitely give it a shot and use it as a learning experience. Even better if you are friends with a cryptanalyst, and can get their feedback on what you wrote. If they are worth their salt, they, too, will tell you not to use the code in real life, but they should be able to give you some information that will help you learn and grow.


It is generally impossible to guarantee that someone who designs a cryptosystem won't leave the company for which it is created, and use their knowledge of that design to the detriment of their former employer, except by designing the cryptosystem in such a way that any such knowledge an adversary may acquire could be rendered useless.

If one has a cryptosystem which is secure even against attackers who knows everything but a key, and one changes the key to a new randomly-generated value, then the system will be secure against any attackers who don't have the new key. Even if the attackers had enough information to compromise the system before the key was changed, they would be unable to break the system afterward.

Unless a system needs to protect unusually valuable data, it's probably not too hard to design a cryptosystem to be good enough that, without insider knowledge, the cost of cracking it would exceed any value that could be gained by doing so. Not because designing good crypto is easy, but because most systems aren't used to guard anything that would be of much value to an attacker (even if a skilled cryptographer could easily break a system in 58 minutes, that wouldn't be much of a risk unless the value of such information to an attacker would exceed the cost of the cryptographer's time).

Designing a system so that it can be made robust against someone with insider data, however, is much more difficult, and there are very few people with sufficient expertise to design a system that could--by changing a key--be made robust by someone who had both full inside knowledge of the design and expertise in cryptography. A cryptographic expert without insider knowledge may have to check for hundreds or thousands of potential mistakes a designer could have made, but insider knowledge may allow that person to identify and exploit a mistake immediately.


I think your question ignores important concepts.

Using your own system and depending on security of your system are two entirely different concepts.

Using your own custom code as an additional layer of defense while you use industry standard code to have industry standard security as well is fine. Using you own untested, unproven code as the only line of defense doesn't make sense.

If your code is only relevant if the attacker already cracked all your industry standard security measures and you have it as "last line of defense" you can lose nothing with that.

If your code is exposed and can have exploitable security holes? If it is your only line of defense? Now that is a stupid decision.

  • 2
    This answer adds nothing to the top four answers with ~150 combined votes. Commented Feb 9, 2016 at 0:52

I like the idea of rolling your own. Thing about mathematical/cryptographical discoveries today is that it's hard, probably impossible, to get peer review. Because it's probably as much or more work to vet whatever one comes up with as it was to come up with it. This should NOT deter the fun of exploration and discovery. Asymmetric schemes are harder, more mired in math, and have, for me, been more embarrassingly easy to break. Symmetric methods, less so. I think a good symmetric method should operate on bit (not byte or block) streams (every bit of data domino-impacting every other bit) and encrypt say 10000 0's to look completely different from an encrypted block of 9999 0's and one embedded 1 (none of the strong methods I'm aware of, e.g., rijndael, DES, etc., can do this). And if a single bit of the key, however long, is wrong, decryption should fail utterly, as in output no recognizable plain text. Nothing wrong with proprietary algorithms. Just one more hurdle for the NSA to hop.

  • 9
    Chris - I think that most standard crypto algos have been under heavy peer review. AES had a multi-year world-wide review process. SHA-3 had a similar process. Commented May 14, 2015 at 20:34
  • I wonder if the text that comes after "I think a good symmetric..." is not really relevant to the question. Commented May 14, 2015 at 20:35
  • 4
    Yes, absolutely, do lots of exploration and discovery and have lots of fun... on your own personal computer, with data you don't care about keeping secret.
    – Wildcard
    Commented Sep 19, 2017 at 0:52
  • 2
    You are incorrect regarding a single propagating bit not being doable with AES, DES, etc. What matters is the block mode of operation. Specifically, a propagating mode like PCBC will ensure that a single bit will alter the entire output.
    – forest
    Commented Feb 14, 2018 at 3:54

The example cipher Phil Zimmermann cited:

A simple pseudorandom number stream was added to the plaintext stream to create ciphertext.

is easily thwarted. Some asked why. Here is why:

  1. Step 1, feed the cipher plaintext of all 0's. Since 0 added to any number is same as the number un-changed, it completely exposes the pseudorandom number stream in the output.

  2. Step 2, given what you discover in step 1, and given the encrypted text of a secret message, you can easily calculate the original text by simple subtraction of the pseudo random number stream which you now know.

With that said, I disagree with the general notion that inventing your own cipher is almost bad. Any cipher algorithm, upon first creation, has a status of UNKNOWN security strength, even those created by experts. The experts have the advantage of being able to immediately apply typical known attacks and see how the new cipher stands, and be able to quickly rule out some inventions as weak, and amateurs do not have that ability. But it does not necessarily mean the cipher is weak. It means the strength is unknown and it may well be a very strong cipher. You just do not known.

For example I am not an expert. Here is a trivial cipher that I came up in 5 seconds without much thought:

  1. Pick a random number of 128 bits as your key.
  2. circular Rotate the key by X number of bits, Call the result value A.
  3. Circular rotate the key by Y number of bits, split it into two 64 bit parts and multiply them to produce a value B.
  4. XOR value A and B to produce a new key, use only bit 0 to bit N-1 of this key to encrypt N bit of plain text by XORing.
  5. Go back and repeat steps 2,3,4.

This seems to be simple enough, and I have not done any analysis to see how strong it is. But all I can say is this has an unknown security strength. It may well be very strong. If you immediately jump into conclusion to say it is weak or unreliable, I challenge you to come up with a method to crack it. Can you?

I think when it comes to security strength, there are only two:

  1. Unknown security strength
  2. Known weak security strength

There is no such thing as known strong security strength. If the scheme has been scrutinized a lot without finding a crack, it only means no crack has been found yet and the status remains to be unknown, and it does not necessarily mean strong, because a crack may well be discovered tomorrow.

  • 23
    This is a great example of why you shouldn't roll your own cypher: it has exactly the same weakness to chosen-plaintext attacks that Zimmermann's cypher does. Feed in a plaintext of all 0s that is at least as long as the cyphertext you are trying to decode, and you get the keystream used to encode the cyphertext. XOR that with the unknown cyphertext, and you get the original message.
    – Mark
    Commented Jul 24, 2014 at 1:09
  • 16
    Anthony - your final paragraph is correct, however your example is provably weak despite you thinking it was effective. This just helps to support the principle, which is: don't do it, unless you are an expert. And even if you were an expert, don't do it alone.
    – Rory Alsop
    Commented Jul 24, 2014 at 7:20
  • 1
    Any cipher algorithm, upon first creation, has a status of UNKNOWN security strength Not entirely true. Modern ciphers are based on a finite set of several, well-studied, well-known mathematical constructs, such as substitution-permutation networks, feistel networks, and add-rotate-xor. While in-depth scrutiny is still required, a cryptographer can, at a glance, tell that a cipher has been designed with a well-established and reliable design.
    – forest
    Commented Jan 18, 2018 at 21:31
  • 1
    @RoryAlsop Why do you say his final paragraph is correct? While that's true for ciphers, things like poly1305 are information-theoretic secure. It is "known strong".
    – forest
    Commented Jan 18, 2018 at 21:35
  • 2
    Good designs generally aren't made by mistake. Most good designs in cryptography are made with knowledge of vulnerabilities of other systems and by adding defenses or making sure the issues otherwise don't apply.
    – Macil
    Commented Jan 18, 2018 at 23:30

You must log in to answer this question.

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