ECE4112 Internetwork Security
LabXX Cryptography
Group Number: _________
Member Names: ___________________
_______________________
Date Assigned:
Date Due:
Last Edited: 4/28/2005
Lab Authored by: Troy Latchman and Byungchil Kim
Please read the entire lab and any extra materials carefully before starting. Be sure to start
early enough so that you will have time to complete the lab. Answer ALL questions in the
Answer Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or
before the Date Due.
Goal: This lab will serve as an introduction to encryption. This lab is in no way an exhaustive
look into this subject, nor will it try to explain how the encryption algorithms work on the bit
level. However, students will see the flow of data before, during, and after encryption.
Summary: The first two sections of the lab explore two types of encryption schemes,
symmetric key and private key. The particular symmetric key encryption algorithm we will
look at is the Data Encryption Standard (DES). The particular private key encryption
algorithm we will look at is RSA, named after its founders: Ron Rivest, Adi Shamir, and
Leonard Adleman. The third and final section will look at creating message digests with MD5
and SHA-1.
Background and Theory
The medium in which we transmit our data in the Internet is quite insecure, e.g. can be sniffed.
Given this fact, we need to come up with a way to transmit the data in a safe way. This is
where encryption comes into play. Encryption will make the transmitted data appear garbled
1
to anyone who is trying to listen in on the transmission. We have already seen this when we
took a look at SSH versus FTP over Ethereal in a previous lab. In this lab, we will take a look
at what encryption is and how it is done.
General Encryption Terms:
Plaintext - is the raw data that is generated before any encryption is done to the data.
Ciphertext – data after it has been encrypted.
Key – these are either public or private and serve as an input to the encryption algorithm.
Encryption algorithm – this is how data is encrypted. It usually requires two inputs – a
message and a key.
Note: It is EXTREMELY important that you read over the lecture slides before completing
the various sections of this lab. The material on those slides will NOT be regurgitated in this
lab write-up.
Equipment: Your hard drive. We will only be using the RH 8.0 OS.
Section 1: Symmetric Key Encryption – DES
Be sure to read the lecture slides 1-12 to gain the background knowledge for this section.
1.1 Creating an input file
Do the following on the RH 8.0 machine,
# gedit plain
[It is important that you use gedit throughout this lab and not another text editor. Your
attachments will look different if you use another editor like Emacs]
(Select Yes to create the file)
Type in the following:
ABCDEFG 1234567890
Save the file and exit gedit.
1.2 Encryption
We will now encrypt the “plain” file using DES:
# openssl des –in plain –out output1 –e
Enter des-cbc encryption password: ECE4112
Enter the password again.
You have now encrypted the “plain” file with DES and have stored the output to a file named
“output1”.
2
Open the “output1” file with gedit
# gedit ouptut1
Print the file – Attachment #1
Repeat the above procedure, this time using a different password:
# openssl des –in plain -out output2 –e
Enter des-cbc encryption password: password
Enter the password again.
View and print the “output2” file – Attachment #2
Q1.2.1: Are attachments 1 and 2 different? Why or why not?
Repeat the exercise once more, using 3DES.
# openssl des3 –in plain -out output3 –e
Enter des-cbc encryption password: ECE4112
Enter the password again.
View and print the “output3” file – Attachment #3
Q1.2.2: Is Attachment 3 different from Attachment 1? Why?
Q1.2.3: Do you think the output would be different if you repeated the 3DES exercise
with a different password?
1.3 Decryption
Now that we have an encrypted message, it is safe (or at least safer) to transmit it
over an insecure medium. Lets assume the worst case scenario, we transmit and the packets
were sniffed. The person sniffing would see the garbled data that we saw in the “output” files,
thus gaining no real knowledge of the plaintext data.
We will now try to decrypt the data. Since DES is a symmetric key encryption
scheme, both parties need to know the key. In our first case, lets assume that the message did
not go to the right receiver and that this receiver wants to extract the plaintext message:
# openssl des –in output1 –out output1a –d
Enter des-cbc decryption password: (press a few random keys)
Q1.3.1: What happens when you type an incorrect password?
Now we will consider the case where the message went to the right person, who knows the
secret key:
# openssl des –in output1 –out output1b –d
Use the password: ECE4112
View and print the “output1b” file – Attachment #4
3
Now decrypt the 3DES message:
# openssl des3 –in output3
Use the password: ECE4112
–out output3a –d
View and print the “output3a” file – Attachment #5
Q1.3.2: Are attachments 4 and 5 the same?
Note: We will continue to use the “plain” file, so don’t delete it yet.
See Appendix A for more information about the DES command.
Section 2: Public Key Encryption - RSA
Be sure to read the lecture slides 13-21 to gain the background knowledge for this section.
2.1 Generate an RSA private key
Since the RSA algorithm requires a private key, we have to first generate one:
# openssl genrsa –out key
This generates an RSA private key file named “key” to be used in the RSA algorithm.
We can see the generated RSA key file by typing
# gedit key
Print this file – Attachment #6
See Appendix B for more information on genrsa function.
2.2 Encryption
Now that we have a private key, we can input this as well as a plaintext message into the RSA
function:
# openssl rsautl –sign –in plain –inkey key –out rsaout
Open and print the “rsaout” file - Attachment #7
2.2 Decryption
We are now ready to transmit the encrypted data.
Once this data arrives at its destination, it needs to be decrypted:
# openssl rsautl –verify –in rsaout –inkey key –out plain1
This places the decrypted data into a file called “plain1”.
View and print this file - Attachment #8
Q2.2.1: Is the “plain1” file the same as the “plain” file?
See Appendix C for more information on the rsautl function.
4
Section 3: Message Digest
A message digest can be thought of as a fingerprint for transmitted data. It uniquely
identifies the data using a set number of bits. This output is generated by a hashing algorithm.
There are many such algorithms, including MD5 and SHA-1. Message digests are useful in
that the sender only has to sign over the message digest instead of signing over the entire
message, which is computationally expensive. See the “Integrity” portion of the lecture slides
for further information on message digests.
3.1 MD5
We will now hash a message using MD5, which will output a fairly small message digest:
# openssl dgst –md5 –hex –out digest1 plain
This takes the “plain” file as input and stores the hexadecimal output in “digest1”.
View and print the “digest1” file - Attachment #9
Q3.1.1: How many bits is the output? Recall that each hex digit is 4 bits.
3.2 SHA-1 (Secure Hash Algorithm)
SHA-1 is another hash algorithm that creates a message digest for a given message.
Repeat exercise 3.2 with SHA-1:
# openssl dgst –sha1 –hex –out digest2 plain
View and print the file “digest2” – Attachment #10
Q3.2.1: How many bits is the output?
Q3.2.2: Based on the output, which of these do you think is a better hashing algorithm?
Why?
Q3.2.3: Is it possible to reconstruct the original message from either of the two outputs?
Why or why not?
See Appendix D for more information on the dgst function.
References
1. Kurose, Charlie and Ross, Keith. Computer Networking: A Top-Down Approach Featuring
the Internet. New York, NY: Addison Wesley, 2003.
5
APPENDIX-A
rsautl - Linux man page
openssl [Ciper type] [-out filename] [-in filename] [-pass arg] [numbits] [-e] [-d] [-a / -
base64] [-k][ -kfile][ -[pP]] [bufsize <n>] [-engine e]
OPTIONS
-out <file>
input file
-in <file>
output file
-pass <arg>
pass phrase source
-e
encrypt
-d
decrypt
-a / -base64 base64 encode/decode, depending on encryption flag
-k
key is the next argument
-kfile
key is the first line of the file argument
-[pP]
print the iv/key (then exit if -p)
-bufsize <n> buffer size
-engine e
use engine e, possible a hardware device
CIPHER TYPE
Des
: 56 bit key DES encryption
Des_ede
:
112 bit key DES encryption
Des_ede3
:
168 bit key DES encryption
Rc2
:
128 bit key RC2 encryption
Bf
:
128 bit key blowfish encryption
6
APPENDIX-B
genrsa - Linux man page
NAME
genrsa - generate an RSA private key
SYNOPSIS
openssl genrsa [-out filename] [-passout arg] [-des] [-des3] [-idea] [-f4] [-3] [-rand
file(s)] [-engine id] [numbits]
DESCRIPTION
The genrsa command generates an RSA private key.
OPTIONS
-out filename
the output filename. If this argument is not specified then standard
output is used.
-passout arg
the output file password source. For more information about the
format of arg see the PASS PHRASE ARGUMENTS section in
HYPERLINK
"http://www.die.net/doc/linux/man/man1/openssl.1.html"
openssl
(1).
-des|-des3|-idea
These options encrypt the private key with the DES, triple DES, or
the IDEA ciphers respectively before outputting it. If none of these
options is specified no encryption is used. If encryption is used a
pass phrase is prompted for if it is not supplied via the -passout
argument.
-F4|-3
the public exponent to use, either 65537 or 3. The default is 65537.
-rand file(s)
a file or files containing random data used to seed the random
number generator, or an EGD socket (see
HYPERLINK
7
"http://www.die.net/doc/linux/man/man3/rand_egd.3.html"
rand_egd
(3)). Multiple files can be specified separated by a OS-
dependent character. The separator is ; for MS-Windows, , for
OpenVMS, and : for all others.
-engine id
specifying an engine (by it's unique id string) will cause req to
attempt to obtain a functional reference to the specified engine, thus
initialising it if needed. The engine will then be set as the default for
all available algorithms.
numbits
the size of the private key to generate in bits. This must be the last
option specified. The default is 512.
NOTES
RSA private key generation essentially involves the generation of two prime numbers. When
generating a private key various symbols will be output to indicate the progress of the generation.
A . represents each number which has passed an initial sieve test, + means a number has passed a
single round of the Miller-Rabin primality test. A newline means that the number has passed all the
prime tests (the actual number depends on the key size).
Because key generation is a random process the time taken to generate a key may vary somewhat.
BUGS
A quirk of the prime generation algorithm is that it cannot generate small primes. Therefore the
number of bits should not be less that 64. For typical private keys this will not matter because for
security reasons they will be much larger (typically 1024 bits).
SEE ALSO
HYPERLINK "http://www.die.net/doc/linux/man/man1/gendsa.1.html" gendsa (1)
8
APPENDIX-C
rsautl - Linux man page
NAME
rsautl - RSA utility
SYNOPSIS
openssl rsautl [-in file] [-out file] [-inkey file] [-pubin] [-certin] [-sign] [-verify] [-encrypt]
[-decrypt] [-pkcs] [-ssl] [-raw] [-hexdump] [-asn1parse]
DESCRIPTION
The rsautl command can be used to sign, verify, encrypt and decrypt data using the RSA
algorithm.
COMMAND OPTIONS
-in filename
This specifies the input filename to read data from or standard input
if this option is not specified.
-out filename
specifies the output filename to write to or standard output by
default.
-inkey file
the input key file, by default it should be an RSA private key.
-pubin
the input file is an RSA public key.
-certin
the input is a certificate containing an RSA public key.
-sign
sign the input data and output the signed result. This requires and
RSA private key.
-verify
verify the input data and output the recovered data.
-encrypt
encrypt the input data using an RSA public key.
-decrypt
9
decrypt the input data using an RSA private key.
-pkcs, -oaep, -ssl, -raw
the padding to use: PKCS#1 v1.5 (the default), PKCS#1 OAEP,
special padding used in SSL v2 backwards compatible handshakes,
or no padding, respectively. For signatures, only -pkcs and -raw
can be used.
-hexdump
hex dump the output data.
-asn1parse
asn1parse the output data, this is useful when combined with the verify option.
NOTES
rsautl because it uses the RSA algorithm directly can only be used to sign or verify small pieces of
data.
SEE ALSO
dgst(1), rsa(1), genrsa(1)
10
APPENDIX-D
MD5 - Linux man page
NAME
dgst, md5, md4, md2, sha1, sha, mdc2, ripemd160 - message digests
SYNOPSIS
openssl dgst [-md5|-md4|-md2|-sha1|-sha|-mdc2|-ripemd160|-dss1] [-c] [-d] [-hex] [binary] [-out filename] [-sign filename] [-verify filename] [-prverify filename] [-signature
filename] [file...]
[md5|md4|md2|sha1|sha|mdc2|ripemd160] [-c] [-d] [file...]
DESCRIPTION
The digest functions output the message digest of a supplied file or files in hexadecimal form. They
can also be used for digital signing and verification.
OPTIONS
-c
print out the digest in two digit groups separated by colons, only
relevant if hex format output is used.
-d
print out BIO debugging information.
-hex
digest is to be output as a hex dump. This is the default case for a
``normal'' digest as opposed to a digital signature.
-binary
output the digest or signature in binary form.
-out filename
filename to output to, or standard output by default.
-sign filename
digitally sign the digest using the private key in ``filename''.
-verify filename
11
verify the signature using the the public key in ``filename''. The
output is either ``Verification OK'' or ``Verification Failure''.
-prverify filename
verify the signature using the the private key in ``filename''.
-signature filename
the actual signature to verify.
-rand file(s)
a file or files containing random data used to seed the random
number generator, or an EGD socket (see
HYPERLINK
"http://www.die.net/doc/linux/man/man3/rand_egd.3.html"
rand_egd
(3)). Multiple files can be specified separated by a OS-
dependent character. The separator is ; for MS-Windows, , for
OpenVMS, and : for all others.
file...
file or files to digest. If no files are specified then standard input is
used.
NOTES
The digest of choice for all new applications is SHA1. Other digests are however still widely used.
If you wish to sign or verify data using the DSA algorithm then the dss1 digest must be used. A
source of random numbers is required for certain signing algorithms, in particular DSA. The
signing and verify options should only be used if a single file is being signed or verified.
12
Answer Sheet Lab XX
Group Number: _______________
Member Names: _________________________
_________________________
Section 1: Symmetric Key Encryption – DES
Q1.2.1: Are attachments 1 and 2 different? Why or why not?
Q1.2.2: Is Attachment 3 different from Attachment 1? Why?
13
Q1.2.3: Do you think the output would be different if you repeated the 3DES exercise
with a different password?
Q1.3.1: What happens when you type an incorrect password?
Q1.3.2: Are attachments 4 and 5 the same?
Section 2: Public Key Encryption - RSA
Q2.2.1: Is the “plain1” file the same as the “plain” file?
Section 3: Message Digest
Q3.1.1: How many bits is the output? Recall that each hex digit is 4 bits.
14
15
Q3.2.1: How many bits is the output?
Q3.2.2: Based on the output, which of these do you think is a better hashing algorithm?
Why?
Q3.2.3: Is it possible to reconstruct the original message from either of the two outputs?
Why or why not?
16
General Questions
How long did it take you to complete this lab? Was it an appropriate length lab?
What corrections and or improvements do you suggest for this lab? You may cross out and
edit the text of the lab on previous pages to make corrections. What corrections and or
improvements do you suggest for this lab? Please be very specific and if you add new
material give the exact wording and instructions you would give to future students in the new
lab handout. You need to be very specific and provide details. You need to actually do the
suggested additions in the lab and provide solutions to your suggested additions. Caution as
usual: only extract and use the tools you downloaded in the safe and approved environment of
the network security laboratory.
17
Turn-in Checklist
You need to turn in.
 Screenshot 1~10
 Answer Sheet
 Any corrections or additions to the lab.
18