The "don't roll your own" argument isn't against having lots of encryption algorithms, though. It's because it's nearly impossible for a nonspecialist to implement tools that other specialists can't fairly easily recognize as broken and exploit (whether cryptologically broken or due to side-channel exploits).

> other specialists can't fairly easily recognize as broken and exploit

Is there any supporting evidence for this claim? If I took an AES library and changed the order of some inner loop wouldn't it require extensive statistical analysis to notice the difference? Which means instead of throwing a bunch of compute at decrypting me, along with the masses 10 years from now, you would need to get a specialist to specifically target me and spend considerable time.

Maybe it would be safe, but there would be a decent chance you would accidentally mess up sometime simple and makee the algorithm trivial to decrypt. How do I know? I've experimented with variants of hash functions and seen that happen.

IIRC Groestl if you switch the inputs between the P and Q functions you'll introduce fixed points ino Groestl. Or take your example of AES, if you changed AES such that the loop which ran shift rows and increase it to run four times, you'd massively damage diffusion and probably have a trivially breakable block cipher. Modern cryptographic primitives are very carefully built, minor changes can be disastrous.

I've wondered this as well. Are there tools that will automatically run through all kinds of existing cryptographic algorithms to figure out which ones you're dealing with? Because it sounds to me like throwing enough layers of shoddy algorithms would obfuscate things enough that somebody would actually have to look at it and try to explicitly figure out a way to bypass what you're doing.

There's also a good chance that your change would break some assumptions/guarantees of AES, perhaps fatally (e.g. the result could be that your result only depends on just a few bits of the key).

True, if your threat model is exclusively future untargetted attacks ,your algorithm may be safer,but that is not a commonly accepted threat model I think, even for terrorists or banks.

> If I took an AES library and changed the order of some inner loop wouldn't it require extensive statistical analysis to notice the difference?

Unless you knew why it was organized the way it is in the original spec, altering it may weaken it. The DES S-boxes were altered by the NSA and everyone was suspicious, but it turns out they had made things stronger:

* https://en.wikipedia.org/wiki/Differential_cryptanalysis

Turns out the NSA was (at the time) over a decade ahead in crypto knowledge than the public.

As it stands, AES is approved for even TOP SECRET labelled information:

* https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography#Comme...

As are the various ECDH NIST curves that so many people are anxious about.

having millions of encryption algorithms out there would be inherently more secure than a lot of people standardized on one

Enclosing letters in paper the thickness of which has a million variations doesn't mean one of them is magically more secure than one made from two inch thick steel. The point of encryption is it's a standard that needs to be interoperable. Also, NSAs of this world aren't breaking modern ciphers. They're circumventing encryption by going for the keys: There's three choices

1) If communication system uses TLS-encryption (e.g. Telegram cloud messages), there's no need to break encryption, just hack server and read messages from there.

2) If the system uses E2EE where user has no way to verify fingerprints (e.g. iMessage, Confide), compromise the server legally or by hacking it, and perform undetectable MITM attacks.

3) If the system uses E2EE where fingerprints can be verified, hack the user's endpoint to steal their private keys and perform undetectable MITM attack (or just steal their chat logs or take screenshots).

So, to sum it up, the game when modern ciphers are used, is not with cipher security, but everything else around it.

I agree with the sentiment. The common argument against rolling out your own encryption just baffles me. Because there are plenty of ways to roll out your own encryption safely and in such a way that drastically eliminates the possibility of getting broken. Following is just a few ideas easily implemented even by a mediocre engineer.

For the easiest, you can just apply multiple encryption algorithms in succession (of course with different keys). Although the algorithm of AES is considered safe, it can be broken through a side-channel such as a backdoor, which secretly stores keys used somewhere. But if you apply another algorithm after AES, be it ChaCha20 or Blowfish, it can only gets reinforced.

Another trivial way to safely roll out your own encryption is to increase the number of rounds in ciphers that are considered safe. The increased number of rounds only strengthen the algorithm. And it's just changing a few magic numbers in the source code - you can get extra security for little expense of time.

Both methods provide esay-to-implement ways to safely 'invent' a new encryption algorithm without a proper knowledge of cryptography. If people start doing any of the above regularly, it would be a headache for those enjoying to exploit vulnerabilities in common crypto implementations.

This isn't really "roll your own". This is "run with non-standard parameters". This is a much smaller footgun, though you can really screw this up.

World experts in practical crypto regularly ship implementations that have serious errors that remain undetected by other world experts for years. This shit is hard.

To support both sides on this one, you could roll your own crypto on top of a third party crypto like AES. That way you get the benefits of both: You have the tried and true AES backing you up if your custom crypto is cracked, and you get security and obfuscation benefits from rolling your own crypto.

For downvoters - constructive counterarguments are welcome.

I don’t mean to be rude, but it’s quite obvious by what you wrote that you are barely literate in cryptography, yet you are fairly certain of yourself. Your confidence is misplaced. This isn’t the type of thing that encourages actual experts to bother replying.

Examples: “side channel such as a backdoor that secretly stores keys used somewhere”, “blowfish”, nonsensical mixing of block ciphers and stream ciphers without regard for the complete construction or the implementation (by far the largest weak point), etc.

"by far the largest weak point"

Well, if the nested ciphers are all properly implemented AEAD schemes, use unique keys, and don't rely on public key crypto for key exchange, cascading crypto is fine.

Other than that their discourse was that of a novice, sure.

Combining standard algorithms doesn't constitute rolling your own crypto. Arguably, even increasing the number of rounds in a standard cipher doesn't, either.

A back door is not a side channel.

Rolling one's own crypto has become a catch-all phrase. It's of course very important to remember implementing standard algorithms in non-standard way can be incredibly dangerous too. I've seen unauthenticated AES-CBC way too many times. I've seen fingerprints calculated by hashing pre-master secrets (completely insecure), I've seen crypto libraries that rely on completely insecure structures for their RNGs (worst was probably LCG fed from math.random). I've seen fixed IVs with fixed keys, E2EE without fingerprints (way too often), ones with expired primitives (SHA-1 in PGP). I've seen RSA PKCS #1.5 deployed in brand new products (https://trailofbits.files.wordpress.com/2019/07/image13-1.pn...).

So the correct advice is, "don't deviate from best practices, and hire a cryptographer."