Encryption and Digital Signatures

What is encryption/decryption?

Encryption is the act of passing readable data, referred to as “clear text”, and an encryption key through a formula that changes the clear text into a form that is unreadable to anyone who does not have the associated decryption key. The encrypted data is called “cipher text”. 

Decryption is the reverse or encryption, allowing anyone who has the associated decryption key to convert the cipher text to its corresponding clear text. Through the years there have been many iterations of encryption technology, but there are two encryption methods that are primarily used:

• Synchronous or “shared key” systems
• Asynchronous or “public key” systems

“Shared key” systems

Shared key systems are based upon standard formulas that have been available for quite some time, including the most widely accepted Advanced Encryption System (“AES”) and others, such as, the (old) Data Encryption Standard (“DES”), Triple DES (“3DES” – basically using the DES algorithm three times using one, two or three distinct keys), Twofish, Blowfish and many others. These systems require that the sender and the recipient of the information both share a single key that is used to encrypt and decrypt data. 

Conceptually, shared key systems are simple:

• Setup:
  • Create a key
  • Securely communicate it to the contact at the site with which you need to exchange data
• Sending encrypted data:
  • The sender runs program code that calls the function that calls the appropriate encryption function, passing it the clear text and the shared key and receiving back the cipher text
  • The cipher text is then sent to the intended recipient
  • Upon receipt, the recipient runs program code that calls the appropriate decryption function, passing it the cipher text and shared key. If the shared key is same as the one used for encryption, the decryption function returns the original clear text.
  • The clear text is ready for use

Since anyone who learns the shared key value can decrypt the cipher text, it is critical to ensure that the key is secured and is only shared on a need to know basis.  

Shared key systems usually have keys that are 64-bits, 128-bits, 256-bits in length. With these relatively small key sizes, shared key systems are very efficient but are easier to crack, especially 64-bit key systems.

While minimal effort is required to generate and maintain shared encryption keys if you are interacting with a small number of individuals or organizations, the level of effort increases geometrically as you add more sites with which you need to communicate securely.

“Public key” systems

Public key systems are based upon the work of Rivest, Shamir and Adelman who partnered to develop an encryption technique that effectively addresses the key management problems of shared key systems, especially in application scenarios involving many users, such as e-mail. These concepts were incorporated into products such as RSA, PGP (Pretty Good Privacy), GPG. 

Unlike shared key systems, public key systems are based upon the generation of two keys for each user or for each participating application system. 

Using a public key system, each user who expects to receive encrypted data is required to generate an encryption “key pair” before that can occur. The key pair is made up of:

• A “public key” that is intended to be used by anyone who needs to encrypt clear text data that will be sent to the owner of the key pair
• A “private key” that is used exclusively by the owner of the key pair to decrypt any cipher text that is received

Since the private key's purpose is to allow only the owner of the key pair to convert the received cipher text into readable, clear text, he or she must protect the private key with a strong password and must store it securely. But because the public key is needed to encrypt any piece of clear text data that is intended for a specific recipient and cannot be used to decrypt the protected cipher text, it can be freely shared with any potential sender and can even be stored in a public directory.

Public key encryption products usually have a built-in facility the stores the public keys of any individuals to whom encrypted data must be sent. These facilities have names, such as a “key ring”, a “key store”, etc. Some products can also use external directories, such as Microsoft’s Active Directory and others, to store the keys.  

Public keys are often shared by the owner of the key pair with anyone who needs to send him or her protected data, simply by e-mailing the key. Upon receipt, the recipient merely needs to run a program to copy the public key into his or her local key storage. Within organizations where a central work group generates key pairs for users who require public key encryption, the work group may just store each generated public key into the organization’s central directory system.

In a nutshell, here is the sequence of events in a typical public key encryption scenario:

• Set up
  • Each potential recipient generates a key pair
  • If a central directory is not being used to manage public keys, the owner of each key pair sends his or her public key to any potential senders of protected data
  • If a central directory is being used to manage public keys, the owner of each key pair sends his or her public key to an administrator of the central directory who will add the public key to the key owner's directory record
• Sending encrypted data
  • The sender selects the public key of the intended recipient from his or her key store or the organization’s central directory system
  • The sender runs program code that calls the encryption function, passing it the clear text and the recipient’s public key
  • The cipher text is then sent
  • Upon receipt, the recipient receives the cipher text
  • The recipient unlocks his or her private key by providing the appropriate password or passphrase
  • The recipient runs the program code that calls the decryption function, passing it the cipher text and his or her private key
  • The clear text is ready for use

Many public key systems are actually hybrids

Public key systems use very large key lengths, e.g., 1024-bit, 2048-bit, which makes them far more difficult to crack than the shared key systems, but they also use more computing power. As a result, many public key products are actually hybrid systems, utilizing the key management benefits of public key technology with the speed and efficiency of shared key encryption techniques. The way that the two technologies are married is simple and straightforward:

• The public key setup and key exchange procedures are performed in the manner described in the above section
• When two individuals initiate an encrypted data exchange, one of the systems generates a one-time shared key, called a "session key," and securely exchanges it with the other system using public key cryptography. The most common protocol that is used to exchange the session encryption key is called "Diffie-Hellman Key Exchange".
• The sender’s system uses the generated session key to encrypt the clear text data to be sent
• The sender’s system sends the cipher text to the recipient’s system
• Upon receipt, the recipient’s system decrypts the cipher text using the generated session key
• The clear text is ready for use

Note - the above steps are all performed by the software and are completely transparent to the end user requiring little involvement.

Digital signatures

Another significant benefit provided by public key technology is to make digital signatures possible. The term “digital signature” does NOT refer to an electronic rendering of a handwritten signature. Rather, a digital signature is a piece of data appended to the message that is considered a proof of identity because the signer was able to encrypt a value using his or her private key that he or she must unlock by providing the appropriate passphrase or password that only he or she should know. 

The way digital signatures work is as follows (this assumes keys already have been generated and distributed to recipients who need to confirm the authenticity of the data):

• The owner of the key pair runs the program code that “signs” the data, passing it the data to be signed and his or her private key that he or she has unlocked with his or her password or passphrase
• The program code passes the data through a hashing formula to obtain a fixed length value, called a “hash”
• The hash is encrypted using the key pair owner’s private key
• The data and hash are packaged and transmitted to the intended recipient
• Upon receipt, the recipient runs the program code that verifies the digital signature, passing it the received data, the hash, and the sender’s public key
• The program code decrypts the received hash using the sender’s public key
• The program code recalculates the hash from the received data
• The program code compares the received and recalculated hashes
• If the two hashes match, the data can be considered validly signed

Since a change to just one data character in the message would change the hash completely, this form of digital signature technology can also verify that the data content has not been altered after the signature was applied.