SE 2811, Lab 2: Strategy-based Encryption

This lab will give you experience using the Strategy Pattern. In this lab you will use the Strategy Pattern to build a portable device for carrying secure messages known as a CrypStick. When a message is entered into the CrypStick, it is encrypted before storing on the internal media. When a message is read from the internal media, it is decrypted. Thus (after the encryption method is cleared) anyone who steals the media must also break the encryption to reveal the message. This is an individual lab.

The primary class you will implement is CrypStick; it will contain Encrypter objects to handle encrypting and decrypting messages. The key elements are illustrated in the following class diagram:

You are being given a starting point for this lab, crypstick-start.zip. This code includes a preliminary implementation of the CrypStick and Media classes. It also includes a short program that uses these classes to encrypt and decrypt data. This program will serve as a test bed to help check that your implementation is correct. The provided CrypStick and Media classes are summarized in the following class diagram:

Note the provided Main.java interacts with the user through standard input and output (System.in, System.out). You are not to change the code to use a GUI or GUI operations like JOptionPane. On start up, the program prompts the user for whether to encrypt or decrypt the data and what encryption method to use. It then encrypts the data and displays the result.

For example, if you run your program from IntelliJ and direct it to encrypt tole using the key told, a sample run would be

E)ncrypt or D)ecrypt: e
Method (rev, shift, xor): xor
Key: told
Message: 
tole
^D
00 00 00 01 7e 

Some notes on the interaction:

• The bold text is the information entered by the user.
• Read just one message, encrypt or decrypt it as directed, and exit. Our testing framework will run your program multiple times to test the various cases.
• The end of the input is marked by the end-of-file character in your environment. At a DOS command prompt, that would be by pressing the control and Z keys at the same time (Control-Z or ^Z). In IntelliJ, this is done by pressing ^D (control followed by D). Note you do not need to check for ^Z or ^D; entering these as a user causes hasNext() to return false.
• Your solution must allow all input to be in either upper or lower case.
• This shows just one set of inputs. The prompts and output for other encryption/decryption messages are given below.
• When the encryption method is "xor" (or some variant such as "XOR" or "xOR"), you will prompt for the key. You can assume that each byte in the key is a printable ASCII letter other than newline. For example, "keys", "@#2!", "me 2", but not

  2-line
  key
  

• If the encryption method is "none", apply the NullEncrypter; this encrypter applies no transformation (except that the user will see encrypted messages printed in hexadecimal and will enter hexadecimal for "decryption").
• If the encryption method is "shift", prompt for the shift amount using the prompt "Shift amount:". You can assume the response is a valid, small integer.
• For the "reverse" encryption method, there are no additional prompts.
• The natural way to read the message, line by line, means that the newline character ('\n') appears at the end of each line. Leave this newline character in place; that is, you will encrypt newline characters along with the rest of the input.
• Be precise in your prompts: there is one space after each colon and only certain letters are capitalized. Do not add extra punctuation or spaces or you will have differences that are caught by esubmit. These differences must be removed to get full credit.

The Media object simply stores the byte array given to it. When given a string, it treats the string as a series of space-separated bytes, each coded as two hexadecimal places. The toString() method returns a representation of the string using hexadecimal digits. We are using lower case letters (a-f) to represent the decimal values 10 through 15.

When encrypting information, the media's contents should be displayed in the Media object's String format, that is, in space-separated hexadecimal bytes.

When decrypting the message, the media's contents should be set with the space-separated hexadecimal bytes entered by the user before reading the message. A full application would not display this to the end user, but doing so in this lab allows us to confirm the media is properly encrypted.

Note that the encryption algorithms are fairly simple (that is, not secure). For example, the ShiftEncrypter encrypts text by simply substituting the another alphabetic character for each character encountered. The amount attribute (set by the ShiftEncrypter constructor) affects which character is substituted. For example, when amount is 1, ShiftEncrypter's encrypt() method would encrypt the 3-byte text Hal to Ibm, while the decrypt() method does the opposite. Similar to a Caesar cipher, if the numeric value of the character would fall outside of the ASCII range (0-255), the encrypter must "wrap around" to the other end. For example, if a code would have the numeric value of 256, it should wrap around to 0, and a numeric value of 260 should wrap around to 4.

ReverseEncrypter encrypts by reversing the characters in the string to be encrypted; thus Hello there Bob! becomes !boB ereht olleH. In hexadecimal, this is printed as 0a 21 62 6f 42 20 65 72 65 68 74 20 6f 6c 6c 65 48. This is a silly form of encryption, but it is a worthwhile encryption method to implement because it helps you debug your framework before attempting to introduce better encryption methods.

XOREncrypter is a little more complicated and so slightly harder to crack. For each byte in the array to be encrypted, this encrypter is to compute an exclusive-or (^ in Java) with each successive character in the specified key. For example, if the key is "abcd", then the encrypted array is

