10

On almost any website that relates information about cryptography in general there is this common notion that almost all encryption/decryption algorithms should use a key as one of their inputs. The reason behind this is that encryption algorithms that don't use a key are technically useless.

Because of this I cannot help but wonder how they came to that conclusion. Why is it that the common trend in cryptography is to keep the security key a secret but allow the encryption and decryption algorithms to be public. What if both the encryption and decryption algorithms were the secret? In that case there would be no need for a key anymore and it would simplify things a great deal.

For example: suppose I am a software developer that wants to send textual messages from one computer to another (and back) to allow communication (a simple chat app). Suppose the computers are communicating with each other over an insecure network with the TCP/IP protocol. Suppose that I want to ensure their conversation some privacy and come up with this very basic "encryption" algorithm in which I simply add 10 to each ASCII code for each letter in the plaintext before sending it as raw bytes over the network. As such a message such as "Hello, brother!" would be intercepted by any attacker as "Rovvy6*l|y~ro|+".

How can anyone intercepting the message reconstruct the original plaintext if they had no knowledge of either the encryption or decryption algorithms? What would be the best approach to breaking this cryptosystem? Is it really that easy to somehow break encryption schemes that don't use keys, that they are not viable solutions?

Finally, if you want to say something like "Well....you don't need a genius to figure out that you're just adding 10 to each byte of the plaintext", I did that for simplicity's sake. If you want to make the message even more cryptic then feel free to imagine the mathematical formula being a lot more complex (such as adding 7 then subtracting 10 and then multiplying by 2).

Steve Dodier-Lazaro
  • 6,828
  • 29
  • 45
