What Is an Electronic Signature?
Bruce GottliebPosted Friday, June 16, 2000, at 3:37 PM ETThe House and Senate passed a bill this week that permits the use of so-called electronic signatures to form legally binding contracts, and President Clinton has agreed to sign it. It sounds like a good idea, but what's an electronic signature?
Oddly enough, the bill doesn't say. In the language of its supporters, the bill is "technology-neutral." In other words, it's up to the participants to agree on a format.
Under the law, you could use a very simple technology, such as merging a scanned handwritten signature into the electronic text of the contract. That is certainly no less secure than the common practice of secretaries' reproducing their bosses' signatures with customized rubber stamps.
But a far more secure practice--which seems almost certain to become the industry standard--is to use so-called public-key encryption technology. Here's how it works. Every company that wants to use electronic contracts develops a private key and a public key. The keys are actually small computer programs that translate between text and a series of numbers. The private key translates text into numbers, and the public key translates numbers back into text. For instance, the private key might translate the words "the party of the first party" into a series of numbers like "1837456384." And the public key translates the "1837456384" back into "the party of the first party."
The mathematical trick is that it's nearly impossible to derive the private key from the public key. That is, even if I gave you the program that translates from numbers into text you would not be able to reverse-engineer a program which translates the text into numbers. This is important, because it allows me to let you read a document encoded as set of numbers, but to deny you the ability to write a document in the same format.
So here's how a company uses this system to send an electronic contract: First, it registers its public key with a third-party organization, whose job is simply to record that Corporation X has registered a particular, unique public key. This third-party--a sort of digital notary--will make this public key available to anyone who asks. Second, Corporation X uses its private key--which it keeps secret--to translate the text of its contract into numbers. It then sends these numbers in lieu of the contract to Corporation Y, which simply uses the generally available public key to translate the numbers back into text.
The beauty of this system is that Corporation X cannot deny that it wrote the numbers that comprise the contract. Only someone with the private key--which only Corporation X has--could have written it. If someone without the private key tried to piece together a string of numbers to be translated with Corporation X's public key, it would simply come out as a string of gibberish. In other words, the very fact that the numbers can be turned into readable text with Corporation X's public key is good evidence that Corporation X created the numbers in the first place.
Moreover, Corporation Y cannot change the contract. If it tries to change even a single number, the text will come out completely garbled. So there's no danger of illegally altering the contract after it's been sent. And if Corporation Y, the receiver, agrees to the terms of the contract, it simply sends the same contract back using its own public/private key operation, and both parties to the transaction have proof that they agreed to the same terms.
Finally, it's worth noting that this law won't have much of an effect on most consumer transactions. When you buy a book from Amazon.com, for instance, you agree to certain conditions in the fine print that are legally binding depending on what the terms say, not upon whether you signed them in an appropriate way. Instead, the law will have an effect on business-to-business transactions and major personal transactions, like mortgages and insurance. Its proponents say that it will allow businesses to save enormous sums of money currently expended in mailing routine contracts back and forth.
Next question?
Bruce Gottlieb is a law student and a former
Slate staff writer.
Reader Response from The Fray:
Remember how the Administration wanted people to put their encryption keys in a secure escrow system? It was going to be very secure. "As secure as nuclear secrets," they said.
--A.G.Android
(To reply, click
here.)
Thanks for the article--it raises more logistical questions. Who develops these keys? Is each key unique, or are there only so many that can be made? Would this create a whole new software industry, and what company is poised to move into this area?
--Bill Estes
(To reply, click
here.)
[From the Fray Editor: And Uncertain in Baltimore had
questions
too. Fray post-ers were, as ever, ready to answer them, argue with Explainer and each other, and post messages titled You Guys Have it All Wrong and A number of technical flaws. Read on:]
Explainer is on the right track, but there are a number of important errors in his description of public key cryptography. This is by no means easy to explain, but I'm not going to cut him too much slack, since explaining is Explainer's job.
Here we go: Two keys are indeed initially generated. They must be created simultaneously and cannot both be chosen at random. These keys are not programs, as Explainer writes, merely a chain of alpha-numeric characters. Okay, so suppose that you've used your snazzy new encryption program to generate a key set (a public and private key pair). Now that you have the key pair, you need to make others aware of your public key. This is not as trivially easy as you might think, as those who look up your key must be assured that you are the owner. In other words, you must be absolutely certain that this public key belongs to Bruce Gottlieb, and not say Michael Kinsley. The protocols for accomplishing this verification is beyond the scope of this discussion.
You can now use these keys, together with an encryption program, to encrypt a document, digitally sign a document, or both. Unfortunately, Explainer described the process of encryption and decryption when he tried to explain digital signatures.
Let's start with encryption. Alan wants to send a letter to Betty and make sure that Charlie, who is infatuated with Betty and sometimes intercepts her mail, doesn't read it. Alan looks up Betty's public key and uses it with an encryption program to turn his letter into meaningless gibberish. Betty receives the letter and is able to return it to its original state using her private key and her decryption program.
Now, Betty wants to reply to Alan. She doesn't really care if Charlie reads the message, she's been telling Charlie for months she only has feelings for Alan. However, in the past Charlie has sent letters to Alan claiming to be from Betty and saying, in essence, "Bug off". Betty wants to make sure Alan knows the letter is authentic. So she uses her encryption program, along with her private key to digitally sign the letter. What results is the letter in its original readable form, with a digital signature appended to the end. This signature looks much like a public key, only a bit shorter. When Alan gets the letter, he uses Betty's public key to verify its authorship. Here's the deal, though. If a single character of the original letter has been changed in transit, the verification will fail.
Now, finally, Alan decides to write Betty once more. This time he is really paranoid. He wants to both encrypt and sign the message. So first, he digitally signs it with his private key, then he encrypts it with Betty's public key. When Betty gets it, she'll have to first decrypt it with her private key, then verify it with Alan's public key.
In summary, encryption is used to make a letter unreadable by anyone except the intended recipient. It utilizes the public and private keys of the recipient. Digital signing is used to prove the letter is from a given sender. It uses the private and public keys of the sender. Finally, as Explainer mentions, being able to derive the private key from the public would completely compromise this system. It is unlikely that that the ability to do so will develop anytime soon. However, if you want to take a crack at this problem, figure out a way to factor the product of two very large prime numbers. Next question?
--Hollins
(To reply, click
here.)
[We at the Fray found Hollins' posts--look for several more by him in
The Fray--particularly helpful, and Hollins himself recommends this one:]
Creating a digital signature involves two steps: creating a "message digest" and encrypting that digest with your private key. Suppose we've got a message--"The abalone attack at dawn". The message digest is sort of like the "fingerprint" of the text. The text can be many pages long, but the message digest is usually only around 128 bits or so, or about 16 characters of data. The thing is, though, that if you change one character in the original message, the message digest will be different. If the message is changed to "the abalone attack at sunset" the message digest won't be the same. OK, so far we have this magic algorithm that generates a different "fingerprint" for every likely text we feed it. We can't leave it at that, though. What if some guy generates a message like "the mullets attack at dawn"? The fingerprint algorithm is known, so he can generate a message digest himself, and send it to us. So, before we send the message, we encrypt the "fingerprint" or message digest with our private key. Only we know our private key--no one else should have it. The encrypted "fingerprint" can't be changed--otherwise garbage will result when the recipient tries to decrypt it with our public key. This encrypted message digest is the "digital signature." The fact that the digital signature can be decrypted by our public key shows that we encrypted it, and that it hasn't been changed by anyone since we encrypted it. Then we can run the very same fingerprint algorithm on the text that was used originally. This fingerprint better match the decrypted fingerprint we just found--if it doesn't that means something changed in the message, and we're not responsible for it.
--Don McGregor
(To reply, click
here.)
[And try this from Rex Derby. When you've read them all there will be a short test...]
(6/19)
What did you think of this article?
Join The Fray: Our Reader Discussion Forum
SPONSORED CONTENT
Reader Response from The Fray:
Remember how the Administration wanted people to put their encryption keys in a secure escrow system? It was going to be very secure. "As secure as nuclear secrets," they said.
--A.G.Android
(To reply, click here.)
Thanks for the article--it raises more logistical questions. Who develops these keys? Is each key unique, or are there only so many that can be made? Would this create a whole new software industry, and what company is poised to move into this area?
--Bill Estes
(To reply, click here.)
[From the Fray Editor: And Uncertain in Baltimore had questions too. Fray post-ers were, as ever, ready to answer them, argue with Explainer and each other, and post messages titled You Guys Have it All Wrong and A number of technical flaws. Read on:]
Explainer is on the right track, but there are a number of important errors in his description of public key cryptography. This is by no means easy to explain, but I'm not going to cut him too much slack, since explaining is Explainer's job.
Here we go: Two keys are indeed initially generated. They must be created simultaneously and cannot both be chosen at random. These keys are not programs, as Explainer writes, merely a chain of alpha-numeric characters. Okay, so suppose that you've used your snazzy new encryption program to generate a key set (a public and private key pair). Now that you have the key pair, you need to make others aware of your public key. This is not as trivially easy as you might think, as those who look up your key must be assured that you are the owner. In other words, you must be absolutely certain that this public key belongs to Bruce Gottlieb, and not say Michael Kinsley. The protocols for accomplishing this verification is beyond the scope of this discussion.
You can now use these keys, together with an encryption program, to encrypt a document, digitally sign a document, or both. Unfortunately, Explainer described the process of encryption and decryption when he tried to explain digital signatures.
Let's start with encryption. Alan wants to send a letter to Betty and make sure that Charlie, who is infatuated with Betty and sometimes intercepts her mail, doesn't read it. Alan looks up Betty's public key and uses it with an encryption program to turn his letter into meaningless gibberish. Betty receives the letter and is able to return it to its original state using her private key and her decryption program.
Now, Betty wants to reply to Alan. She doesn't really care if Charlie reads the message, she's been telling Charlie for months she only has feelings for Alan. However, in the past Charlie has sent letters to Alan claiming to be from Betty and saying, in essence, "Bug off". Betty wants to make sure Alan knows the letter is authentic. So she uses her encryption program, along with her private key to digitally sign the letter. What results is the letter in its original readable form, with a digital signature appended to the end. This signature looks much like a public key, only a bit shorter. When Alan gets the letter, he uses Betty's public key to verify its authorship. Here's the deal, though. If a single character of the original letter has been changed in transit, the verification will fail.
Now, finally, Alan decides to write Betty once more. This time he is really paranoid. He wants to both encrypt and sign the message. So first, he digitally signs it with his private key, then he encrypts it with Betty's public key. When Betty gets it, she'll have to first decrypt it with her private key, then verify it with Alan's public key.
In summary, encryption is used to make a letter unreadable by anyone except the intended recipient. It utilizes the public and private keys of the recipient. Digital signing is used to prove the letter is from a given sender. It uses the private and public keys of the sender. Finally, as Explainer mentions, being able to derive the private key from the public would completely compromise this system. It is unlikely that that the ability to do so will develop anytime soon. However, if you want to take a crack at this problem, figure out a way to factor the product of two very large prime numbers. Next question?
--Hollins
(To reply, click here.)
[We at the Fray found Hollins' posts--look for several more by him in The Fray--particularly helpful, and Hollins himself recommends this one:]
Creating a digital signature involves two steps: creating a "message digest" and encrypting that digest with your private key. Suppose we've got a message--"The abalone attack at dawn". The message digest is sort of like the "fingerprint" of the text. The text can be many pages long, but the message digest is usually only around 128 bits or so, or about 16 characters of data. The thing is, though, that if you change one character in the original message, the message digest will be different. If the message is changed to "the abalone attack at sunset" the message digest won't be the same. OK, so far we have this magic algorithm that generates a different "fingerprint" for every likely text we feed it. We can't leave it at that, though. What if some guy generates a message like "the mullets attack at dawn"? The fingerprint algorithm is known, so he can generate a message digest himself, and send it to us. So, before we send the message, we encrypt the "fingerprint" or message digest with our private key. Only we know our private key--no one else should have it. The encrypted "fingerprint" can't be changed--otherwise garbage will result when the recipient tries to decrypt it with our public key. This encrypted message digest is the "digital signature." The fact that the digital signature can be decrypted by our public key shows that we encrypted it, and that it hasn't been changed by anyone since we encrypted it. Then we can run the very same fingerprint algorithm on the text that was used originally. This fingerprint better match the decrypted fingerprint we just found--if it doesn't that means something changed in the message, and we're not responsible for it.
--Don McGregor
(To reply, click here.)
[And try this from Rex Derby. When you've read them all there will be a short test...]
(6/19)