H^a   e^b   l^c   l^d   o^a   <sp>^b   t^c   h^d   e^a   r^b   e^c   <sp>^d   B^a   o^b   b^c   !^d

where H^a represents the character that results from applying the exclusive-or to H and a and <sp>^b represents computing the exclusive-or between b and a space character. Note how this also illustrates cycling through the bytes in the key arrway. For example, encrypting "Hello there Bob!" with "abcd" will give the hexadecimal output

29 07 0f 08 0e 42 17 0c 04 10 06 44 23 0d 01 45 6b

Decryption for XOR is the same process: reapply the exclusive-or operation (using the same key) to the encrypted array. Note α ^ β ^ β gives α; that is, computing an exclusive-or with the same string twice returns the original string.

The ShiftEncryter and XOREncrypter may produce non-printable characters. This is why all input and output of encrypted text uses hexadecimal.

Additional Constraints and Notes

• There are TODO comments within the code for places where edits may be needed to incorporate the strategy pattern. Normally you would remove TODO statements once they are completed, but in this case leaving them will make it easier for you to find the code you add. For this lab, please leave all TODO statements in your solution.
• Some of the technical electives (such as Network Security) discuss better encryption algorithms. Take those classes if you wish to learn about more effective encryption methods.
• You must either modify or implement the classes shown above (CrypStick, Media, Encrypter, ReverseEncrypter, ShiftEncrypter, XOREncrypter) as needed. Add constructors and getters if it is useful for your implementation.
• Do not rename the main class file; keep the name Main.java.
• Use named constants for values that would be likely to change if your implementation was maintained.
• The above UML class diagram does not fully specify your implementation. Besides issues such as constructors and attributes, your associations may differ depending on your implementation details.
• Your solution must be able to encrypt arbitrary Unicode input, not just ASCII input files. The provided Main.java supports this. Your encrypters should also support arbitrary binary data.
• A String called str can be converted to a byte array using the code str.getBytes(StandardCharsets.UTF_8).
• A byte array bytes that consists of ASCII or UTF-8 text can be converted to a (Java) String using the code new String(bytes, StandardCharsets.UTF_8).

Your submission will consist of the following:

• your completed implementation, containing your fully commented, functional code.
• a reverse-engineered UML class diagram similar to the one shown above (other than yours will include class for main and addtional details)
• responses to any instructor-specific questions (if there are any)
Be sure your code meets the coding standard published by your instructor!

See our Enterprise Architect Notes for how to reverse-engeineer a class model. The reverse-engineered model must include stereotypes (e.g. <<strategy interface>>, <<concrete strategy>>, etc.). Note the reverse-engineered diagram is to match your implementation; it may differ in details from the above diagram! For example, you may have different types of assocations. The EA Notes page also indicates how to generate a .PNG of your model; do not use screen capture to generate the .PNG because this results in a low-resolution image with important, missing details.

When you are finished, submit your assignment according to your instructor's specific directions. For example, you may need to convert your .PNG into a .PDF (probably using print-to-PDF on your computer).

Hints

• The test inputs and outputs used by esubmit are in strategy-lab-tests.zip.
• String.format() can be helpful when encoding bytes as hexadecimal strings.
• Scanner has some very helpful methods for decoding bytes from hexadecimal strings. Remember that a scanner can be wrapped around a String, and not just around System.in.
• When you have multiple forms of input such as in this assignment, it might be tempting to write code like

          {
            Scanner intro_scanner = new Scanner(System.in);
            ...
          }
          {
            Scanner second_scanner = new Scanner(System.in);
            ...
          }
  

  (where the two portions of code might be in different classes or methods). This is unlikely to work as expected, because lots of operations can result in the first scanner reading text that you need the second scanner to process. The solution is simple: create a single scanner object and pass it as a parameter or store it as an attribute.
• You may find DataInputStream useful for reading the binary data.
• When you are processing data that is stored in a Java byte array, use the byte data type for the computation, not int.
• You will likely find use for the standard Java pattern for reading until end-of-file:

       initialize scanner
       while the scanner has a next element,
           read the next element
           process that element
  

  See CountLines.java for sample code using this pattern.
• Do not attempt to implement the full lab in one step. Start by implementing NullEncrypter and the encryption method "none". This will ensure you can process hexadecimal data.
• The next recommended step is to implement the Reverse encrypter since that encrypter is simple to debug.
• The getMedia() method of CrypStick is protected to indicate that one would not normally need to access its interior data. However, we do access it from the provided Main.java to facilitate testing. A production version of CrypStick would lock down the data more completely.
• Feel free to add reasonable error checks to help you debug your code. Note the writeup does not specify specific error messages, so there is no requirement to add any checks.

Submission

Submission of the lab will be electronic. See Canvas for details.