RU beehive logo ITEC dept promo banner
ITEC 345
2013fall
ibarland

home—lects—hws
D2L—breeze (snow day)

crypto-using-gpg
Encrypting, Signing, and Hashing messages
hw04: using gpg

Due Oct.18 (Fri) 14:00.

In this homework, you will generate your own pair of public/private keys, and use them to encrypt a message, and to digitally sign a message. You will also check check for tampered files both by checking a digital signature, and checking file-hashes.

You may work with a partner for this homework. When completing this assignment, be sure to use the filenames exactly as specified. The grading will be largely automated, and using different filenames may result in getting a 0 on that portion of the question. Only submit one copy of your team files on D2L.

To run this lab, you will need to be able to run gpg (“GNU Privacy Guard”), which is installed on rucs.radford.edu. You can connect via ssh or putty, as usual. You can also download versions for your own computer from www.gnupg.org; either version 1.4 or 2.1 should suffice. The provided links include GUI versions1; it's up to you (and the discussion boards) to interpret the (command-line oriented) instructions in these instructions.

  1. Generate a public/private keys for your team.

    1. Make sure you can run gpg, either on rucs or your own computer (e.g. run “gpg --help”).
    2. Then follow the instructions in the section “Generating a new keypair” from the manual www.gnupg.org/gph/en/manual.html, and follow those instructions (i.e. run gpg --gen-key from the command line). If using a gui tool, it's up to you to figure out the equivalents to the command-line instructions.
    3. When prompted for inputs, you can use any of the defaults provided.
      • (Only) if you are running this rucs, I recommend using a smaller key-size (1024 bits, rather than 2048). This is to help minimize the long delay mentioned in the next step.
      • If you choose a non-default expiration date, make sure your key doesn't expire before the end of finals week (≥ ~10weeks).
      • Do use a (nick)name I'll recognize as yours, and use your RU email.

    4. Generating the key, if on rucs, can take a while (about 20-30min)! It tends to be very quick on PCs/Macs.

      If, on rucs, you get a message about “Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy!” you can do spur the computer to do some busywork. Doing I/O is good because it is both a source of external, non-deterministic (effectively random) bits, and it doesn't bog down the machine's cpu as much. Some examples: From a different shell:

      • nice watch wget -O /dev/null amazon.com

        (While waiting, you can use man to see what each of nice, watch2, and wget do.)

      • If you want to see the (slow) progress, you might run nice watch cat /proc/sys/kernel/random/entropy_avail
      • You can copy large files to/from rucs (for example, a large disk-image).
      • You might use find (along with nice) to trigger local disk I/O.

    When finished, it won't print the keys, but your public/private pair will be stored in a preference file (on Mac/Unix, it's in ~/.gnupg/, if you care).
  2. Export your public key. Read the section: “Exporting a public key” (www.gnupg.org/gph/en/manual.html).
    1. Make sure to use the “--armor” option, so that the result doesn't contain special (non-printing) characters.
    2. Deliverable: A file containing your public key, named3 user1-user2.pub (where user1 and user2 are the RU usernames of you and your teammate -- e.g. “ibarland-jpittges.pub”).

    E.g. if I was generating a public key with my email id, I might run: gpg --armor --export ibarland@radford.edu > ibarland-jpittges.pub Go ahead and look at the contents of your public key file once (using, say, cat or more or an editor); it should contain something like: 

     -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Aha, this is the comment I entered when creating the key.

