Tales From The Crypto - Part I

Think of this series of tips as a very simplified explanation of current encryption technologies, with some suggestions

for specific situations thrown in.

Problem Number 1: Your host application needs to exchange "private" data with another application somewhere out there on the Internet.

Tip: Consider symmetric or private key cryptography where both sender and receiver share a hopefully secret key. The algorithm to encrypt (scramble) and the algorithm to decrypt (unscramble) are both publicly known. The secrecy is strictly in the key and not in the algorithms.

Example: You want to send data "CAT". You and recipient share a secret key

3. A rudimentary form of encryption might be to promote every letter in the data by the key amount (if necessary, letters wrap at "Z" back to "A"). Demoting does decryption. You promote "CAT" by 3 and send "FDW". The recipient decrypts "FDW" by demoting each letter by 3 to get back "CAT". Voila!

Note: This is the actual encryption technique that Julius Caesar used!

Problem Number 2: Your host application needs to exchange data with more and more applications or users on the web. The exchanging of secret keys is getting quite cumbersome and even losing the security it once had.

Tip: Consider a newer form of cryptography, called asymmetric or public key cryptography. It eliminates the need to exchange or share a secret key between every two parties wishing to communicate privately. In public key cryptography every participant has a pair of keys: a public key anyone can know and a private key that should be, err, private There is a complex mathematical relationship between the two keys such that data encrypted using one of the keys can only be decrypted by using the other key. The same publicly known algorithm is used to both encrypt and decrypt. Again the secrecy is solely in the private key and not the algorithm.

Example: You want to send "NOW" to a user who has public key 6 and private key 20. The algorithm is to simply promote each letter by the key amount. You promote the letters in "NOW" by 6 and sends "TUC". Recipient promotes "TUC" by 20 to get "NOW" as you intended.

Note: A hundred users wishing to hold secure two-party conversations need one key pair each for a total of 100 key pairs, or 200 keys. With private key the hundred users need to share a secret key with each of the other ninety-nine for a total of almost 5000 keys. Key management becomes a nightmare, and security can go out the window.

Problem Number 3: How can you or some user on the web be sure of incoming data's integrity? Has it been corrupted or modified in transit?

Tip: Use a checksum or hash of the data. The receiver can calculate the hash of the data using a publicly known hashing algorithm and verify the hashes match. If even a single bit of data or hash has been altered, inserted or deleted the hashes would differ. Here's a simplistic hashing example: Substitute numbers for letters, and add all the letters, then convert back to letters ("ABC" hashes to "F" because 1+2+3 = 6). If hashing goes past "Z" (26) you wrap back to "A".

Example: As before you want to send "NOW" which encrypts to "TUC" using recipient's public key 6. You calculate the hash of "TUC" which is "R" (20+21+3 = 44 = 18) and send both "TUC" and "R". Recipient calculates hash of "TUC" and gets the same hash "R". No corruption. Recipient decrypts "TUC" using recipient's private key 20 and gets "NOW". Everybody's happy.

Problem Number 4: How can recipient be sure the data and corresponding hash didn't come from someone else pretending to be you?

Tip: Digitally sign what you are sending. That means you send data encrypted with the recipient's public key followed by the hash encrypted with your private key.

Example: Your private/public key pair is 8 and 18. As before you want to send "NOW" which encrypts to "TUC". The hash of "TUC" is "R". This time you also encrypt "R" using your private key 8 and get "Z". Send both the encrypted data "TUC" and the encrypted hash "Z". Recipient uses your public key 18 to decrypt the "Z" and gets "R". Recipient calculates hash of "TUC" and gets the same hash "R". Recipient knows data was not corrupted and that you must have sent it since your private key was used. Since you have digitally signed the transmission you cannot later repudiate that fact. Recipient decrypts "TUC" using own private key 20 to get "NOW".

In reality cryptography is far more complex. Symmetric keys are usually 40, 56, 80, 168, or more bits. Public keys are 512, 1024, 2048, or more bits. The mathematical relationship in a key pair is far more difficult to discern than the "they add up to 26" rule above for key pairs 6/20 and 8/18. Hash values are usually at least 4 or 8 bytes. There are brute-force and sophisticated attacks that can defeat secrecy but not in a computationally feasible amount of time. That means it may take legions of supercomputers many, many months or even years to decode a message encrypted with large key sizes. The encrypted data is cryptographically secure.

As complex as cryptography is, there are numerous programming API's, tool boxes, libraries, source code, etc. from IBM and many other Internet sources that make a developer's life much easier. These tools will let you incorporate these security methods into your application programs. For example, IBM has many procedures available under OS/390, such as:

CALL 'ENCRYPT' USING MY-DATA, DATA-LEN, RECIPIENT-PUBLIC-KEY. CALL 'SEND' USING MY-DATA, DATA-LEN. CALL 'HASH' USING MY-DATA, DATA-LEN, HASH-VALUE. CALL 'ENCRYPT' USING HASH-VALUE, HASH-LEN, MY-PRIVATE-KEY. CALL 'SEND' USING HASH-VALUE, HASH-LEN.

Public key cryptography has one disadvantage. It is drastically more computationally intensive than private key cryptography. It's simple to get around this drawback during a transmission between computers over the Internet. Both ends use public key cryptography initially to communicate and agree on a temporary shared key. That key is used with private key cryptography for the rest of the transmission.

About the author:
Jim Keohane (jimkeo@multi-platforms.com) is president of New York consulting company Multi-Platforms, Inc. His company specializes in commercial software development/consulting with emphasis on cross-platform and performance issues.


Related book

Personal Encryption Clearly Explained
Author : Peter Loshin
Publisher : AP Professional
ISBN/CODE : 0124558372
Cover Type : Soft Cover
Published : Oct. 1998
Summary:
This book is a hands-on guide for effectively using cryptography and encryption. It opens with an introduction to the concepts of modern encryption: secret-key encryption, public key encryption, digital signatures and user authentication mechanisms. The book then moves into why encryption is necessary, how it can be used to protect information at the individual level, and how the new cryptographic technologies are implemented in both software and hardware. Key to the book is how to efficiently set-up a personal encryption system, and how to use it to protect yourself while browsing the Web, sending and receiving e-mail, or using any Internet application.


This was first published in August 2000

Dig deeper on PKI and Digital Certificates

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close