Printable View
First, let me congradulate all contestants for participating. Everyone who signed up sent something in! It shows a real interest.
I will post my comments, individual scores, and the winner of it all. A few posts down is a zip file with all of the source code.
Note: all source code is the unmodified original
for all entries, the criteria were:
speed -- this served as a moderating factor. No entry was exceptionally slow.
efficiency -- this is how well a program uses its resources to encrypt
elegance -- how pretty the code looks
portability -- how portable the code is
The Interface -- how pretty and usable the interface is
Size Ratio -- the amount of space the encryption takes up compared to the original
Creativity (counts double) -- how original the idea was
Strength -- how easily it can be broken. (note: i didn't try to actually break each encrypted message. these are mostly educated guesses.
Two points will be added to the total for the ability to work with ASCII code and not just letters and numbers. I didn't test each one with that kind of thing; i just checked the algorithm. Testing each one with a binary file might trip up programs with EOF's and whatnot.
Longer descriptions of the criteria can be found at the beginning of the post.
If you spot something I got really wrong, some glaring problem, tell me and I'll look it over.
Hammer's entry:
review notes:
i tried compiling the pieces together with the command:
gcc -o crypto crypto.c ioUtilities.c main.c -O2
there are multiple errors, all having to do with stray '\' marks. this might have worked on his compiler, but it doesn't work on mine. (gcc 2.95.3, linux) in any case, this is a minor setback. After fixing this problem it compiles fine.
scores:
speed: 3. No extraordinary speed-saving measures, nor was there any speed delay. A 2 mb file took only a 1/4 second.
efficiency: 3. No special efficiency measures, either. This program was geared more toward modularity.(sp?)
elegance: 5. All code looked neat. It was indented, logically placed, and the variable and function names make sense.
portability: 2. My compiler, a fairly common one, didn't accept slash marks without a problem. Last time I used them was on DJGPP, where it told me they were depreciated. Other than that, it's mostly fine. The only other fault I could find was a message in the readme file telling me to set a #define depending on the compiler I used.
The Interface: 4. It allows input from both standard input and a file. It can do this from the command line or from a prompt inside the program. It includes help messages. An ignorant user would have little trouble eventually getting this program to work. (depending on the user, of course...)
Size Ratio: 3. It stays exactly the same.
Creativity: 1.5. Xor encryption is anything but creative.
Strength: 3. Being xor encryption, it is reasonably strong, but not unbreakable.
+2 for ASCII
total: 28. (the sum of all scores, creativity counted twice, and two extra points)
vasanth's entry:
review notes:
Judging from the readme, this one looks promising. Unfortunately, it doesn't compile. Since he has said repeatedly that it works on his machine, I'll try to fix some syntax errors.
1) it appears string.h uses 'index' as a function name, so that variable name will have to be changed. (added two underscores after it)
2) the variable 'i' had gone out of scope after a for loop. i'll just initialize it again.
3) functions en and de have no return type. i'll make them ints.
now it works.
Now that that's out of the way...
The program is a command-line program. It outputs to standard output and a file, and inputs from a file. Using a 64k file named short.html, I ran it through. Unfortunately, when it writes to a file, it just keeps on writing forever. I had a 90 mb file of null characters before I forced it to stop. It does show the outputted data to console, though. The included win32 executable works fine, like it's supposed to, so it's probably a portability issue. The problem was with a temporary file written to C:\. A better solution, IMHO, would be to write it to the current directory.
scores:
speed: 3. No glaring issues.
efficiency: 3. No gaping holes.
elegance: 1. Overall, the code was sloppy. It is indented oddly and the indenting system changes as you scroll down. Global variables were used. And believe it or not, there was a goto statement to the middle of an if clause.
portability: 1. In order to compile it I had to correct syntax errors. If these were allowed by vasanth's compiler, then it is a portability issue. In linux, if weird characters are outputted to console, it will screw up the console letters. (not fatally, a reset command usually returns things to normal.) That is a compatability issue because this program outputs the text to console. The question at the end makes it very difficult for the text to be outputted through redirection.
Interface: 3. It gets the job done. While some unexpected stuff on the command line could upset things, for most cases it works properly.
Size ratio: 3. nearly 1:1. The readme tells me that it should actually shrink in size, but in my file (which had no endlines or tabs) it grows bigger by a hundred bytes or so. In any case it is normal.
Creativity: 4. He uses a vigenere algorithm with a few more tricks mixed in.
Strength: 3.5. Given the fairly unusual algorithm, it makes it slightly harder to crack.
+2 for ascii
total: 27.5
QuestionC's entry:
This also looks promising. In his readme he gives a lengthy history of and details about the Enigma machine. It's a World War 2 encoding machine.
Compiling went fine. He even included a makefile, although the steps were intuitive.
The program works.
scores:
speed: 3. Nothing Special.
efficiency: 3. Nothing Special.
elegance: 5. Functions and variables are named well. The program is divided up nicely, too.
portability: 3. Nothing special. no portability problems.
Interface: 4. It makes it easy to do what you want. The error messages could have been better labeled. Not everyone knows that this encryption program takes only numbers as keys.
size ratio: 3. no change in size.
creativity: 4.5. I'd give it a five, but this idea was stolen from the Germans. :)
Strength: 3. Back in WW2, they often had the messages cracked daily. This form of encryption has weak points, but for the most part it's fairly strong.
+2 for ascii
totals: 35
Sean345's entry
He names his entry 'Enigma'. It is nothing special. It has a nice interface, a menu, and logical code, but in the end it's encryption is not creative or strong.
scores:
speed: 3. Although his code reports that ten seconds have gone by, in reality it's unnoticable.
efficiency: 2.5. The program goes through many levels of functions to do stuff.
elegance: 4.5. All code is neat. Prototypes and #defines are in a seperate header file. However, there is an obvious typo, which could mislead some people.
portability: 3. Nothing special. No problems here.
Interface: 4. The menu idea makes things easy for the user. I have to question the logic of having a seperate encrypt and decrypt choice, when both do the same thing...
size ratio: 3. no change in size
creativity: 1. It's a simple xor encryption program, with a nice interface. Unlike some of the other xor encryption schemes with passwords, this one uses the same key on every character.
strength: 1.5. It would be a piece of cake to crack this.
+2 for ascii
totals: 25.5
shaik786's entry
His entry encrypts through some complicated bitwise operations. It is reasonably secure. It has a tendency to mirror redundancy in the original text, although it doesn't mirror it exactly, so it can be misleading. It looks like a fine entry.
scores:
speed: 3. Nothing special.
efficiency: 3. nothing special.
elegance: 4. The code is neat. He uses hex to show better the encryption. There are a few errors, though. He uses gets(), a dangerous function sometimes. He doesn't cast from getpass(), which passes an int.
portability: 2.5. No problems here, except that getpass() is depreciated. My compiler didn't give me problems with that, though.
Interface: 3. The interface is bare and standard, mostly. It lacks some helpful hints, like a range for the key, or a description of the program. But silences the console echo when the password is typed.
size ratio: 3. no change
creativity: 3.5. While bitwise altercations are nothing new, the uses of them as well as its use of the key make it creative.
strength: 3.5. It is slightly harder than xor encryption to break.
+2 for ascii
totals: 31
tailorguitarman's entry:
His entry is fairly simple. It adds a key, xors with the key, adds a seemingly random number, and xors it with the key again. Unfortunately, the random algorithm changes from operating system to operating system. It makes it uncertain whether something encrypted on one system, compiled on one compiler, will work on another system and another compiler. I created an executable using linux gcc 2.95.3 and another one in windows using dev-c++. These encode differently and can't be interchanged.
scores:
speed: 3. Nothing special.
efficiency: 3. nothing special.
elegance: 5. Mostly everything looks good. Its functions give it a modular feel, and everything is named logically.
portability: 1. The rand() function is expected only to give a reasonably random number. This program assumes (incorrectly) that every compiler implements this function the same way. Even with the same seed, this can't be expected.
Interface: 3. It is a run-of-the-mill command line function.
size ratio: 3. no change
creativity: 4. Using a random algorithm as well as some bit manipulations makes it interesting, at least in theory. If he made his own randomizing function or copied a standard one, this would work much better.
strength: 4. The randomizing function makes it close to impossible to guess the decoding algorithm. It's discreet enough to boggle people for a while.
+2 for ascii
totals: 32
Xmevs's entry:
This file gives me so many errors in linux... I can't compile it without a great deal of changes, some of which show no obvious correct solution.
Using dev-c++ I finally get it to work after including a variety of files, like stdlib.h and stdio.h. I erased all the clrscr()'s. Unfortunately, I choose an option from the menu, It writes a file steadily increasing in size on my hard drive. After adding a fflush(stdin); statement in the appropriate spot it works.
scores:
speed: 3. Nothing special here.
efficiency: 3. Nothing special.
elegance: 1.5. There are two global arrays defined up top, filled with misc. ASCII characters. It doesn't look good. The two space characters had to be altered for the program to compile. Many include files had to be added, and five functions had to be commented out. The only redeeming quality were the variable names and the layout of the program. Oh, and there were two goto's. IMHO a while loop would have done it cleaner.
portability: 1. the conio.h header isn't a standard. A system command calls 'pause', a MS-DOS command. clrscr() is non-standard. It assumes C:\ exists for a temporary file.
Interface: 2. The interface is a text menu, and well laid out. Unfortunately, he forgot to flush the input. This creates a lot of problems.
creativity: 2. The algorithm is a regular substitution algorithm.
size ratio: 3. The process adds one byte to the end. Not significant.
strength: 2.5. It's not too hard to figure out encrypted text from this. Not too easy, either, but easier than xor encryption.
totals: 20
Winners
QuestionC: 35 (3.89)
Taylorguitarman: 32 (3.56)
Shaik786: 31 (3.44)
Hammer: 28 (3.11)
Vasanth: 27.5 (3.05)
Sean345: 25.5 (2.83)
Xmevs: 20 (2.22)
(numbers in parentheses are of a 5 point scale)
Congrats, QuestionC, our new winner!
can a mod sticky this thread, please?
no offense but man you really should put eah entry on a webpage so we dont have insane load times to see the stuff plus im sure the admin wont apreaciate the huge bandwith spike his going to experience...
i guess you're right... it is a bit much
i'll just post the source code zipped up
Well this was a great contest guys.. Well atleast my encryption has good strength.. I got 3.5. One of the highest.. Thank you.. I will sure improve my coding style in the future...
Thenx
Bye
Congrats to all participants !
I'm sorry for any inconvenience I may have caused. ygf looked at all your programs and was just waiting for me to do the same, but at the moment, my sparetime seems to be sucked into some invisible black hole never to be seen again. I hope I'll be more helpful when I have some time on my hands *g*
Me thinks it be time to start planning the next contest.
Perhaps something graphical?
let me start a new thread on planning.
//edit: the thread is called the third round, fyi
First of all, congrats to all, and specially to QuestionC.
ygfperson, can you put the code on some webpage or somewhere else(probably a FTP site)? I cannot download the zip file you've attached in this thread, the Firewall here does not allow me to.
it's also at http://www.flashdaddeesfreehold.com/forums/all.zip
Thank you, thank you. I would like to give a shout out to my manager, my mom, Jesus, and The Code Book for making this all possible. :)
I must say however, I'm a little miffed about EnigmaC getting the same score for strength as XOR encryption. I mean, come on, we're talking about three smoking barrels of encrpytion goodness all wrapped into one typewriter from hell.
And umm, thank you again. :)
Yo, well done QuestionC :)
I could take care of that if neededQuote:
Originally posted by Unregistered
no offense but man you really should put eah entry on a webpage so we dont have insane load times to see the stuff plus im sure the admin wont apreaciate the huge bandwith spike his going to experience...
What, for a 45kb zip file??!! :confused:Quote:
Originally posted by Unregistered
.... insane load times to see the stuff plus im sure the admin wont apreaciate the huge bandwith spike this going to experience...