Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Programming Public Key CryptoStreams, Part 1

Programming Public Key CryptoStreams, Part 1

Cryptology is the study of cryptography and cryptanalysis, the theory and practice of analyzing cryptography. Public key cryptography, which uses a different key for encryption than for decryption, provides data security and privacy with technical features that are ideally suited to network computing. In the next two newsletters, I’ll look at creating and managing cryptographic keys and I’ll show how data security can be achieved using a public key CryptoStream in C# to encrypt and decrypt data using IO streams.

Complex programmable computers with bloated operating systems are nearly impossible to fully protect from malicious tampering. To ensure optimal data security, one need only to generate random encryption keys, use them to encrypt data, save the encrypted data (ciphertext) to a reliable storage device (backup tape, for instance), write the encryption keys on a piece of paper, and then destroy the computer that was used to perform the encryption (at least destroy its storage devices and nonvolatile RAM). This guarantees that all copies of the encryption keys, other than the printed copy, are destroyed. Even if malicious code was present on the encrypting computer and it managed to intercept the encryption keys, the unauthorized copies made by the malicious code get destroyed when the computer is destroyed. Without a communications device connected to the computer, there are only three ways for a third party to obtain the original unencrypted data (plaintext). Even optimal data security with encryption leaves the following three points of vulnerability:

  1. Encryption can be broken through cryptanalysis.
  2. A third party can intercept the paper copy of the encryption keys.
  3. An eavesdropper in a remote location with extremely sensitive listening devices designed to pick-up electromagnetic radiation (called TEMPEST or EMSEC) can observe the computer during encryption.

Computer security threats plague even the best software-based cryptographic systems. It is presently impossible for us to know whether malicious or flawed code is in control of a trusted computer system that we rely on to encrypt sensitive data. Assuming that the encrypting computer is shielded to guard against EMSEC as well as protection from someone simply looking over your shoulder, it’s irrelevant whether there happens to be malicious code executing while key generation and encryption occur. Resistance to decryption through cryptanalysis, the theory and practice of solving cryptographic systems, and the safety of physical storage for the paper copy of the encryption keys determine the effective degree of data security.

Managing Trust in Cryptography

It may be impractical for your organization to implement an elaborate EMSEC policy including purchasing expensive EMSEC-hardened computer equipment from a government-approved vendor. And it would be absurd to toss hard drives into a furnace after each use, but the mental exercise is important so that you can evaluate how close you come to achieving optimal data security with any cryptography you deploy. Data encryption must typically be performed in a trusted environment where the plaintext is not accessible to malicious code. The Catch-22 of encryption is that when trust is compromised, so too are encryption keys, thus rendering pointless any future encryption and unlocking all existing ciphertext produced in the past using those same encryption keys. That is, when the encryption employed uses a symmetric encryption algorithm, where the same key is used for both encryption and decryption, the computer that applies the encryption must never become compromised or else its encryption keys and all data security are also compromised. Encryption applied using a symmetric algorithm in an untrustworthy environment is either untrustworthy or pointless. If untrustworthy is good enough, why bother with encryption? Conversely, why bother with encryption if you know you can trust your computing environment?

The Secure Sockets Layer (SSL) protocol was developed to implement encryption for untrustworthy settings like the Internet. The SSL protocol employs symmetric cryptography to encrypt and decrypt data so that third parties who do not have control over either the client or the server but who do have the ability to eavesdrop on the network are unable to decipher the content of the communication. Since symmetric encryption is employed for privacy by SSL, both client and server must have a copy of the encryption key. To exchange the symmetric key across the untrustworthy network, SSL uses the RSA asymmetric encryption algorithm (where there are different keys for encryption and decryption), discovered by three researchers at MIT—Rivest, Shamir, and Adleman—in the 1970s. The RSA algorithm is used in SSL for key exchange but not for bulk data encryption because of the amount of time it takes to compute the decryption transformation from ciphertext to plaintext using the RSA algorithm. Even a fast computer by modern standards can require over 60 seconds to decrypt 1 MB of RSA ciphertext produced using a 1024-bit key. RSA encryption is computationally easy relative to decryption, with the same computer able to encrypt 1 MB of plaintext in about 4 seconds with a 1024-bit key. This encryption speed is nearly adequate for real-time data security if the computer doing the decryption is 15 times as powerful as the one doing the encryption. Of course, this assumes that the full resources of both computers are devoted to the task of encryption and that encryption tasks aren’t performed in parallel. Hardware encryption accelerators can further speed up both sides of the equation, but the cost to scale is prohibitive as parallel demand grows.