Y93aV7dns0t1+ODms33koJuE3drtQ8z93sDmA+KrTm7EfWvZLu7LnXvpi3JvDBYJ
/c+R2WcL+rnKn/l7ciAQ5hQRxOC3JDJzf4gVEE4SrQnoncVl/oJEzAEe0W4yceBN
CMf3DOG4OcV97qITr6epiAvKUnDtGrtJDXiPpr2tkg9jcNTLGy+viBAbuHrTfEEA
⋮
-----END PGP PUBLIC KEY BLOCK-----
    Congratulations! That is your public key.

  3. Decrypt a signed message.

    1. Download MY (Ian’s) public key ibarland.pub from the homework files.
    2. Import my public key into your public key ring, as described in "importing a public key" in www.gnupg.org/gph/en/manual.html. (A public key ring is a ring that contains all the public-keys from others that you have collected.)
    3. Download three different files, each purporting to contain the name of my favorite band. However, only one of them is properly digitally signed by me. Determine what my favorite band really is.

    4. Try decrypting each of the files, as described in “Encrypting and Decrypting documents” in www.gnupg.org/gph/en/manual.html.

      Note that you want to make sure “Good signature” is indicated; however it won't be a “trusted signature” because you have not had some certifying authority add me to your web-of-trust. That's okay.

    (There isn't any direct deliverable for this step, but you'll include this important information in the next step.)
  4. Create a message.
    1. Create the file message.txt, for use in the following steps.
    2. Your file must be a plain-text file (not .doc or anything).

      There are many ways to create a plain-text file: You can run an editor on rucs directly, like pico or emacs or vi (all of which run within a terminal window). Or, you can an use an editor on your own machine, like use Notepad or Word being sure to save as a plain-text file. If you then need to have that file stored on rucs, you can use scp to copy it there.

    3. Your file must contain:
      1. The string “ITEC 345, 2013fall-ibarland”.
      2. the name of your team's public-key file (created above),
      3. the preferred (first) names of all teammates,
      4. the name of my favorite band (and it must not contain the name of any bands in imposters from the previous step).
      5. a videogame that (at least one of) you have enjoyed playing in the past. (It can contain more information, but shouldn't be larger than 1KB.)
      Deliverable: message.txt. Note that this same file will also be used for several following steps, so don't modify it later.
  5. Digitally sign your message.

    To generate a digital signature on a document, refer to the appropriate section of www.gnupg.org/gph/en/manual.html. E.g., if the document to sign is message.txt, then you can created the signed version (named message.txt.sig) as follows:

    1. gpg --output message.txt.sig --armor --clearsign message.txt
    2. Since digital signatures involve encrypting the text document with your private key, you will be prompted for the passphrase you used during the creation of your public/private key pair. If you do not remember this phrase, you will need to go back to Part I and start from scratch.
    3. Self-test: You too can verify if your signature was created correctly. Simply decrypt the document: gpg --decrypt message.txt.sig (Since gpg already knows your own public key, you won't need to add anything further.)
    Deliverable: message.txt.sig. Between this file and your public key (submitted earlier), I'll be able to authenticate the file.

  6. Send me a confidential message, using MY (Ian's) public key.

    Well, it won't be that confidential, but encrypt your message file using my (Ian’s) public key.

    1. gpg --out message.txt.gpg --armor --encrypt message.txt
    2. You will be prompted to enter the userid of the person whose public key you want to use. Use my public key by entering my RU email ibarland@radford.edu (and ignore messages saying that this key is not trusted).
    3. The file encrypted-message.txt will now contain the text message encrypted with my public key. So it is now confidential; only I can decrypt it.
    4. Be sure to use the exact filename specified, and include the armor option so that the encrypted version only contains printable characters.
    5. Deliverable: the file message.txt.gpg (be sure to use that exact filename!). Once I decrypt it using my own private key, I will know if your encryption has worked.
    6. Self-test: You can (and should) test whether your public private keys are working using this method:
      1. Encrypt the same file “message.txt”, but this time using your own public key.
      2. Next decrypt it using your own private key. You can decrypt it with the --decrypt option as follows: gpg --decrypt message.txt.gpg and the result should be identical to the original message.txt.
      3. Even better self-practice, find a different team/friend in the class and ask them for their public key, and make sure you can send messages to them.
      With this you should have gained hands on experience in being able to encrypt or decrypt any message.

    You are encouraged to share your public key with other friendly teams and send appropriate messages encrypted with their public key. (This won’t be graded.) You can post your public key on the D2L discussion boards, and/or on your web page.

  7. Authenticate and encrypt: Submit a file which is both secure from eavesdroppers, and digitally signed by you: simply encrypt the signed version message.txt.sig from two steps ago.
    Deliverable: the signed, encrypted file, named “message.txt.sig.gpg”.

    Note that I'll be checking your file in the indicated order: Since you signed-then-encrypted, I will correspondingly decrypt-then-unsign. (That is, I'll decrypt with my private key, then with your public key.)

    (Note that in general, encrypt-then-sign and the flipped version sign-then-encrypt both achieve authenticated, confidential information. However, there is a difference: In one version, an eavesdropper can authenticate who the message's author really is, even if they don't know the message at all. In the other version, if the eavesdropper just sees the file, they can't even be absolutely sure who wrote it. I'll leave it for you to ponder which arrangement is preferable, and probably ask about this on an exam.)

  8. Compute the hash for your original message.txt, via the SHA-256 hash algorithm. Use gpg's “print-md” option, giving it “sha256” as the algorithm: gpg --print-md sha256 filename. Deliverable: Store the fixed-length result in a file message.txt.sha256.

  9. With the hw04 files you will find three plain-text files (.txt) along with their secure hashes (.txt.sha256) . However, something foul is afoot: at least one of those .txt files has been tampered with. Your goal is to compute the correct sha256 hash for each file, compare each with the posted sha256's and determine which file(s) were altered by an international gang of file-tamperers.

    Deliverable: a file named fixed-hashes.txt which contains, for only the files which have an incorrect hash, the hash for that (presumably-tampered) file as printed by gpg. For example, something like: 

    hw04.html: 1E0F772F 20668251 268546E5 FEFA9C2D 312340E5 958D2D8E
           9B019581 A7A1EB1B
    (Your file should have exactly 0, 2, 4, or 6 lines.)

  10. Deliverables: On D2L, exactly one team-member should submit the following files:

1 If you are installing gpg on your own machine, here are some random notes:

     ↩

2 The program watch is installed on rucs, and might be a standard install on some linux systems, but it's not included wit Mac OSX by default. Myself, I installed it on my own Mac using the package-manager homebrew, by running brew install watch.      ↩

3 If not working with a teammate, then of course use just your own username, “user.pub”.      ↩

home—lects—hws
D2L—breeze (snow day)

©2013, Ian Barland, Radford University
Last modified 2013.Oct.17 (Thu)		 Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu		 Powered by PLT Scheme