Pardon me if this question seems a bit obvious, but if someone has a key to your encryption, knowing what type of encryption you are using (or running outputs against a lot of common encryption types) gives them the opportunity to reach your data using said key. So wouldn't it be better if you encrypted according to a non-standard form of encryption, hence removing the need for standards?
5
-
1$\begingroup$ Why does someone else have your key? $\endgroup$– MaeherCommented Mar 26, 2020 at 14:43
-
$\begingroup$ It doesn't matter how exactly they got it. It's a hypothetical breach of your security in this sense. $\endgroup$– yoloCommented Mar 26, 2020 at 14:55
-
2$\begingroup$ It matters a lot. You're suggesting that there is a scenario where it's probable that a key is leaked but you somehow manage to conceal an algorithm. $\endgroup$– MaeherCommented Mar 26, 2020 at 15:19
-
$\begingroup$ To quote Bruce Almighty "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." Also, see the first three paragraphs at philzimmermann.com/EN/essays/SnakeOil.html $\endgroup$– SwashbucklerCommented Mar 26, 2020 at 15:22
-
$\begingroup$ Consider this. If I was a bank, I would know what encryption method I'm using. Unless it's official, my client doesn't know what encryption I'm using, but they technically have the key. If I managed to steal the key from them, that doesn't necessarily mean I now know the method of encryption $\endgroup$– yoloCommented Mar 26, 2020 at 15:30
Add a comment
|
4 Answers
$\begingroup$
$\endgroup$
0
There are two scenarios:
you keep the algorithm completely secret. In that case the leak of the algorithm is fatal for the security it offers. If you would lose the key as well (bruteforcing is not really an option) you might think you're still secure, while you are not. Keeping one algorithm secret is very hard, which is why Kerckhoff decided against it.
you don't keep the algorithm secret, but you select the algorithm from a list of known algorithms. In that case the choice of the algorithm basically becomes part of the key. If you have 200 algorithms to chose from you've just added under 8 bits of security; that's not very much. But note that you may be able to distinguish algorithms much easier than keys; even one tiny little detectable difference would render the 8 bits useless.
Basically, in scenario 1 you have a system wide secret that cannot be leaked. In scenario 2 you don't need that, but you have a lot of complexity to deal with (all the different cipher implementations) and none of the actual advantages; increasing the key size (or just using a symmetric cipher with a 256 bit key) would be much easier and much harder to attack.
If you are asking about why we would use standardized algorithms at all then the question becomes simpler: most schemes that are devised are not secure at all, and would be easy to crypt-analyse. In the SHA-3 competition there was a scholar who decided to take part as well. This was well received, but the scheme was also immediately broken.
As Bruce Schneier has said: "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." No doubt "he" in that quote can be read as gender-neutral.
Currently the cryptographers are "winning" against the crypt-analists (usually their competitors). So it is best to take the most well studied algorithm out there that isn't broken, such as AES. For such algorithms it is most likely that nobody will try a known attack and win.
answered Mar 26, 2020 at 23:56
$\begingroup$
$\endgroup$
2
Maybe I misunderstood but it seems like you suggest hiding the encryption algorithm instead of your secret key, basically. Firstly, it is useless in any scenario that you want to send data to someone else to decrypt. If you aim to encrypt values so that only you will be able to decrypt them, think about which one is easier, hiding an algorithm from someone else or just a key?
-
$\begingroup$ I interpreted it as hiding both the key and the encryption method. $\endgroup$ Commented Mar 26, 2020 at 15:19
-
$\begingroup$
$\endgroup$
[...], but if someone has a key to your encryption, knowing what type of encryption you are using (or running outputs against a lot of common encryption types) gives them the opportunity to reach your data using said key.
Hiding the key
The important thing is, that you hide the key. This goes all the way back to Kerckhoffs's principle: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.
His second design principle is most relevant to your question:
It [the algorithm] should not require secrecy, and it should not be a problem if it falls into enemy hands.
Keeping an algorithm secret is considered bad practice. You might think that you're algorithm is secure, meaning that it's secure against any attacks, but it's usually the opposite. That is basically (Bruce) Schneier's law:
"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."
- Bruce Schneier, 1998
A cryptographic standard is only established (or considered secure) after a thorough and intensive phase of trying to break said standard.
Using standards can give you reassurance that the system is secure against anyone that doesn't know the key.
Hiding the algorithm and the key
Keeping the key hidden as well as hiding the encryption algorithm would give you a further problem: You might want to send data to anyone over some channel and you wish to keep this data secret in transmission. So you encrypt it with you're secret algorithm. But now the receiver doesn't know how to decrypt the data. This is similar to the problem of a key exchange.
answered Mar 26, 2020 at 15:48
$\begingroup$
$\endgroup$
It is moderately common for companies, and sometimes even standards bodies as in the case of the CSS encryption on DVDs, to keep the inner workings of a system secret. Some argue this "security by obscurity" makes the product safer and less vulnerable to attack. A counter-argument is that keeping the innards secret may improve security in the short term, but in the long run, only systems that have been published and analyzed should be trusted.
Hiding security vulnerabilities in algorithms, software, and/or hardware decreases the likelihood they will be repaired and increases the likelihood that they can and will be exploited. Discouraging or outlawing discussion of weaknesses and vulnerabilities is extremely dangerous and deleterious to the security of computer systems, the network, and its citizens.
The long history of cryptography and cryptoanalysis has shown time and time again that open discussion and analysis of algorithms exposes weaknesses not thought of by the original authors, and thereby leads to better and more secure algorithms. As Kerckhoff noted about cipher systems in 1883 [Kerc83], "the system must not require secrecy and must be able to be stolen by the enemy without causing trouble."
Short answer: the security of a cryptosystem should only depend on the key.
