5 ms·

That thought is one reason why I've always questioned this advice: "Don't roll your own encryption." I've always understood the arguments for it but that the

That thought is one reason why I've always questioned this advice: "Don't roll your own encryption." I've always understood the arguments for it but that the advice is so widespread seemed a little counter intuitive. It always seemed, to me at least, that having millions of encryption algorithms out there would be inherently more secure than a lot of people standardized on one because the risk to any one would be so compartmentalized by comparison.

deleted 7y ago
[deleted]
ninly 7y ago
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).
- bosswipe 7y ago
  > 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.
  - Mirioron 7y ago
    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.
  - tsimionescu 7y ago
    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.
  - EthanHeilman 7y ago
    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.
  - throw0101a 7y ago
    > 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 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#Commercial_National_Security_Algorithm_Suite https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography#Comme... As are the various ECDH NIST curves that so many people are anxious about.
hadcomplained 7y ago
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.
- hadcomplained 7y ago
  For downvoters - constructive counterarguments are welcome.
  - lawnchair_larry 7y ago
    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.
    - maqp 7y ago
      "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.
maqp 7y ago
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.

deleted 7y ago

[deleted]

ninly 7y ago

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).

bosswipe 7y ago
> 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.
- Mirioron 7y ago
  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.
- tsimionescu 7y ago
  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.
- EthanHeilman 7y ago
  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.
- throw0101a 7y ago
  > 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 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#Commercial_National_Security_Algorithm_Suite https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography#Comme... As are the various ECDH NIST curves that so many people are anxious about.

hadcomplained 7y ago

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.

hadcomplained 7y ago
For downvoters - constructive counterarguments are welcome.
- lawnchair_larry 7y ago
  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.
  - maqp 7y ago
    "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.

maqp 7y ago

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.