It is important to draw a distinction between encryption for the purpose of privacy to guard against eavesdroppers and encryption for the purpose of data security to protect data from unauthorized access. The former is the goal of SSL, while the latter is left to the client and server to implement in application-specific ways. It is this type of encryption for data security that is too often skipped when developers create automated data processing applications because of the Catch-22 of symmetric encryption. If the application needs automated access to data, then it must be able to automatically encrypt and decrypt that data, meaning it must have a copy of the symmetric encryption key. Any third party who gains control over the computer also gains control over the key. As a result it’s far more important to restrict unauthorized access to sensitive computer systems than to go through the motions of encryption and decryption automatically with a symmetric key algorithm. Adding encryption does little to increase data security because ultimately, that security hinges on protecting the computer from unauthorized access.

Symmetric encryption decreases the likelihood that unauthorized third parties can gain access to data by ensuring that a copy of the symmetric key is in the possession of any person or computer that reads the data. Possession of a copy of the symmetric key functions as an authentication credential. The key provides proof that the person or computer is authorized to access the plaintext data, assuming the key is kept secret. Without the symmetric key, access to the data is denied due to the fact that the ciphertext is unintelligible without lengthy and complex cryptanalysis. Symmetric encryption that is applied on-demand by a human user offers security that can be considered superior to symmetric encryption performed automatically by any computer application. We will always be faced with practical risks of key management in our automated systems that we don't have to contend with when keys are controlled exclusively by human users. A third party attacker may find it easier to break into a computer and take control of an application that can automatically decrypt ciphertext than to break the will of a human and compel them to reveal the secret encryption key.

An automated system that must overcome this Catch-22 must encrypt plaintext data in such a way that even the encrypting system itself is incapable of decrypting it. Asymmetric encryption algorithms provide a way to transform plaintext into ciphertext using an encryption algorithm and a key that are useless for decryption. There are many reasons that an application might need to automatically encrypt data that it has no business ever automatically decrypting. By using asymmetric encryption, all ciphertext is completely secured from unauthorized decryption, even if a third party gains control over the computer that performs the encryption and intercepts the ciphertext. Symmetric encryption is useful to protect data on demand, where only an authorized user with a copy of the encryption key can decipher and use the data and the key is never stored on the computer for it to use later in automatic decryption. But only asymmetric encryption can provide optimal data security for automated systems. Automated symmetric encryption is good for privacy, but does little to enhance data security. Ciphertext produced by an automated system using symmetric key encryption must not be stored in a location that is accessible to the automated system or there is a perpetual risk that system’s security will be compromised, its secret symmetric keys intercepted, and all ciphertext produced by the system easily decrypted. Asymmetric cryptography is a viable solution to these data security problems.

Applying Public Key Cryptography to Data Stream Encryption

Cryptographers Diffie and Hellman are credited with conceiving a cryptographic algorithm where the user generates a pair of keys and keeps one private but reveals the other key in the public. Encryption performed using the public key produces ciphertext that can be decrypted only with the private key. Thus asymmetric cryptography became known as public key cryptography and is sometimes referred to as Diffie-Hellman public key cryptography. The RSA algorithm was licensed exclusively to RSA Security Inc. by MIT in 1983. Recently, on September 6, 2000, two weeks before MIT’s patent was set to expire, RSA Security announced that it was placing the patent in the public domain to clearly explain its view that the algorithm was no longer its protected intellectual property and anyone was free to use the invention for any purpose. On September 20, 2000 the RSA patent expired.

Public key cryptography is much slower than symmetric key cryptography. As a result, public key encryption is commonly used only for symmetric key exchange as in the SSL protocol. But public key encryption does work for bulk encryption and it provides unmatched data security for automated systems. Consider how a malicious attack might occur against a system that employs symmetric encryption. One option is to intercept only the symmetric key at the point of encryption and then intercept a copy of the ciphertext at a later time. Another option is to intercept the plaintext before encryption occurs. The symmetric key is usually very small compared to the plaintext data, so the preferred attack would be to intercept only the key at the point of encryption since intercepting all of the plaintext would require more effort and more likely produce signs of theft and system penetration. If 10 GB of plaintext are being encrypted using a 128-bit symmetric encryption key, malicious code has a much higher chance of intercepting the 128-bit key and transporting it to the attacker without being detected than dumping a copy of the plaintext out to a file or a network stream. Theft of the encryption key does nothing to impact data security in asymmetric encryption because the encryption key is not used for decryption. Stealing the plaintext before it is encrypted is the only option for an attacker, so the complexity of the attack is increased substantially. Countermeasures are possible to detect and halt the theft of large amounts of plaintext that just aren't possible to defend against theft of small symmetric encryption keys. Symmetric encryption keys can literally fly out a window; transported to an attacker via cellular network or just leaked as electromagnetic radiation. Applying public key cryptography to bulk encryption is the solution to the problem of key theft and undetected malicious third-party control over automated systems that must achieve optimal data security. In the next newsletter, I'll show a C# example that applies the RSA public key encryption algorithm to the task of file encryption using IO streams.

Jason Coombs works as forensic analyst and expert witness in court cases involving digital evidence. Information security and network programming are his areas of special expertise. He can be reached at [email protected].

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.