Jumpstart Lab Curriculum


In this project you’ll use Ruby to build a tool for cracking an encryption algorithm.


Learning Goals / Areas of Focus

  • Practice breaking a program into logical components
  • Testing components in isolation and in combination
  • Applying Enumerable techniques in a real context
  • Reading text from and writing text to files

Base Expectations

You are to build an encryption engine for encrypting, decrypting, and cracking messages.

Encryption Notes

The encryption is based on rotation. The character map is made up of all the lowercase letters, then the numbers, then space, then period, then comma. New lines will not appear in the message nor character map.

The Key

  • Each message uses a unique encryption key
  • The key is five digits, like 41521
  • The first two digits of the key are the "A" rotation (41)
  • The second and third digits of the key are the "B" rotation (15)
  • The third and fourth digits of the key are the "C" rotation (52)
  • The fourth and fifth digits of the key are the "D" rotation (21)

The Offsets

  • The date of message transmission is also factored into the encryption
  • Consider the date in the format DDMMYY, like 020315
  • Square the numeric form (412699225) and find the last four digits (9225)
  • The first digit is the "A offset" (9)
  • The second digit is the "B offset" (2)
  • The third digit is the "C offset" (2)
  • The fourth digit is the "D offset" (5)

Encrypting a Message

  • Four characters are encrypted at a time.
  • The first character is rotated forward by the "A" rotation plus the "A offset"
  • The second character is rotated forward by the "B" rotation plus the "B offset"
  • The third character is rotated forward by the "C" rotation plus the "C offset"
  • The fourth character is rotated forward by the "D" rotation plus the "D offset"

Decrypting a Message

The offsets and keys can be calculated by the same methods above. Then each character is rotated backwards instead of forwards.

Cracking a Key

When the key is not known, the offsets can still be calculated from the message date. We believe that each enemy message ends with the characters "..end..". Use that to determine when you’ve correctly guessed the key.


The tool is used from the command line like so:


ruby ./lib/encrypt.rb message.txt encrypted.txtCreated 'encrypted.txt' with the key 82648 and date 030415

That will take the plaintext file message.txt and create an encrypted file encrypted.txt.

Then, if we know the key, we can decrypt:


ruby ./lib/decrypt.rb encrypted.txt decrypted.txt 82648 030415Created 'decrypted.txt' with the key 82648 and date 030415

But if we don’t know the key, we can try to crack it with just the date:


ruby ./lib/crack.rb encrypted.txt cracked.txt 030415Created 'cracked.txt' with the cracked key 82648 and date 030415

Evaluation Rubric

The project will be assessed with the following rubric:

1. Fundamental Ruby & Style

  • 4: Application demonstrates excellent knowledge of Ruby syntax, style, and refactoring
  • 3: Application shows some effort toward organization but still has 6 or fewer long methods (> 8 lines) and needs some refactoring.
  • 2: Application runs but the code has many long methods (>8 lines) and needs significant refactoring
  • 1: Application generates syntax error or crashes during execution

2. Test-Driven Development

  • 4: Application is broken into components which are well tested in both isolation and integration
  • 3: Application uses tests to exercise core functionality, but has some gaps in coverage or leaves edge cases untested.
  • 2: Application tests some components but has many gaps in coverage.
  • 1: Application does not demonstrate strong use of TDD

3. File I/O

  • 4: Application warns the user when the output file exists and allows them to cancel the operation or overwrite the file
  • 3: Application reads and writes files as described
  • 2: Application can only specify either the input or output file name
  • 1: Application uses only static filenames

4. Breaking Logic into Components

  • 4: Application effectively breaks logical components apart with clear intent and usage
  • 3: Application has multiple components with defined responsibilities but there is some leaking of responsibilities
  • 2: Application has some logical components but divisions of responsibility are inconsistent or unclear and/or there is a "God" object taking too much responsibility
  • 1: Application logic shows poor decomposition with too much logic mashed together

Have Feedback?

Did you find an error? Something confusing? We'd love your help: