Database Reference
In-Depth Information
C H A P T E R 5
Public Key Encryption
I'm sure you've heard of public key encryption (PKE). You probably use it every day—if not in your code
or on your servers, then on the Internet. When you use secure socket layers (SSL) in your browser or
when you see the lock or key symbol and see
https:\\
(with the s) as the protocol in the address bar, you
are using PKE and other encryption. SSL is used to send private data such as your credit card number in
encrypted form to online merchants.
The basic concept of PKE is that two entities share a set of two keys (one public and one private) and
use them to encrypt data for and decrypt data from each other. The keys are tied to one another so that
anything encrypted with one of the pair (e.g., the private key) can only be decrypted with the other (e.g.,
the public key). This encryption/decryption works in both directions.
The most important aspect of PKE is that one of the keys is private. The private key is never
disclosed to anyone; however, the public key can be given to any and all requestors. How does this help
privacy?
The one requesting the public key can be sure that if that key successfully decrypts data, then it
came from the entity with the private key. Only the private key can encrypt data that can be decrypted
with the public key.
The converse is also true: only the public key can encrypt data that can be decrypted by the private
key, so the one using the public key can be sure that only the entity with the private key can decrypt data
that they encrypted.
Because the public key is, well, public, anyone can decrypt data sent from the originator. Also
anyone can encrypt data and send it to the originator for decryption. This is not a flaw, but it is an aspect
of PKE that we need to be aware of and account for.
Generate Keys on the Client
We will have the client computer generate a set of keys. That computer will send artifacts (components)
of the public key to the Oracle database so that Oracle can build a copy of the public key. Then the
Oracle database can encrypt data using the public key that only the originating client can decrypt.
This approach may sound like a complete solution, but there are a couple concerns that we will not
address until we get to the next chapter's discussion on secret password encryption. First, anyone can
read the public key artifacts as they traverse the network (that is, anyone with software to read all
packets going across the network, like a sniffer.) That means that we have to assume that everyone has
the public key and that everyone sees and can decrypt data (if any) that the client encrypts with the
private key and sends to the server.
The second concern is that PKE, at least the version we are using, does not lend itself to encrypting
large amounts data. It is a block cipher with a limited block size. For example, if the block size for our
PKE keys is limited to 128 bytes, we would have to break the data into portions of that size and encrypt
each portion individually. On the other side of this transaction, the recipient would have to decrypt each
portion and reassemble the original data.