Anyone see any vulnerabilities with this algorithm?

Quote:

---

Yea, I had messed with XOR not too long ago, but couldn't get the *de*cryption part to work

---

Here's the code for an XOR encryption program I wrote back as a sophomore in high school. It's not great, but it works for both encryption and decryption. After you encrypt the file with it, just re-run the file through the encryption program and it should get back to normal. It's been a while (going on 7 years now) since I wrote it, but I'm pretty sure it still works (I don't have a compiler handy at the moment to test it). If you need anything explained, let me know and I'll do my best.

Code:

---

#include <stdio.h>

#define PROG_NAME "encrypt"

void usage()
{
  printf("-------------------------------\n");
  printf("Invalid command line.\n");
  printf("Usage:\n\t%s infile outfile key\n", PROG_NAME);
  printf("-------------------------------\n");
}

int main(int argc, char *argv[])
{
  int count,bytes;
  FILE *in,*out;

  if(argc < 4)
  {
    usage();
    return 0;
  }

  if ((in = fopen(argv[1], "rb")) == NULL)
    printf("Error opening %s.\n", argv[1]);

  if ((out = fopen(argv[2], "wb")) == NULL)
    printf("Error opening %s.\n", argv[2]);

  while((count = getc(in)) != EOF)
  {
    count = (count ^ *argv[3])*(count*count ^ *argv[3]);
    bytes++;
    putc(count, out);
  }

  fclose(in);
  fclose(out);
  printf("Encryption Success:\n");
  printf("\tEncrypted %s and stored data in %s.\n", argv[1],argv[2]);
  printf("\tWrote %d bytes to %s.\n", bytes,argv[2]);
  return 0;
}

---

AJ

Well, since I'm a C++ guy, and not C, a few things are a bit weird to me. But I think I get it for the most part. I'll have to compile it sometime to try it out. How do you measure the encryption on that? Is it still 8-bit, since you do one byte at a time?

To a certain point the "x-bit encryption" isn't really meaningful. I try to use it mainly to show input combinations vs. output combinations. Where known, I try to pick the lower of the two, and use that.

Here I think avdven made a mistake in his program (I haven't compiled and tested it), because it looks like it XOR's the first character of the password over and over again. Usually it would be first character of key to first character of file, and loop the key when you get to the end of it.

If you just change a line or two, it would be a good working XOR encryption program.

The way we'd toss an "x-bit strength" to it would be by taking the length of the key, which could be say 8 characters or 8 bytes, and convert it into bits. Since 1 byte is 8 bits, we get 8 * 8 or 64bits. We can then consider that file to be encrypted in a way that someone *might* have to try up to 2^64 combinations to successfully decrypt it.

In reality, however, this file could acturally be decrypted in around 2048 tries if we get to do a known-plaintext attack on it, or if we can find some pattern. 2048 is only a teenie tiny fraction of 18446744073709551616. So 64bit can be strongly misleading...


The only way to really be secure and take advantage of this as "x-bit encryption" is to encrypt totally random data. This sounds strange, but it is what RSA does. As we (probably) know, RSA is a slow a-symetric cipher. We'd never want to encrypt a 50MB file with it, because it would take a while. So how come RSA can encrypt that file so fast? The acturally pair RSA up with a fast symetric cipher (read: private key). The key is encrypted by RSA. And from there, that key decrypts a compressed version of the 50MB file. The compression to the 50MB file makes it strongly random (you can't compress random data any further) and this stregthens the private key part of RSA enough that you wouldn't want to brute force it because known-plaintext attacks won't work.

Anyways, if you want to use 64bit XOR encryption, you'd want to learn about compression algorithms so you can randomize the data and make it much harder to crack. Otherwise, the only way to really go with XOR is the One Time Pad. This is a random key that is the same length as the file you are encrypting. They'd get every possible combination for that length of a file, which makes it impossible to brute-force because you can't tell if the message said "meet me at 5 pm" or "meet me at 2 am", etc.