Encryption and C++

First, I am really sorry for having to post this. Second, this is for legal means nothing bad. Now onto the meat of the post.

How hard would it be to write my own encryption code? Also how would I go about doing it. I am trying to make my own orignal code, I don’t trust anyone elses. I am rather proficient in C++, but people keep on explaining that it has to do with hexadecimal and prime numbers. A routine search on google brings back companies selling encryption for C++, bummer. I even got out of my chair and went to the library. It wasn’t very helpful. The vast majority of the books were about WWII and the history of cryptography. So if anyone has it in the goodness in their heart, respond away. Thanks!

It all depends on how good of an encryption method you want. The RSA algorithm can be found through google, and if you’re not trying to encrypt anything securely, you can use it. Of course, if you can come up with a method to use 128 bit primes, you can also encrypt things securely.

I just finished writing a bunch of encryption code in C++, so sure it can be done.

What kind of encryption do you need? For what purpose? There are a million different forms of ‘encryption’. There are message digest algorithmns like SH-1 and MD-5 that are used to make digital signatures, there are a zillion different Ciphers floating around, most based on Feistel networks.

Here’s a simple routine, written in the C language, for encoding with key k[0] - k[3]. Data in v[0] and v[1].


void code(long* v, long* k)
{
  unsigned long y=v[0],z=v[1], sum=0,   /* set up */
  delta=0x9e3779b9, n=32 ;             /* a key schedule constant */
  while (n-->0) {                       /* basic cycle start */
    sum += delta;
    y += (z<<4)+k[0] ^ z+sum ^ (z>>5)+k[1];
    z += (y<<4)+k[2] ^ y+sum ^ (y>>5)+k[3];   /* end cycle */
  }
  v[0]=y ; v[1]=z;
}

That chunk of code is called TEA, or Tiny Encryption Algorithm. You can read more about it here: http://www.vader.brad.ac.uk/tea/tea.shtml

There are plenty of public domain encryption algorithms around, and I recommend that unless you are a serious math student you don’t try to write your own.

Argh, Sam Stone you are making tell more than I wanted to. I am writing a paper on Encryption for a math competition that I am competing. It was my goal to make a simple and maybe even kinda effective piece of code. I consider myself pretty serious, I also, if necessary, have the help of two very able math teachers, but I hate to bother them. I understood all the code except the delta part. Thanks again for you help.

Are you trying to develop your own implementation of an existing encryption algorithm or come up with your own algorithm?

