Juan Ortega
7/1/11
MSE506
Cryptography Project and Report
Secret Key (Symmetric) Encryption - DES
One of the most well-known symmetric encryption algorithms has to be the Data
Encryption Standard (DES). Before DES, there was no accepted standard encryption 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 with a reputation of keeping
secrets – 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 Security 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 back-door function in the algorithm, others say because NSA’s
supercomputers we’re not 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 power 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 developed
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 line 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 generated 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 file 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 file 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
large.open file and encrypted it to get a 2.5Mb large.close file. Both files 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 observable 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 patterns 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 used since
upon writing the document, a new type of encryption algorithm [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 policy.” 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 modern symmetric 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
available 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 was developed by Rivest, Shamir, and Adleman who respectfully called it
RSA. Published 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 protocols 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 readline functionality. 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). The 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 process 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
desirable functionality. I have used the time program on Linux, and GPG to encrypt/decrypt
files. The time program that ships default on all UNIX systems displays the amount of time the
specified program took to execute and finish; by combining this with the GNU Privacy Guard
(GPG), I am able to see the amount of time it took to encrypt/decrypt. Commands used:
$ gpg –gen-key
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 –cipher-algo 3DES –c <file>
Uses the symmetric 3DES algorithm to encrypt the file; the user would have to enter a
passphrase.
$ gpg –output <file> –d <file>.gpg
This command decrypts the cipher file. The user again enters the passphrase.
$ time <above gpg command>
The time program shows how long the program [GPG] took to finish.
Table of results:
RSA – 1024 bit key
Encryption
-Size of File- -Time Elapsed-
3DES
Decryption
Encryption
Decryption
-Time Elapsed-
-Time Elapsed-
-Time Elapsed-
72Mb
10.454s
11.942s
18.546s
11.942s
166Mb
38.713s
22.012s
44.654s
22.552s
332Mb
1m15.018s
31.597s
1m13.203s
1m19.657s
617Mb
2m11.306s
1m4.283s
2m35.659s
2m28.897s
The results were not what I expected. Other programs and resources running on my
system might have affected the results. I have used 3DES instead of the regular DES because
GPG no longer supports it. The results for RSA were not consistent; encryption took much
longer to compute than decryption as seen from the third file with 332Mb having the biggest
difference 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 longer for a symmetric like 3DES.