FBI Challenge

A Network World article led me to a challenge by the FBI. They had previously put out such a challenge last year. This year they are repeating the challenge with a harder puzzle. They have encrypted some text and encourage you to try to break the code. Here is the text of the code from the FBI web site:


The FBI also provides some background on ciphers. The first one they describe is the old Caesar cipher. Each letter is replaced with another one in the alphabet. You would think this would be too simple of a cipher for the FBI to use. But I thought I would try to write a program that is smart enough to tell whether some encrypted text Is using a Caesar cipher.

My plan was for the program to guess all possible Caesar cipher substitutions. Then it would use brute force to decrypt the text using each guess. The output would be checked against a dictionary to see if the result looked like English words. It would assign a score based on how many words are actually recognizable. The program would then choose the top scoring Caesar substitution set, and declare a victory if some threshold such as 90% of the words are good.

The problem with this plan was that I needed a dictionary for my program to rely on. More specifically, I needed a list of valid English words. You would think this would be an easy thing to find. However I only found lists that were split up among multiple files. Or I would find lists that contained a whole lot more than just words. So the very first task was to write a processing program that would accept some input I found on the Internet, and output a single file full of unique words in the English language.

When I get this done, I will share the code and list with you. Who knew that this was going to take such a long time? And I am only on the first simple Caesar cipher try.

About the Crypto API

Last week I read an article in CoDe magazine by Alex Feldstein about the Crypto API. This comes at a good time as I continue to study the C header file for this API. I was delighted to hear that there is a user manual for the Windows Crypto API. Unfortunately I do not know where to get it. I have since found the Crypto API documentation on the Microsoft Developer Network (MSDN). Perhaps that is the user manual.

Cryptography in general is the science of keeping messages secure. A hash is a function that can be applied to a plain text password. The client program can send the hash alone, thereby eliminating the need for sending the actual password. That makes sense. I think that is how Oracle authenticates database users with their passwords.

The Crypto API implements Public Key Cryptography functionality. This is also known as Asymmetric Encryption. It is also known as Public Key Infrastructure (PKI). You encrypt data with the public key. The recipient decrypts the data with their private key. A well known system for this is Diffie-Hellman. Some implementations of Diffie-Hellman are RSA, PGP, and Entrust.

Digital signatures also used public and private keys. The United States Government uses the Digital Signature Algorithm (DSA) from the US Digital Signature Standard (DSS). Although this does not fully explain these terms, at least I now know what some of these strange acronyms stand for.

The Windows Crypto API is implemented with a set of dynamic link libraries (DLLs). It is a part of Microsoft Windows. It has an abstraction layer. The Crypto API uses encryption servers called Cryptographic Service Providers (CSPs). The applications do not directly access the CSPs. They go through the Crypto API,. A session is established between the Crypto API and the client application. This session is the context needed for calling the API functions. You can export a session key to something called a key blob.

My next step is to continue pouring through the MSDN documentation on the Crypto API. There are a lot of topics under the Crypto API. I have been taking vigorous notes while I read through. So far I am up to 10 pages of notes. After I have finished reading, and have digested the information, I shall post further about it.

Crypto API Terms

I have previously written about my discovery of the C header file for the Microsoft Crypto API. There are many terms in this source file that are foreign to me. It is my goal to learn all I can to unlock these mysteries. I thought I would go over some more unfamiliar terms and discuss what little I know about them.

One realm has to do with Diffie-Hellman. I do know that these are the last names of two guys. However I do not know the details of their research. There were terms in the code such as KEA, SANDF, and EPHEM. These must mean something for this algorithm.

The code referenced different types of hashes. I recognized SHA which I have previously written about. However I did not know what MAC, RIPEMD, HMAS, or TLS1 were. The same thing goes for Secure Channel. I have heard about it. But I did not know what the “master” refers to. I suspect this has something to do with SSL. Again I am not sure.

There are a number of algorithm choices present in the code. I know about digital signatures using RSA. I might have heard about DSS digital signatures. However the terms SEAL, KEA, CYLINK MEK, and PCT MASTER were foreign to me. It is definitely time to study up.

Now I saw a section on Gen Key. My instinct tells me this has something to do with Netscape. If I had to guess, it must be a program or technique to generate random keys. However I want to be sure. In addition, I need to understand how the following terms apply to key generation: exportable, user protected, salt, SF, KEK, and volatile.

There was a section of code enumerating the types of “modes” available. I was not sure what they were talking about. I know I did not recognize the different values such as cipher block chaining, electronic code boo, output feedback, cipher feedback, and cipher text stealing. Only one of them sounded even vaguely familiar.