If you’re trying to implement something existing, you can get sample code from open source projects like Cryptix (http://www.cryptix.org/) (mostly Java)
and Crypto++ (http://www.eskimo.com/~weidai/cryptlib.html). These would at least show you how to code various techniques.

If you’re trying to come up with something new, then the above samples might at least demonstrate how you handle different functions like bit shifting and key scheduling. You can code up pretty much anything you can think of using C++.

Not to discourage you, but be advised that crypto is Hard with a capital-H. It fairly easy for a decent coder to gin up an implementation of an algorithm and try to optimize it, but to actually design a new secure algorithm takes a tremendous amount of math and skill. Many new designs are cracked within moments of release, and algorithms have to get banged on very hard by lots of experts before anyone accepts them as useful. Witness the recent NIST competition to select an “Advanced Encryption Standard” (AES). Many teams submitted and world-renowned mathematicians picked them apart for months before settling on one to be the new standard. Good cryptographers spend a lot of time breaking algorithms and some of their techniques boggle my mind (no mean feat).

Just a note of etiquette if you’re designing a new system: don’t post a short encrypted string and challenge people to crack it. All trusted cryptography is open for inspection (if not the code itself, at least the algorithm) and “security by obscurity” is an industry joke. If you want to be taken seriously, post details of your technique on a forum like Usenet’s sci.crypt and ask for feedback.

The book Applied Cryptography is a very good primer to cryptography. It will introduce you to many different kinds of algorithms (symmetric, public key, MAC, etc.) with both pseudocode and C code. It also talks about the basics of cryptoanalysis and code breaking. I recommend it highly if you’re interested in the field. You might also check out the FAQ for the Usenet group sci.crypt; it’s a very good resource.

Neglected to mention that my book recommendation was for Applied Cryptography by Bruce Schneier.

There’s another good one, Handbook of Applied Cryptography by Menezes et al. which is excellent, but much heavier on the math. Schneier’s book is a must-read if you’re playing with crypto.

I’ll second Micco’s book recommendations.

It might help if you could tell us just what level of math you are capable of. Are you a high school student, or a university math major, or what?

If you are writing a high-school level paper, then you aren’t going to have the math skill to build an encryption algorithm that is truly secure, and you would be better off trying to apply an existing algorithm to a new application, or to do an overview of techniques. For example, you could do a paper on Feistel ciphers in general, and explain what makes that class of cipher tough to crack.

Or, you could take a specific application of encryption and work on that. For example, you could explain why high entropy is required for a good hashing algorithm, and/or why good message digests cannot be reverse-engineered. Then write some code to demonstrate a good hash, and show how the output changes drastically with small changes to the input.

Another angle would be to tackle pseudo-randomness and all the various difficulties in creating ‘random’ numbers in a computer that are unpredictable. Then demonstrate the concept by coming up with a random-number generator of your own design that means some specifications you set up beforehand.

I’d like to recommend a book at the other end of the spectrum, The Code Book, by Simon Singh. It’s a general overview of encryption on a very basic/understandable level. He discusses the history of encryption, and some current algorithms, such as RSA.

I don’t know your level, but if you’re not already knee-deep into mathematics/information theory, you will probably find it a lot more accessible.

Encryption is a very very very big area of mathematics. The purpose of the encryption is important in deciding what type of algorithm to use. The best book by far for learning encryption techniques is Applied Cryptography by Bruce Schneier. You can get it from Amazon or similar. It has detailed explanations of secure protocols, encryption and encoding algorithms, and lots of source code to play with.

Bruce Schneier runs Counterpane Internet Security. There’s a lot of technical information availaible on the Counterpane Laboratory site, lots of papers and newsletters and free source code for several algorithms, including Blowfish (a widely used and very secure algorithm) and Twofish.

Schneier’s Secrets and Lies is well worth reading. Cryptography is only part of the answer to security problems; see this page from the introduction.

Bad attitude. I’m not saying you should trust someone else’s code without evaluation, but trusting anyone’s (including your own) code without evaluation and attack by an independent party or parties is not a good idea.

You are doomed. How do you know that you can trust the compiler that you will compile the code with?

Basically, what everyone else, and especially micco, said. Implementing an existing algorythm shouldn’t be too hard, once you’ve got a decent understanding of what’s involved, but creating a new encryption scheme is a Very Big Deal.

The FAQ for the usenet group on cryto explains the difficulties, and why the denizens of that group hate it when someone comes along with a “brand new encryption technique that’s like, way '133t”. Unfortunately, the name of that group eludes me at the moment. You might try reading this FAQ http://www.faqs.org/faqs/cryptography-faq/
since it will be a little easier to read than Applied Crypto(which is an excellent book, btw)

You had it and didn’t know it. Your link is the FAQ for sci.crypt, the main Usenet group for serious discussion of crypto.

If you aren’t stuck on some “public” key type of encryption, it is actually pretty easy to write a new encryption type that can be quite secure. Its the public key part that makes it tough.

If you allow the parties that are going to pass messages to pass key material “in the blind” it is much easier. In fact, it isn’t very difficult to build completely unbreakable encryption if no part of the key has to be publicly available.

I disagree pretty strongly. The single case where you’re right is a one-time pad algorithm, which is trivial to implement but pretty impractical to use in realistic situations.

Do you really think it’s easy to develop a secure symmetric algorithm? As in my earlier post, I’ll point you to the recent AES competition. Many people tried to develop new algorithms. Almost as many failed. There were a few standouts, but they were developed by teams of people who had years of experience in the field and they spent a great deal of time developing their schemes and subjecting them to a battery of different cracking techniques.

At the other end of the spectrum, check out the sci.crypt archives for thousands of “new unbreakable encyption” posts which are typically cracked wide open within hours of being posted.

Actually, the one time pad is great to implement for one to one message sending. Just fill two CDs or DVDs identically with true random environmental noise, and you are in business. US govt has used technique even.

I probably should have qualified my statement though. There are several different encryption environments to deal with.

  1. One to One message passing. Your encryption engine and keys are not available for analysis to anyone trying to break your code. This makes your job much easier.
  2. Commercial encryption with out public keys. Much tougher, as potential codebreakers get to see the guts of the encryption engine.
  3. Commercial with public keys. By far the toughest to do mathmatically.

The AES competition would not consider stuff in the first category. Encryption of commercial value has to be secure even when everyone knows how the encryption is accomplished. However, for the OP project, this wasn’t a specified requirement. So, I was even considering a one time pad a viable option as well as all the encryption engines that are very good if no one else gets to see the guts.

“Security by obscurity” - generally discredited for real applications because you can never trust that your secrets will get kept. If you could keep those things secret, you wouldn’t need encryption. The spies, spooks and crackers will always be better than we are. Works great for passing notes around the clubhouse, but if you do anything that makes you an attractive target (e.g. financial transactions), you’ll get cracked in a hurry.

True. This includes every respected symmetric algorithm I can think of. The exceptions are things like music and video codecs that try to remain secure by outlawing reverse engineering (i.e., they’re not secure, but they’ll sue you for noticing).

The mathematics in public-key systems is not any harder than in symmetric systems. They’re based on different math, but I don’t really think one is harder than the other on a conceptual or practical level. In fact, mathematically speaking, public-key systems are usually much simpler than symmetric systems. Symmetric algorithms typically have very complex key schedules and repeated rounds. Public keys systems like RSA or El Gamal can be expressed as a single exponentiation.

The implementation of a public-key system may be more difficult because it requires things like big integer libraries and pseudo-random generators, but you can do basic RSA in seven lines of Perl, so how hard can that be (for the Perl-impaired, that’s a joke).

First, I would like to thank everyone for their invaluable help. I will be definitely checking otu a copy of Bruce’s book.
Ok, I am only in High School so I guess that serverely limits the mathematical aspects. The ease of cracking the program has almost no importance. These judges are will not have the time or the computer skills to do so. The focal point of my paper is to implement my own cipher using C++. The more I am able to relate it to math the better.
The comment about not trusting anyone else is simply because I do not want to plagiarize and I probably would not be able to explain everything as well if I did not hand write it myself.
The code will be used basically once maybe twice. So the one to one message may be viable. Although it would look much more impressive if I did one that was slightly more complex. I have 4 months, and I believe that I am dedicated to the cause. Once again thanks everyone.

This is easy then.
If you want the simplest cypher…just XOR your plaintext with a number. That will produce your code.
To turn the code back into plaintext, just XOR the code with the number again.

So…

Plaintext XOR Number = Code
Code XOR Number = Plaintext

Got it?