Mr Sir
  • 175
  • 1
  • 5
  • 2
    You may find https://crypto.stackexchange.com/ provides a different viewpoint. Cryptanalysis is a focus of that site. – Neil Smithline Jun 11 '15 at 03:28
  • 8
    How do you distribute your algorithm if it has to be a secret? – Elliot Gorokhovsky Jun 11 '15 at 03:39
  • I didn't plan to distribute it in source code format....just send the necessary binaries in a secure way to the other computers and have them use them as is. Something like a proprietary software used by a single company or something – Mr Sir Jun 11 '15 at 06:44
  • 15
    Compiled source is decompilable. Even obfuscated code is de-obfuscationable (which is a word I don't get to use often). If someone wants to, you won't be able to stop them (without physically) reverse engineering your code. – Chris Murray Jun 11 '15 at 11:20
  • 6
    @ChrisMurray That's because the word should be *de-obfuscatable* (the verb is "obfuscate", not "obfuscation"). – cpast Jun 11 '15 at 13:22
  • 2
    Also, don't forget that many systems have multiple users. This makes many of the naïve cryptography solutions pretty much worthless - if you can control the plain-text being sent, you'll be able to discern the encryption mechanism pretty fast. Making an algorithm strong enough to prevent this is rather tricky, and you still need to have multiple different keys for the different users - you wouldn't want everyone to encrypt / decrypt each others' communication, would you? Try googling for "security through obscurity" - it's a lot of fun. – Luaan Jun 11 '15 at 13:48
  • 6
    Please, please read about [Kerckhoffs's law](http://en.wikipedia.org/wiki/Kerckhoffs's_principle). Then start your question over. – AviD Jun 11 '15 at 13:52
  • 2
    Knowing the internal workings of an algorithm and still not being able to crack the encryption that it creates is one of the key aspects that makes the algorithm of high quality. That is why it happens very, very often that once released into the public a previously kept in secrecy algorithm is cracked almost instantly because the algorithm itself was not that good but used the advantage of obscurity. Also an algorithm can usually be improved and if you keep it in secret you are the only one who can do that -> less expertise hence poorer results. – rbaleksandar Jun 11 '15 at 14:34
  • Sometimes secrets leak. When they do you need to change them. Keys are much easier to change once they have leaked than algorithms. – kasperd Jun 14 '15 at 14:29
  • The most simplest answer to your question would be that unless you are sending messages from one computer to another computer to *yourself*, then your algorithm is not really secret. Why? Well because you know it so as a user of your chat, I would not use it because you can decipher my messages. Finally, even if this was used by only you and someone *sniffed* the data, using cryptanalysis, as others pointed out, they can probably decipher it in a short time. – CodingYoshi Nov 14 '21 at 16:59

6 Answers6

33

We don't just want secrecy. We want quantifiable secrecy. The point is not only to ensure confidentiality of data, but also to be able to know that we indeed ensured confidentiality of data.

When we have a public algorithm and a secret key, secrecy can be quantified. For instance, if we use AES with a 128-bit key, then we know that an attacker will have to try an average of 2127 possible keys (i.e. way too many to actually do it) to find the right one.

If instead we tried to use a secret algorithm, then we would face three big challenges:

  • As @Xander explains, making a secure encryption algorithm is awfully hard. The only known method which offers some decent reliability is public design: publish the algorithm, let loose hundreds of cryptographers on it, and see if they can find something wrong in it. If, after a couple of years, none of them found anything bad in the algorithm, then it is probably not too weak. With a secret algorithm, you have to do all that cross-review work yourself, which is not feasible in any decent amount of time.

  • We do not know how many "decent encryption algorithms" can exist. An attacker may try to enumerate the possible algorithms, were "possible" means "that which the designer may have come up with". Part of the issue is in the realm of psychology, so quantification will be hard.

  • A secret algorithm still exists as source code on some computer, compiled binaries on some others, and in the head of at least one designer. Unless all the involved development computers and the designer's corpse were dissolved in a big acid cauldron, it is very hard to prevent that "secret algorithm" from leaking everywhere. On the other hand, a secret key is a small element that can be more efficiently managed and kept secret (stored in RAM only, possibly rebuilt from a key exchange algorithm like Diffie-Hellman...).

Since the algorithm will probably leak, you may as well consider it public and rely only on the secrecy of the key. By actually making the algorithm public, you may then benefit from extended review by other people, which is an almost unavoidable precondition for achieving security.

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • The mode matters as well, side channels on the mode can and has weakened strong algorithms – jas- Jun 11 '15 at 01:26
  • 3
    Regarding your third point, it's easier to replace a key than an algorithm. So if you suspect that a key is compromised you can just select a different key. In fact you can do this even if you have no reason to suspect that the key is compromised, switch keys every year or month and you limit the impact of any future leak. Switching encryption algorithm every year would be very difficult. – Taemyr Jun 11 '15 at 13:39
17

There are a couple of things to consider.

First, coming up with a secure encryption algorithm is hard. Not kind of hard, but really mind-bendingly hard in that we can't actually prove that encryption algorithms are actually secure, but only demonstrate that with what we know, we don't know how to break them with effort of less than 2^n for some large value of n. And so, the only way to be reasonably sure that there aren't disastrous flaws in an algorithm (and there are in virtually all algorithms designed by amateurs, and many designed by professionals) is to subject them to rigorous peer review by qualified people. So, if an algorithm is vetted, it cannot, by definition be secret. If it is not vetted on the other hand, it cannot by any reasonable measure be considered to be secure.

Second, there is the practical matter of long term secrecy. If you did rely only on the algorithm for secrecy, you run the risk of needing to change the algorithm should it be uncovered. That is hard, and involves modifying every single implementation of the algorithm, which is expensive and disruptive. If the key is the only secret, keys can be changed cheaply and easily, which makes key-based schemes much more attractive.

Ultimately, modern cryptography is based on Kerckhoffs's principle which states that: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. This is because with the knowledge that we have, this is really the only reasonable way to approach serious, secure cryptosystem design.

Xander
  • 35,616
  • 27
  • 114
  • 141
  • 1
    Also worth mentioning Schneier's Law, in the context of how hard it is do design a secure algorithm: Anyone can build an encryption algorithm so clever that he or she can't imagine a way of breaking it. – AviD Jun 11 '15 at 13:55
0

The scheme that you've proposed uses basic substitution. The mapping, however complicated is ( 7 - 10 ) * 2 = -6. So using frequency analysis on the ciphertext would provide the plaintext. Right now, the string you're using is too short for any analysis, but given time, the surfeit of data using the same scheme will provide the means to obtain the plaintext.

Once along this path, you might want to consider how the ciphertext is generated if the function is changed, like every 12th letter, or every 18th letter, just to confound the frequency distribution of the ciphertext. Eventually you'll encounter the enigma enc/decoders used during the world war. And very soon after, the use of Diffie-Hellman to securely negotiate a shared key in public. DH is the cornerstone by which public key negotiations are handled on the internet. A rather interesting development, since the key used to initialise the enigma machines required someone to transmit the key in the first place. A tricky thing to do amidst the fighting. With that, the chicken and egg problem was solved.

Now if only the certificate authorities can get a grip on the number of second tier CAs then everything would be better.

Bruno Rohée
  • 5,351
  • 28
  • 39
munchkin
  • 393
  • 1
  • 5
  • This question isn't so much about the specific algorithm proposed, as it is about the general concept of key secrecy vs. algorithm secrecy. To answer more appropriately, you should assume the algorithm is reasonably secure (or provide argument for why *all* algorithms developed in secret cannot be considered reasonably secure) and work from there. – Iszi Jun 11 '15 at 13:50
  • Well the original question, though now edited to reflect the interpretation as a question about the secrecy of algorithm, should probably be understood as a question about how cryptography works from a person without any knowledge about the evolution of cryptography. My answer reflects this. The implementation details, initialisation vectors, s boxes, key modulus length, diffie helman key exchanges in detail, PEM, x509 certs are better explored in a more specific fashion. – munchkin Jun 12 '15 at 07:15
0

A less academic answer:

Imagine you're the government of some country. Imagine that you've hired people to design this awesome new crypto algorithm, and you've hired people to build machines that implement it, and you've outfitted all of your ships and airplanes and mobile command centers and embassies and offices and... with it.

And then your enemy captures one of the machines, or your enemy turns one of the people who built the machines, or...

Which is easier? Design a new algorithm, design new machines and replace them all? Or change the key?

honker
  • 1
  • 1
0

It may be helpful to think of something like DES not as being an algorithm, but rather as an algorithm generator which, given 56 bits, will yield one of 2^56 encryption algorithms, most of which are about equally strong; newer schemes like AES can generate 2^128 or more algorithms, all of which are strong. Designing a secure encryption algorithm from scratch is extremely hard; taking a secure algorithm and turning it into an "algorithm generator" which can generate a huge number of secure algorithms is, by comparison, much easier. Given a choice between hiring some expert to design an encryption algorithm from scratch at a cost of tends of thousands of dollars or more, or throwing a few dice and using the results as a "key" for some other "algorithm generator", the latter is not only vastly easier and more for most users of cryptography, it also avoids the need for them to trust an outsider with their secrecy. If someone rolls some physical dice and uses the results to generate a key used to secure secret information for his own use, and if he would be would not want anyone to ever be able to decode his secrets, there's no need for him to ever let any other person or group of individuals possess knowledge sufficient to do so.

supercat
  • 2,049
  • 11
  • 10
0

Well, how many algorithms can you imagine? Keep in mind that they shouldn't rely on a key to be different otherwise you are using keys.

How many don't share a way to attack? E.g. replace x with x+10 and replace x with k[d] are both vulnerable to a letter frequency attack.

How many are not the equivalent of 123456 and password i.e. won't be in the list of top algorithms to check?

Are there enough to make it too slow for someone to check all of them?

Thanos Tintinidis
  • 159
  • 3