-2

I can easily handcraft my own encryption algorithm like the following:

// make sure the private key is long enough
byte key[] = {0x3e, 0x33, 0x7e, 0x02, 0x48, 0x2a, 0x4e, ...};
byte data[] = "a string to be encrypted".getBytes("utf-8");
for (int i = 0, j = 0; i < data.length; ++i, ++j) {
    data[i] ^= key[j];
    if (j + 1 == key.length)
        j = 0;
}

With the above algorithm, if I don't give away the private key, I find no easy way of breaking the encryption(or I am too naive?), if an encryption algorithm can be created easily like this, what's the point in creating the standard? what's the benefit of using those well-known algorithms?

neevek
  • 11,760
  • 8
  • 55
  • 73

3 Answers3

3

speaking directly to your proposed algorithm, there are a couple of major problems with it:

  1. If your data is longer than your key, then it will become very easy to recover your key, because it becomes like a Vigenere Cipher.

  2. you can only use a key to encrypt a single message. Encrypting two or more messages with the same key causes the same problems that reusing the key within a message does, but even worse.

  3. Because your key has to be as long as the message to actually be secure, you have a key management nightmare. How do you store the key that is as long as the message? how do you communicate it securely to whomever wants to read it? What if you want to encrypt a 1GB file? you now need 2GB of storage for your encrypted version

  4. Your key has to be perfectly random. Any flaws in your random number generator will expose information about your message and key. Admittedly, this is an issue with algorithms like AES too, but while a bad RNG will reduce the effort to break an AES message/key, it is not nearly as bad as it would be for your scheme

Well known algorithms like AES address these sorts of issues, using short keys to get more security. a single 256 bit key can be used to encrypt a huge number of messages before it becomes unsafe to use, and managing and storing a 256 bit key is much easier than a 1GB one.

Peter Elliott
  • 3,273
  • 16
  • 30
  • Thank you, this is **the answer** I am looking for! It clearly points out defects of my algorithm, which helps me understand why it is insecure, why I should use a well-known algorithm rather than a handcrafted one. Thank you again Peter, this is really really helpful! – neevek Jan 23 '13 at 15:40
3

You use a well-known algorithm in order to not become Dave.

Schneier's Law states that "any person can invent a security system so clever that she or he can't think of how to break it."

Which basically means: an security system (encryption algorithm, authentication system, ...) can't be assumed to be secure because the creator says it's secure. Other experts on the topic must review it (and usually review it for a long time) before it can be considered secure.

Community
  • 1
  • 1
Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
1

The main benefit of using a well known algorithm is that it will be reviewed and analyzed for defects and weaknesses. If you roll your own, you don't get the benefit of community review. Moreover, it's probably almost as easy, or just as easy, to use built in encryption, depending on your platform.

I'm no expert in cryptanalysis, but something this simple probably isn't that secure.

Besides, if it were this easy, wouldn't everyone do it?

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236