I did gain some tangible knowledge reading this source file “wincrypt.h”. Specifically it stated that Windows XP ships with a 128-bit encryption provider. And I read that the code is implemented in a file called “crypt32.dll”. I found out that OID stands for Object Identifier. However I need to know more than what the acronym stands for. I need to also learn what non-repudiation means. Microsoft is usually good with its documentation. My next stop is the Microsoft Developer Network (MSDN) for detailed info. As always I will share what I learn.

Crypto API

I was browsing the source code for one of our main applications. And I found a file that implements a C++ class for security. This file has a curious include of another file named "wincrypt.h". I have come to find out that this include file is the Microsoft Cryptographic API. I figured I could learn a lot by studying this file. Or more precisely, I could identify some topics from this file that I need to research further.

The file referenced the term "entrust" under the heading of RSA. Now I know that RSA is or was a company. But I am not familiar with what entrust is yet. I need to study up. The file also referenced the acronyms PKCS and DMS under the heading of DSS. Now I know that PKCS stands for Public Key Cryptographic Standards. However I am not confident of what DMS and DSS stand for.

There were DES block ciphers enumerated in the file. Some of them had names like DESX, IDEA, CAST, and RC5. Now I know that DES stands for Data Encryption Standard. And I have previously written about RC5 when I discussed SSL. However the other acronyms have no meaning to me. I am starting to get the feeling that just about everything relating to cryptography has an acronym name.

The header file also had some terms under the heading of Fortezza. They were SKIPJACK and TEK. Now I have written about how SKIPJACK is a block cipher. And I have also written about Fortezza when discussing SSL. However I am not sure what TEK stands for.

Sometimes I found that I really did not know what the heck the code was talking about. For example, there was a heading for a KP mode. I am at a loss since I do not even know what the group stands for. I do know that some terms for these modes I need to learn are CBC, CFB, OFB, interleaved, pipelined, and masking.

I was happy that most of the time I recognized the header for groups in the source file. For example, I know what a stream cipher is. Two such ciphers listed in the code were RC4 and SEAL. Previously I have written about RC4. However I have never heard about SEAL.

For now I plan to write another post about some more goodies I have uncovered in the Microsoft Crypto API header file. Long term I want to research the unknown topics and become very familiar with them. Perhaps it is time to get some training on this.

RSA Key Exchange

Previously I have written about the Secure Socket Layer (SSL). One method that SSL uses to negotiate the encryption between client and server is the RSA Key Exchange. There are multiple modes that the RSA Key Exchange algorithm can choose for encryption. I had already described the MD5 hash function and RC2 block cipher. Now let’s go over the other modes that RSA Key Exchange can decide upon.

A frequent choice is DES with 56 bit encryption and the SHA-1 hash function. DES stands for Data Encryption Standard. It is a cipher selected as an official Federal Information Processing Standard (FIPS). It is a symmetric algorithm meaning the encryption and decryption use the same key. RC4 is a stream cipher that has been called the most widely used software stream cipher. RC4 is also called ARC4. This cipher is used in wireless networks as well.

Another choice is Triple DES with 168 bit encryption and SHA-1 message authentication. This method has the strongest security. However that means it is not as fast as some other techniques. You can do the math and see that the key is three times longer than DES. It is also FIPS compliant. Triple DES is a block cipher that employs DES three times. IT is designed to prevent man in the middle attacks. Although it is very strong, Triple DES is being replaced by AES (Advanced Encryption Standard). The SHA-1 stands for Secure Hash Algorithm. It was designed by the National Security Agency.

That wraps up the modes that are available under the RSA Key Exchange. I thought I would also mention that SSL can use Fortezza. That is an encryption system used by the United States government. It calls for hardware based encryption of a classified cipher such as KEA or SKIPJACK. You get a PC card which stores private keys on it. Like the RSA Key Exchange, Fortezza provides different modes of encryption which can be negotiated.

One cipher suite used by Fortezza is RC4 with 128 bit encryption and SHA-1. This is very strong and difficult to crack. Another suite is RC4 with 128 bit encryption, SKIPJACK, and SHA-1. This is used for classified systems. It employs a symmetric key. SKIPJACK is a replacement for DES. It is also a block cipher, and was developed by the National Security Agency.]

This almost completes my overview of SSL. I wanted to get into the SSL Handshake and also the Man in the Middle Attack. Perhaps I can leave those as topics for future posts.