Cryptography Project and Report

twisterskyhighAI and Robotics

Nov 21, 2013 (4 years and 7 months ago)


Juan Ortega



Cryptography Project and Report

Secret Key (Symmetric) Encryption


One of the most well
known symmetric encryption algorithms has to be the Data
Encryption Standard (DES). Before DES

there was no acce
pted standard encryptio
n method;

this left individual companies to develop their own proprietary algorithms each claiming to be
more secure than the other. Everyone needed an algorithm that was tested by someone they
can trust, and who better to trust than a government agency wi
th a reputation of keeping

the NSA. To help in the development, in 1972 the National Institute of Standard and
Technology (NIST) settled on a cryptographic algorithm submitted by IBM named DES. NIST
requested the assistance of the National Securi
ty Agency (NSA) to be tested and full proofed.
The original key algorithm was 128 bits, but NSA shortens it to 56 bits. Some claim this was
necessary for NSA to install a

function in the algorithm, others say because NSA’s
supercomputers we’re no
t up to the task of cracking 128 bit keys. DES was adopted as the
federal standard for unclassified documents in 1977 and lasted up until 2000 where NIST
selected the Rijndael algorithm to be renamed to Advance Encryption Standard (AES). With
computer powe
r doubling every 18 months, a 56
key key could be brute
forced by today’s
computers in a short amount of time. The DES algorithm was fine, no practical holes have been
found only the small key was the problem. To combat this, the new Triple DES was develop
using 2 separate keys generating a 168
bit key effectively prevent most brute force attempts.

CryptTool is a very powerful tool used for cryptography and cryptanalysis. As you can
see from the small screenshot above, the tool was used to encrypt a li
ne of plaintext under the
window Unnamed1. The lab procedure is very similar to this. Decryption of the ciphertext can
be accomplished by navigating Encrypt/Decrypt
> Symmetric (modern)
> DES (ECB) and by
entering the correct key; otherwise the tool can
also brute
force the key by conducting a
cryptanalysis, but this would require a fair amount of time.

Onward to the actual procedure, the Java applet was successfully able to encrypt and
decrypt text in the notepad by generating a random 64
bit key. This
is a simple way to
demonstrate the ability to hide text using keys like a lock. By following the procedure, I opened
up the Windows command prompt, navigated to the unzipped DES folder and typed in “java
des” to bring up the applet. Then I have first gener
ated the random key, then opened up
notepad and typed some text inside the file. After saving the file with an .open extension, I used
the Java applet to look for the file, and hit the encryption button. One quick note, the applet
only works if the .open f
ile with text is in the same directory as the applet itself; do not know
why this is necessary. A new file with the extension .close appeared. I opened the new file, and
inside it were random characters not viewable by the notepad. Decrypting the .close fi
le took
the same steps as encrypting it, by entering the right key again and hit decrypt button.

To answer the question as to which ZIP file would be bigger, I have created a 2.5Mb file and encrypted it to get a 2.5Mb large.close file. Both fil
es are the exact same
size, but differ greatly when compressed. Upon a successful ZIP compression, the plaintext
deflated 99% down to a mere 28K file, the ciphertext on the other hand deflated only 11%
down to 2.2M. Compressors [like ZIP] work by finding o
bservable patterns in the text, it would
be like replacing all

words and characters
with the number of times each gets repeated
. ZIP had
difficulty compressing a ciphertext because all the characters where indistinguishably random,
thus very little pattern
s were present. Of course other algorithms handle lossless compression
better for ciphertext.

The Standard A.12.3.1, ISO/IEC 27001 Information Security Management Systems
Requirements does not implicitly say what type of symmetric encryption should be use
d since
upon writing the document,
a new type of encryption


considered to be more secure

would become available. It does include however, “Key management procedures depend on
the algorithm used, the intended use of the key and the security poli
cy.” As stated previously
DES is really old [1977] and should be considered obsolete. Organizations implementing
encryption for the confidentiality, integrity, and availability of resources should look at DES’s
successor Triple DES, and the many other mode


encryption algorithms.

Public Key (Asymmetric) Encryption

Unlike symmetric key algorithms were only one private key is used for both encryption
and decryption; asymmetric keys use two keys, a private and public key. The public key
is freely
vailable to everyone and anyone; this is because the public key is used for encryption. The
private key however must remain private, as the private key is used for decryption.

The first
asymmetric algorithm


by Rivest, Shamir, and Adleman who
respectfully called it
ublished in the late 1970s, RSA withstood the
bombardment of time by factoring larger
and large prime numbers to produce larger keys, and today it is
one of the most popular
authentication methods used for electronic commerce p
rotocols throughout the Internet

The lab procedure is relevant to the first DES lab with some minor differences. Unlike
the first lab, the RSA applet did not have a simple to use point and click GUI; rather it presents
the user with a

ity. By starting the command prompt and navigating to the
RSA extracted directly, I was able to start RSA with ‘java RSA 512’. This generated two prime
numbers, and with those a public and private key was formed.
The java applet then requested a
message to

be typed (plaintext) to be encrypted with the public key (ciphertext). Th
e next part
of the lab was a bit tricky as I am not aware of a tool or site where it displays the amount of
time it took to encrypt/decrypt a message.

In theory, the decryption proc
ess should take longer to compute than the encryption
process; but this all depends on the size of the modulus. Because of the lack of tools that
display the time elapse of computation, I had to use two programs together to achieve the
ity. I have used the

program on Linux, and GPG to encrypt/decrypt

time program that ships
default on all UNIX systems displays the a
mount of time the
specified program took to execute and finish
; by combining this with the GNU Privacy Guar
(GPG), I am able to see the amount of time it took to encrypt/decrypt.

Commands used:

$ gpg


This command creates the public and private keys to be used with RSA.

$ gpg

output <file>.gpg

recipient ‘<email address>’
encrypt <file>

This command

uses RSA to encrypt a file using the public key generated.

$ gpg

output <file>
decrypt <file>.gpg

This command decrypts

the RSA encrypted file.

$ gpg

algo 3DES

c <file>

Uses the symmetric 3DES algorithm to encrypt the file; the user would have

to enter a

$ gpg

output <file>

d <file>

This command decrypts the cipher file. The user again enters the passphrase.

$ time <
gpg command>

The time program shows how long the program [
] took to finish.

Table of results:


1024 bit key


Encryption Decryption



Size of File

Time Elapsed

Time Elapsed

Time Elapsed

Time Elapsed





















The results were not what I expected. Other programs and resources running on my
system might have affected t
he results. I have used 3DES instead of the regular DES because
GPG no longer supports it. The results for RSA were not

took much
longer to compute than decryption as seen from the third file with 332Mb having the biggest
overall. The difference in 3DES were somewhat more consistent; being a symmetric
key, the time elapsed should be the same.
Overall the results showed it takes longer to encrypt
a file for

an asymmetric like

RSA, and somewhat



a symmetric like