Trusted Solaris

Asymmetric Key Cryptography

One major limitation of symmetric key cryptography is that the same key is required to encrypt and decrypt data. This is fine for protecting individual files from unauthorized users, but many data protection scenarios require multiple users, and in many cases parties amongst which trust has never been established, to be involved. For example, if a manager in New York needed to exchange sales data with a manager in Buffalo, and this data required encryption, then both managers could simply share the key required to decrypt the data. However, this approach has two problems: first, users tend to apply the same password and key to multiple purposes, meaning that one manager might be able to access the other manager’s files; second, what if more than two managers were involved? Clearly, passing a password around a user group of 1,000 users is tantamount to having no security at all! A system is required that allows individual users to encrypt data using one key, and for the file to be decrypted using a separate key for each user.

Asymmetric encryption allows separate keys to be used for encrypting and decrypting data. How is this possible? Basically, every user is assigned a private key, which they never release to anyone else, and a public key, which is supplied to other users who need to send the user encrypted data. For example, the New York manager would have a private key stored on a floppy disk, locked in a safe, as would the Buffalo manager. Both would also exchange their public keys via e-mail, or another offline method such as floppy disk, verifying that the keys were genuine by using a key “fingerprints” check over the telephone. To encrypt a file for the Buffalo manager, the New York manager would need to use both the Buffalo manager’s public key and his own private key. Conversely, the Buffalo manager would need to use her private key and the New York manager’s public key to encrypt a file for him. Remember that if you exchange public keys via e-mail, and have no other method of verifying who is on the other end of the line, then you’re ripe for a “man in the middle attack,” because the person you think you are exchanging data with could be an intermediary. For example, imagine if Joe substitutes his key in place of his manager’s, and manages to place his machine between the manager’s machine and an external router. Now Joe is able to pretend to be his manager, issuing his own public key with his manager’s name for which he actually has the corresponding private key.

The most important feature (or limitation, depending on your requirements) of asymmetric key cryptography is that obtaining the private key used to encrypt data is not sufficient to decrypt that data: only the private key of the individual whose public key was used for signing can be used for this purpose. This can be very important in situations where data may be compromised in a specific location. For example, an embassy in a foreign country under threat of attack may decide to encrypt all data using the public key of an officer in the State Department in Washington, send it via e-mail, and then delete the on-site originals. Even if the encrypted data and the embassy’s private key were obtained by force, they could not be used to decrypt the data.

Of course, asymmetry implies that if you lose your original data accidentally, you must rely on the public-key holder’s private key to decrypt the data. However, at least there is one avenue of recourse available, unlike symmetric key cryptography, where a lost key almost certainly means lost data.

Public-Key Cryptography

One of the most commonly used “public key” systems that uses asymmetric keys is the Pretty Good Privacy (PGP) application (http://www.pgp.com/). PGP is available for a wide variety of operating systems, making it very popular among PC and UNIX users because data can be exchanged without conversion. PGP works both on the command line, to facilitate secure storage of files, and as a plug-in to e-mail programs, allowing messages to be exchanged securely. This ensures that intermediate mail servers and routers cannot intercept the decrypted contents of transmitted messages, even if they can intercept packets containing the encrypted data.

In order to use PGP, each user needs to generate their own public/private key pair. This can be performed by using the following command:

$ pgp -kg

The following prompt will be displayed:

Choose the type of your public key:
  1)  DSS/Diffie-Hellman - New algorithm for 5.0 (default)
  2)  RSA
Choose 1 or 2:

The public key format that you choose will determine what types of block ciphers can be used to encrypt your data. The DSS/Diffie-Hellman algorithm allows Triple DES, CAST, or IDEA, while RSA keys will only work with IDEA, so most users will want to select the DSS/Diffie-Hellman algorithm.

Next, you will need to select the key size:

Pick your public/private keypair key size:
(Sizes are Diffie-Hellman/DSS; Read the user's guide for more information)
 1)   768/768  bits- Commercial grade, probably not currently breakable
 2)  1024/1024 bits- High commercial grade, secure for many years
 3)  2048/1024 bits- "Military" grade, secure for foreseeable future(default)
 4)  3072/1024 bits- Archival grade, slow, highest security
Choose 1, 2, 3 or 4, or enter desired number of Diffie-Hellman bits
(768 - 4096):

Keep in mind that while a large key provides greater security, it also slows down operations significantly since it is CPU-intensive. Thus, if your needs are really commercial rather than military, you should use the 768- or 1,024-bit key. Military users should certainly select the largest key size available (currently 4,096 bits).

Next, you will need to enter a user ID. This should be recognizable by your intended recipients. For example, a programmer called Yayoi Rei from Rei Corporation would have a user ID of Yayoi Rei <<yayoi@rei.com>>. Even in countries where the family name is usually written first, the expectation for the key server is that the family name will appear last, followed by an e-mail address:

