> Of course, you can also do it wrong, but it is with little work possible to do it correctly.
GCHQ loves people who think this.
Have a look at some of the game console cryptography. These are companies with strong financial incentive to get it right. They're large well funded multinational organisations. They still get it wrong.
Game companies are also a great example of a situation where a large group of people with time on their hands (teenagers still in high school) are motivated to look for vulnerabilities in the method used.
Have any studies been done on relative security of crypto algorithms that are either:
a) Well known, well studied but also attractive targets for attackers to study
b) Unknown (aside from the developer) until an attacker encounters a specific piece of encrypted data
It is a common assumption that well-known methods are better (and it is the assumption I work under) but does empirical data on security breaches back that up? There are plenty of examples of security breaches where 'standard' methods were being used. Are there similar examples where people using previously unknown methods have been compromised?
GCHQ and others invest a huge amount of resources in finding vulnerabilities in well known encryption methods. When they find one, everyone who used that method is vulnerable.
I have no doubt that if they really wanted a piece of data that I had encrypted with a homemade method, they would be able to break it.
However, are they going to invest the resources to do that if I am not being specifically targeted? Are they going to invest the resources to crack hundreds of different people's home-made encryption methods? Thousands? Hundreds of thousands?
If am being specifically targeted by something like GCHQ, they will get what they want one way or another.
I'm not aware of academic studies on the subject (I think that would be hard to do, because it's virtually impossible to know how many proprietary algorithms exist, how many are trivially breakable and how many have been broken).
However, this point is featured as 101 material in basically every cryptographic textbook. To put it very succinctly: there are conditions in which it can be beneficial to use proprietary cryptography, especially when you require very unique interoperability constraints. However it is almost never a benefit for the safety of the algorithm.
I've come across a proprietary algorithm and successfully broken it, in a black box setting, with differential cryptanalysis. This algorithm was deployed to disguise the sequential order numbers for a very large delivery company. It took me about a month, but it was done. The challenge in proprietary algorithms is shifted to figuring out what's going on because it's unrecognizable. That is a significantly easier challenge that identifying a vulnerability in an algorithm like AES, which has never had a meaningful vulnerability in a decade and a half of cryptanalysis.
If you use a proprietary algorithm it might be safer than a known unsafe open algorithm, but it's virtually guaranteed to be worse than widely studied algorithms, and most likely in a trivially breakable way. They can be safe, but that still means you're going to be working with professional cryptographers at a company like Riscure to assure it's safe.
I am aware of the usual (and strong in my opinion) argument.
Every time this discussion does the rounds, though, I do wonder whether the hypothesis could be tested.
Most vulnerabilities do not come from breaking the core algorithm but rather from a flaw in how they are implemented or applied. Standardisation can lead to monocultures that become tempting targets for those with plenty of resources to throw at them.
That's what leads me to being reasonably sure the hypothesis is valid.
As a scientist, though, I'm always going to wonder whether there is a way to subject it to a proper test rather than just relying on opinion (no matter how much I respect those opinions)
It's not thought policing. Would you consider us adamantly telling you not to develop and deploy your own rockets or medical software without significant expertise and third party review to be "thought policing"?
Furthermore, your argument is fallacious. That expert professionals make mistakes does not tell you anything about the likelihood of an amateur to make a mistake. You can't draw any logical conclusion from that statement on its own.
That's great, but that's not what I'm telling you. I'm telling you not to develop and deploy them with human passengers, in a production environment, on a trip to orbit. If you get collaboration from professionals with significant expertise and audit the design and development extensively, then sure, go for it.
Even were that as accessible as developing and deploying your own cryptography, I'd still advise against it.
If you roll your own crypto and say, "that was a fun learning experience" and write a blog post about what you learned implementing AES in some novel way, nobody is going to show up and tell you not to roll your own crypto. If you roll your own crypto and then deploy it in a production system, then you are putting actual users at risk.
> There is cult around "Don't roll your own crypto" that is thought-policing
You know who else gets "thought policed"? The people who actually need to rely on cryptography. In their case it isn't grumpy people on Internet message boards telling them not to do something, it's agents of the state killing them or imprisoning them for many years.
GCHQ loves people who think this.
Have a look at some of the game console cryptography. These are companies with strong financial incentive to get it right. They're large well funded multinational organisations. They still get it wrong.