User Tools

Site Tools


Sidebar

projects

  • cci0 (due 20150909)
  • mms0 (due 20150916)
  • dow0 (due 20150923)
  • mbe0 (due 20150930)
  • mbe1 (due 20151007)
  • cos0 (due 20151028)
  • afn0 (due 20151104)
  • sam0 (due 20151111)
  • cbf0 (due 20151118)
haas:fall2015:cprog:projects:sam0

This is an old revision of the document!


Corning Community College

CSCS1320 C/C++ Programming

~~TOC~~

Project: Data Obfuscation - SECRET AGENT MESSAGES (sam0)

Objective

To explore the implementation of caesar cipher encoding and decoding programs.

Background

A cipher is defined as “a secret or disguised way of writing; a code”, and (as a verb): to put (a message) into secret writing; encode.

In the realm of secrecy (think elementary school secret agent), obfuscation is key. If we can remove direct accessibility to the message (encode), yet still preserve its intent, it can be transmit to a recipient who has the ability to retrieve the message (decode).

The caesar cipher (or shift cipher) is a relatively simple cipher, where each letter of the alphabet is shifted by a fixed amount, enabling a once legible message to appear unrecognizeable (at least directly).

Further background information can be found here:

There are two processes related to a lossless obfuscation of data:

  • encoding - taking the readable text and making it obfuscated, according to a set process
  • decoding - taking the obfuscated text and making it readable, by reversing the process

Task

You are to implement two programs (or at least a program with two fundamental modes of operation):

  • encode program: takes plain text message as input, along with a cipher key, and outputs the encoded (obfuscated) result
    • key should be provided via command-line argument (or, if present, a file in the current directory called 'cipher.key')
  • decode program: takes the encoded (obfuscated) message, along with a cipher key, and outputs the decoded (readable, plain text) result
    • key should be provided via command-line argument (or, if present, a file in the current directory called 'cipher.key')

The key should be a signed char, allowing for a cipher shift of -128 to +127 (your shift can be left or right, depending on the sign of the number).

You can implement this as two separate programs, or as one program that behaves fundamentally different depending on how it is named (ie encode-sam0 operates in encode mode, decode-sam0 operates in decode mode).

Your program should accept input from STDIN until the EOF character is encountered.

Sample execution: encode

Via positive command-line key:

lab46:~/src/cprog/sam0$ ./encode-sam0 2
hello
jgnnq
^D
lab46:~/src/cprog/sam0$ 

Via negative command-line key:

lab46:~/src/cprog/sam0$ ./encode-sam0 -3
hello there
ebiil qebob
^D
lab46:~/src/cprog/sam0$ 

Function prototype

Like variables, functions need to be declared.

We can declare them at various scopes (file/global, block/local)… if you wish for the function to be accessible by all functions within a program, you will want to declare it with a global scope.

If a particular function is only to be used by a specific function, and no others, you can opt to declare it local scope (ie within the function that will be calling it).

A function is basically a module or subroutine. It is a mini-program, focusing on the performing of a particular process.

Like a program, it takes input, does processing, and provides output.

Unlike a program, its input may not come from the keyboard, but instead from particular variables, and may not send output to the screen, but instead channel output in a way that it can be stored into a variable.

This distinctions aside, a function can in many ways be viewed as a micro- or sub-program/routine. We use functions to assist us in making our code more readable/organized/navigable.

Keeping everything in ONE file, ONE big function in that one file, is rather monolithic. In time, with sufficiently large programs, such an arrangement would become a tad unwieldy. So functions help to keep our focus short yet attentive.

To create a function we must first declare (or prototype) it. This needs to happen BEFORE said function is ever used (just as with variables- you must declare a variable before it is first used, otherwise the compiler yells).

A function, in many ways, is like a programmable variable (or is a variable with programming attached).

As such, it has a return value of a type (the function's output), a name, and parameters (input).

We see this with main()… here are two variations of a main() function declaration (technically also the start of the definition as well, in the case of main()):

Parameterless function

int main()

In this example, we see the declaration of main() where it has a return value of int, meaning, upon completion, main() will return a value corresponding with an int data type (also in main()'s case, being the first function run, we tend to return a status code to the operating system– 0 for success, non-zero for some sort of error or deferred success).

main(), in this case, takes no parameters (just an empty set of parenthesis)… due to this, we refer to this function as a parameterless function. A function without parameters. Without input.

Now: this is technically a different form of input and output than you are used to. Input doesn't ALWAYS have to come from the keyboard, nor does output ALWAYS have to go to the screen. Input instead is desired informating being acquired for the process at hand, and output is the byproduct of performing the operation. Sometimes this means keyboard input and screen output- but not always.

Additionally, with or without parameters, we can always perform additional input (and output) within a given function, through the use of various input and output methods (like fprintf()/fscanf()).

Parametered function

int main(int argc, char **argv)

In this case, our main() function actually takes parameters- two, in fact:

  1. an integer, we are calling argc
  2. a double pointer, we are calling argv

This function takes two parameters, two pieces of input, available to us in the form of variables, by those names, of those types. We make use of them as we need to in accomplishing the program at hand.

So, when we wish to create functions of our own, we need:

  • the return type
  • the function name
  • 0 or more parameters, identifying their order and type

For example, let us make a sum() function. Here would be a likely prototype (we'd place it above main()):

int sum(int *, int);

A function prototype (vs. its definition) will have a terminating semi-colon, as you see above.

In our case, our sum() function has the following:

  • a return type of int (particular variable name doesn't matter, type does)
  • the function's name (sum)
  • a comma-separated list of types corresponding to the parameters (again, variable names do not matter, but the type is important).

Our sum() function will take an integer array (denoted by the int pointer above), and a size (the second, regular int).

Now, parameter order very much matters. In our case, an “int *” came first, followed by an “int”… we need to be mindful of this order to successfully call and use the function.

Submission

To successfully complete this project, the following criteria must be met:

  • Code must compile cleanly (no warnings or errors)
  • Output must be correct, and resemble the form given in the sample output above.
  • Code must be nicely and consistently indented (you may use the indent tool)
  • Code must utilize the algorithm presented above
  • Code must be commented
    • have a properly filled-out comment banner at the top
    • have at least 20% of your program consist of //-style descriptive comments
  • Track/version the source code in a repository
  • Submit a copy of your source code to me using the submit tool.

To submit this program to me using the submit tool, run the following command at your lab46 prompt:

$ submit cprog sam0 sam0-encode.c sam0-decode.c
Submitting cprog project "sam0":
    -> sam0-encode.c(OK)
    -> sam0-decode.c(OK)

SUCCESSFULLY SUBMITTED

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.

haas/fall2015/cprog/projects/sam0.1445968653.txt.gz · Last modified: 2015/10/27 17:57 by wedge