You need a user ID for your public key.  The desired form for this
user ID is your FULL name, followed by your E-mail address enclosed in
<<angle brackets>>, if you have an E-mail address.  For example:
  Joe Smith <<user@domain.com>>
Enter a user ID for your public key:

If you wish your key to be valid for a specific time period, you can enter its validity in days next. Alternatively, if the key is intended to be permanent, you can enter zero days:

Enter the validity period of your key in days from 0 - 999
0 is forever (and the default): 

A password will need to be associated with the private key for future use, and will need to be entered twice for verification:

You need a pass phrase to protect your private key(s).
Your pass phrase can be any sentence or phrase and may have many
words, spaces, punctuation, or any other printable characters.
Enter pass phrase:
Enter again, for confirmation:

Finally, a number of random numbers needs to be generated from the intervals between random key presses on your keyboard. Try to insert some variation in the key press latency to ensure security:

We need to generate 595 random bits.  This is done by measuring the
time intervals between your keystrokes.  Please enter some random text
on your keyboard until you hear the beep:

Once the key pair has been created, it is possible to list all of the keys on your local key ring by using the following command:

$ pgp -kl
Type Bits KeyID      Created    Expires    Algorithm       Use
sec+  768 0x71849810 2002-01-07 ---------- DSS             Sign & Encrypt
sub   768 0x78697B9D 2002-01-07 ---------- Diffie-Hellman
uid  Yayoi Rei <<yayoi@rei.com>>
1 matching key found

The key pair is now available for use. In order to generate a copy of your public key for your correspondents and colleagues to use, you will need to extract this from your key ring as follows:

$pgp -x Yayoi
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQFCBDw5+oURAwDBKeBtW+0PdDvCC7KO1/gUAF9X//uGRhbPkg6m83QzaA7pr6T+
QAVQE4q74NXFCakX8GzmhzHtA2/Hoe/yfpfHGHMhJRZHZIWQWTS6W+r5wHYRSObm
NNNTeJ4C+3/klbEAoP/Mjlim4eMkfvYwNmifTUvak5zRAv48SrXOHmVI+5Mukx8Z
lT7txut60VeYd34QvidwtUbbL7p2IVVa3fGW/gsuo7whb1aW//+5Z/+4wxbaqnu6
WxT5vFObm1sJ7E20OW3SDLxdVjeTlYbzTUfNwbN/KHoUzMsC/2EZ3aDB6mGZuDPL
0SMT8sOoxlbpPouuBxnF/sbcxgOVKkGZDS5XrhodUbp2RUflwFSMyqjbmoqITnNq
xzpSXEhT0odwjjq3YeHj1icBaiy9xB/j0CBXe3QQKAXk5bXMEbQZWWF5b2kgUmVp
IDx5YXlvaUByZWkuY29tPokASwQQEQIACwUCPDn6hQQLAwECAAoJEHCOVqNxhJgQ
riMAn18a5kKYaepNk8BEksMJOTbRgDQmAKC0JD6wvYfo5zmziGr7TAv+uFWN5LkA
zQQ8OfqHEAMA6zd3dxeMkyKJmust3S3IrKvQzMLlMoRuQdb+N2momBYDF1+slo8k
EMK8F/Vrun+HdhJW+hWivgZRhTMe9fm6OL7PDYESkwuQsMizqAJJ1JF0yhbfTwE5
GjdVPcUMyPyTAAICAwCgdBO1XyiPbwdQtjxq+8CZ7uchASvJXsU28OFqbLzNcAW2
Q64lWSs6qr2HNfgf+ikG8S8eVWVKEBgm6md9trr6CK25SYEu4oB3o1f45X4daa/n
iNytKUglPPOJMK/rhJOJAD8DBRg8OfqHcI5Wo3GEmBARAs3mAJ0ZPQjmlYyNsMDY
ZVbR9/q2xQl8gACgkqVCNYR40mPIaxrd5Cw9ZrHqlkQ=
=Gsmt
-----END PGP PUBLIC KEY BLOCK-----

To encrypt a file using standard, symmetric encryption, you simply pass the –c option on the command line along with the name of the file that you want to encrypt. This provides Solaris users with an alternative to crypt, where a more secure encryption algorithm is desired:

$ pgp -c secret.doc
You need a passphrase to encrypt the file
Enter pass phrase:
Enter same passphrase again
Enter pass phrase:
Creating output file secret.pgp

After entering a password to protect the data in secret.doc, the encrypted file secret.pgp is created. In order to sign the file for another user, the –e option needs to be passed, along with the name of the user from your key ring who will have the power to decrypt your data:

$ pgp -e Henry secret.doc
   4096 bits, Key ID 76857743, Created 2002-01-07
   "Henry Bolingbroke <<henry@bolingbroke.co.uk>>"
Creating output file secret.pgp

The file can then be transmitted to Henry by UUencoding it, sending it as an e-mail attachment, or by directly generating the file in ASCII format:

$ pgp -ea Henry secret.doc