Homebrewing something like SSL

Question

So me and eight other friends have founded a "company" (not official, we just like calling ourselves that) named sDev and we are making a strategy game. We are aged 16-17 and have about 3-5 years of experience coding, mainly from school lessons. So much for the context of this question

As for network communication in our game we have made the (rather sensible) decision to use encrypred traffic; the group agrees on this. The way of doing this? Thats where our views differ. Most of us agree that it would be beneficial for us to use a prefabricated security library (the only one any of us knows is SSL) while our enthusiastic (in a good sense) colleague martin is in favor of an alternative.

Martin thinks it would be good for us to make our own SSL for a number of reasons:

• compile time
• repo size
• we only code the stuff we need
• experience
• license stuff
• it would be cool

Side note, at this point martins idea of making our own SSL has become a meme. While we can identify with his views there are a few issues I see in this, mainly the fact that I would not want to have the responsibility for our potential clients' security. A number of us would also be troubled with the task of finding the motivation to learn and implement RSA, AES and whatnot else you need. My greatest concern though is that missing a simple if check can ruin the whole thing (best example, heartbleed) and I don't trust myself or the team to code such a perfect piece of software that can match the performance and security of SSL (not that I have trust issues). If we already have this beautiful library with years of effort and a strong competent team behind it that is also open and has a very kind license for us to use, why risk making our own?

So here to my actual question to some people that are more into the field:

How beneficial would making our own SSL really be, how risky is it if we mess up and how valid are the arguments for either side?

By the way, Martin will be shown this question in the near future

Answer 1

TL;DR: I don't really find any points that are positive to enroll your own Security. You can try to implement the Basic concepts of SSL in some dummy application to learn how it works but beside that you shouldn't even consider that to use it in Productive. For your own sake and for that of every user that should use your application.

Beside the Point of "don't roll your own" (which is always an argument that kills the need of a own implementation because a "normal" developer can't develop it correctly) according to Martin's points:

• compile time -> you won't compile the entire SSL Library, you will use it. So use an external one is faster than your own
• repo size -> you use the Library, your own implementation would be much bigger
• we only code the stuff we need -> you do exactly that ;)
• experience -> ok, you will learn the basics of SSL. But if you then program something which is broken in the beginning and you think that this code is correct, you will learn something wrong and thinking it is correct. That is much worse then learn how to use a well known library
• license stuff -> yes you maybe must put some text in your application that says you use that library. But then go to different big applications (example may be Android OS) and go to their License Part. You will (if it use SSL) always see the openSSL library license text there
• it would be cool -> what is cool on build something that is not good ;)

Additional: Always try to use Libraries that are well know. You don't need to fix bugs inside of them, they are reviewed by more eyes you could afford and bugs are much faster found than in your code (your 10 000 user vs. their 1 million users as example). Further more are well know Security Libraries very often checked by Experts that know what they doing ;)

The best code is that one you don't write.

Answer 2

@Serverfrog hit many of the points, but the only valid reason to write your own encryption protocol today would be to learn from the experience.

The problem with writing your own is that you can't see its flaws. Schnier once glibly said "Anyone can create an encryption algorithm that they can't break." The same is true for protocols. So please don't feel bad, because this is a well understood problem in cryptographic protocol development.

One problem is that you are unaware of all the security problems that have plagued all the previous encryption tunnels, and you simply don't know all the vulnerabilities that you would have to defend against. For example, did you know that if you don't code your encryption algorithm perfectly, it can leak information that you can't even see? An attacker can send thousands of encrypted requests at your machine, time the responses, and use variations in the timing to learn bits of your secret keys. Or if you encrypt compressed messages, an attacker can measure the length of the responses to extract the contents of a message? Do you know why the world is using TLS 1.2, why researchers are working on TLS 1.3, and what happened to TLS 1.1, TLS 1.0, SSLv3, SSLv2, and SSLv1? And those are just a few examples of the hundreds of flaws that have been found.

The history of cryptography is littered with hundreds of painful, expensive, and sometimes fatal lessons in how attackers can discover new flaws and exploit them; even though the leading scholars and experts in the field never found them despite years of searching.

If you go forward, what experts do you have lined up to study your cryptographic protocols for weaknesses? Where are these scholars who are going to write their master's thesis on your protocols, proving there are no hidden flaws? Worst case, your crypto will work against some simple attackers until you have a lot of success, which is the worst possible time for them to attack you.

Let's imagine your game becomes wildly successful - World of Warcraft successful. Millions of customers from around the globe are spending hundreds of millions of dollars on in-game purchases, and you're all rolling in money like Scrooge McDuck. That's a lot of money, and the more money you have, the more powerfully it motivates thieves to steal it. One day you get to work and discover someone's broken your crypto, stolen every artifact from every customer, figured out how to issue themselves 10 billion untraceable gold pieces, stolen credit card numbers and passwords from your customer databases, and they've trashed your in-game economy. Your company's reputation is in ruins. Is a home-brewed protocol worth the risk?