654
`
`THE APPLICATION LA YER
`
`CHAP. 7
`
`The Content-Id: header identifies the content. It uses the same format as the
`standard Message-Id: header.
`The Content-Transfer-Encoding: tells how the body is wrapped for transmis(cid:173)
`sion through a network that may object to most characters other than letters,
`numbers, and punctuation marks. Five schemes (plus an escape to new schemes)
`are provided. The simplest scheme is just ASCII text. ASCII characters use 7
`bits, and can be carried directly by the email protocol provided that no line
`exceeds 1000 characters.
`The next simplest scheme is the same thing, but using 8-bit characters, that is,
`all values from 0 up to and including 255. This encoding scheme violates the (ori(cid:173)
`ginal) Internet email protocol but is used by some parts of the Internet that imple(cid:173)
`ment some extensions to the original protocol. While declaring the encoding does
`not make it legal, having it explicit may at least explain things when something
`goes wrong. Messages using the 8-bit encoding must still adhere to the standard
`maximum line length.
`Even worse are messages that use binary encoding. These are arbitrary binary
`files that not only use all 8 bits but also do not even respect the 1000 character
`line limit. Executable programs fall into this category. No guarantee is given that
`messages in binary will arrive correctly, but many people send them anyway.
`The correct way to encode binary messages is to use base64 encoding, some(cid:173)
`times called ASCII armor. In this scheme, groups of 24 bits are broken up into
`four 6-bit units, with each unit being sent as a legal ASCII character. The coding
`is "A" for 0, "B" for 1, and so on, followed by the 26 lowercase letters, the ten
`digits, and finally+ and I for 62 and 63, respectively. The== and= sequences are
`used to indicate that the last group contained only 8 or 16 bits, respectively. Car(cid:173)
`riage returns and line feeds are ignored, so they can be inserted at will to keep the
`lines short enough. Arbitrary binary text can be sent safely using this scheme.
`For messages that are almost entirely ASCII, but with a few non-ASCII char(cid:173)
`acters, base64 encoding is somewhat inefficient. Instead, an encoding known as
`quoted-printable encoding is used. This is just 7-bit ASCII, with all the charac(cid:173)
`ters above 127 encoded as an equal sign followed by the character's value as two
`hexadecimal digits.
`In summary, binary data should be sent encoded in base64 or quoted printable
`form. When there are valid reasons not to use one of these schemes, it is possible
`to specify a user-defined encoding in the Content-Transfer-Encoding: header.
`The last header shown in Fig. 7-44 is really the most interesting one. It speci(cid:173)
`fies the nature of the message body. Seven types are defined in RFC 1521, each
`of which has one or more subtypes. The type and subtype are separated by a
`slash, as in
`
`Content-Type: video/mpeg
`
`The subtype must be given explicitly in the header; no defaults are provided. The
`initial list of types and subtypes specified in RFC 1521 is given in Fig. 7-45.
`
`Ex.1006.672
`
`DELL
`
`

`

`SEC. 7.4
`
`ELECTRONIC MAIL
`
`655
`
`Many new ones have been added since then, and additional entries are being
`added all the time as the need arises.
`
`Type
`
`Subtype
`
`Description
`
`Text
`
`Image
`
`Audio
`
`Video
`
`Plain
`
`Unformatted text
`
`Richtext
`
`Text including simple formatting commands
`
`Gif
`
`Jpeg
`
`Basic
`
`Mpeg
`
`Still picture in GIF format
`
`Still picture in JPEG format
`
`Audible sound
`
`Movie in MPEG format
`
`Application
`
`Octet-stream
`
`An uninterpreted byte sequence
`
`Postscript
`
`A printable document in Postscript
`
`Rfc822
`
`A MIME RFC 822 message
`
`Message
`
`Partial
`
`Message has been split for transmission
`
`Multipart
`
`External-body Message itself must be fetched over the net
`
`Mixed
`
`Independent parts in the specified order
`
`Alternative
`
`Same message in different formats
`
`Parallel
`
`Digest
`
`Parts must be viewed simultaneously
`
`Each part is a complete RFC 822 message
`
`Fig. 7-45. The MIME types and subtypes defined in RFC 1521.
`
`Let us now go through the list of types. The text type is for straight text. The
`text/plain combination is for ordinary messages that can be displayed as received,
`with no encoding and no further processing. This option allows ordinary mes(cid:173)
`sages to be transported in MIME with only a few extra headers.
`The text/richtext subtype allows a simple markup language to be included in
`the text. This language provides a system-independent way to express boldface,
`italics, smaller and larger point sizes, indentation, justification, sub- and super(cid:173)
`scripting, and simple page layout.· The markup language is based on SGML, the
`Standard Generalized Markup Language also used as the basis for the World
`Wide Web's HTML. For exampl~, the message
`
`The <bold> time </bold> has come the <italic> walrus </italic> said ...
`
`would be displayed as
`
`The time has come the walrus said ...
`
`It is up to the receiving system to choose the appropriate rendition. If boldface
`and
`italics are available,
`they can be used; otherwise, colors, blinking,
`
`Ex.1006.673
`
`DELL
`
`

`

`656
`
`THE APPLICATION LA YER
`
`CHAP. 7
`
`underlining, reverse video, etc. can be used for emphasis. Different systems can,
`and do, make different choices.
`The next MIME type is image, which is used to transmit still pictures. Many
`formats are widely used for storing and transmitting images nowadays, both with
`and without compression. Two of these, GIF and JPEG, are official subtypes, but
`no doubt others will be added later.
`The audio and video types are for sound and moving pictures, respectively.
`Note that video includes only the visual information, not the soundtrack. If a
`movie with sound is to be transmitted, the video and audio portions may have to
`be transmitted separately, depending on the encoding system used. The only
`video format defined so far is the one devised by the modestly-named Moving
`Picture Experts Group (MPEG).
`The application type is a catchall for formats that require external processing
`not covered by one of the other types. An octet-stream is just a sequence of unin(cid:173)
`terpreted bytes. Upon receiving such a stream, a user agent should probably
`display it by suggesting to the user that it be copied to a file and prompting for a
`file name. Subsequent processing is then up to the user.
`The other defined subtype is postscript, which refers to the PostScript
`language produced by Adobe Systems and widely used for describing printed
`pages. Many printers have built-in Postscript interpreters. Although a user agent
`can just call an external PostScript interpreter to display incoming PostScript files,
`doing so is not without danger. PostScript is a full-blown programming language.
`Given enough time, a sufficiently masochistic person could write a C compiler or
`a database management system in PostScript. Displaying an incoming PostScript
`message is done by executing the PostScript program contained in it. In addition
`to displaying some text, this program can read, modify, or delete the user's files,
`and have other nasty side effects.
`The message type allows one message to be fully encapsulated inside another.
`This scheme is useful for forwarding email, for example. When a complete RFC
`822 message is encapsulated inside an outer message, the rfc822 subtype should
`be used.
`The partial subtype makes it possible to break an encapsulated message up
`into pieces and send them separately (for example, if the encapsulated message is
`too long). Parameters make it possible to reassemble all the parts at the destina(cid:173)
`tion in the correct order.
`Finally, the external-body subtype can be used for very long messages (e.g.,
`video films). Instead of including the MPEG file in the message, an FTP address
`is given and the receiver's user agent can fetch it over the network at the time it is
`needed. This facility is especially useful when sending a movie to a mailing list
`of people, only a few of whom are expected to view it (think about electronic junk
`mail containing advertising videos).
`The final type is multipart, which allows a message to contain more than one
`part, with the beginning and end of each part being clearly delimited. The mixed
`
`Ex.1006.674
`
`DELL
`
`

`

`SEC. 7.4
`
`ELECTRONIC MAIL
`
`657
`
`subtype aHows each part to be different, with no additional structure imposed. In
`contrast, with the alternative subtype, each part must contain the same message
`but expressed in a different medium or encoding. For example, a message could
`be sent in plain ASCII, in richtext, and in PostScript. A properly-designed user
`agent getting such a message would display it in PostScript if possible. Second
`choice would be richtext. If neither of these were possible, the flat ASCII text
`would be displayed. The parts should be ordered from simplest to most complex
`to help recipients with pre--MIME user agents make some sense of the message
`(e.g., even a pre-MIME user can read flat ASCII text).
`The alternative subtype can also be used for multiple languages. In this con(cid:173)
`text, the Rosetta Stone can be thought of as an early multipart/alternative mes(cid:173)
`sage.
`A multimedia example is shown in Fig. 7-46. Here a birthday greeting is
`transmitted both as text and as a song. If the receiver has an audio capability, the
`user agent there will fetch the sound file, birthday.snd, and play it. If not, the lyr(cid:173)
`ics are displayed on the screen in stony silence. The parts are delimited by two
`hyphens followed by the (user-defined) string specified in the boundary parame(cid:173)
`ter.
`
`Note that the Content-Type header occurs in three positions within this exam(cid:173)
`ple. At the top level, it indicates that the message has multiple parts. Within each
`part, it gives the type and subtype of that part. Finally, within the body of the
`second part, it is required to tell the user agent what kind of an external file it is to
`fetch. To indicate this slight difference in usage, we have used lowercase letters
`here, although all headers are case insensitive. The content-transfer-encoding is
`similarly required for any external body that is not encoded as 7-bit ASCII.
`Getting back to the subtypes for multipart messages, two more possibilities
`exist. The parallel subtype is used when all parts must be "viewed" simultane(cid:173)
`ously. For example, movies often have an audio channel and a video channel.
`Movies are more effective if these two channels are played back in parallel,
`instead of consecutively.
`Finally, the digest subtype is used when many messages are packed together
`into a composite message. For example, some discussion groups on the Internet
`collect messages from subscribers and then send them out as a single
`multipart/digest message.
`
`7 .4.4. Message Transfer
`
`The message transfer system is concerned with relaying messages from origi(cid:173)
`nator to the recipient. The simplest way to do this is to establish a transport con(cid:173)
`nection from the source machine to the destination machine and then just transfer
`the message. After examining how this is normally done, we will examine some
`situations in which this does not work and what can be done about them.
`
`Ex.1006.675
`
`DELL
`
`

`

`658
`
`THE APPLICATION LAYER
`
`CHAP. 7
`
`From: elinor@abc.com
`To: carolyn@xyz.com
`MIME-Version: 1.0
`Message-Id: <0704760941.AA00747@abc.com>
`Content-Type: multipart/alternative; boundary=qwertyuiopasdfghjklzxcvbnm
`Subject: Earth orbits sun integral number of times
`
`This is the preamble. The user agent ignores it. Have a nice day.
`
`--qwertyuiopasdfghjklzxcvbnm
`Content-Type: text/richtext
`
`Happy birthday to you
`Happy birthday to you
`Happy birthday dear <bold> Carolyn </bold>
`Happy birthday to you
`
`--qwertyuiopasdfghjklzxcvbnm
`Content-Type: message/external-body;
`access-type=" anon-ftp";
`site="bicycle.abc.com";
`di rectory=" pub";
`name="birthday.snd"
`
`content-type: audio/basic
`content-transfer-encoding: base64
`--qwertyuiopasdfghjklzxcvbnm--
`
`Fig. 7-46. A multipart message containing richtext and audio alternatives.
`
`SMTP-Simple Mail Transfer Protocol
`
`Within the Internet, email is delivered by having the source machine establish
`a TCP connection to port 25 of the destination machine. Listening to this port is
`an email daemon that speaks SMTP (Simple Mail Transfer Protocol). This
`daemon accepts incoming connections and copies messages from them into the
`appropriate mailboxes. If a message cannot be delivered, an error report contain(cid:173)
`ing the first part of the undeliverable message is returned to the sender.
`SMTP is a simple ASCII protocol. After establishing the TCP connection to
`port 25, the sending machine, operating as the client, waits for the receiving ma(cid:173)
`chine, operating as the server, to talk first. The server starts by sending a line of
`text giving its identity and telling whether or not it is prepared to receive mail. If
`it is not, the client releases the connection and tries again later.
`If the server is willing to accept email, the client announces whom the email
`is corning from and whom it is going too. If such a recipient exists at the
`
`Ex.1006.676
`
`DELL
`
`

`

`SEC. 7.4
`
`ELECTRONIC MAIL
`
`659
`
`destination, the server gives the client the go-ahead to send the message. Then the
`client sends the message and the server acknowledges it. No checksums are gen(cid:173)
`erally needed because TCP provides a reliable byte stream. If there is more
`email, that is now sent. When all the email has been exchanged in both direc(cid:173)
`tions, the connection is released. A sample dialog for sending the message of
`Fig. 7-46, including the numerical codes used by SMTP, is shown in Fig. 7-47.
`The lines sent by the client are marked C:; those sent by the server are marked S:.
`A few comments about Fig. 7-47 may be helpful. The first command from
`the client is indeed HELO. Of the two four-character abbreviations for HELLO,
`this one has numerous advantages over its competitor. Why all the commands
`had to be four characters has been lost in the mists of time.
`In Fig. 7-47, the message is sent to only one recipient, so only one RCPT
`command is used. Multiple such commands are allowed to send a single message
`to multiple receivers. Each one is individually acknowledged or rejected. Even if
`some recipients are rejected (because they do not exist at the destination), the
`message can be sent to the remainder.
`Finally, although the syntax of the four-character commands from the client is
`rigidly specified, the syntax of the replies is less rigid. Only the numerical code
`really counts. Each implementation can put whatever string it wants after the
`code.
`Even though the SMTP protocol is well defined (by RFC 821), a few prob(cid:173)
`lems can still arise. One problem relates to message length. Some older imple(cid:173)
`mentations cannot handle messages exceeding 64KB. Another problem relates to
`timeouts. If the client and server have different timeouts, one of them may give
`up while the other is still busy, unexpectedly terminating the connection. Finally,
`in rare situations, infinite mailstorms can be triggered. For example, if host l
`holds mailing list A and host 2 holds mailing list B and each list contains an entry
`for the other one, then any message sent to either list will generate a never-ending
`amount of email traffic.
`To get around some of these problems, extended STMP (ESMTP) has been
`defined in RFC 1425. Clients wanting to use it should send an EHLO message
`instead of HELO initially. If this is rejected, then the server is a regular SMTP
`server, and the client should proceed in the usual way. If the EHLO is accepted,
`then new commands and parameters are allowed. The standardization of these
`commands and parameters is an ongoing process.
`
`Email Gateways
`
`Email using SMTP works best when both the sender and the receiver are on
`the Internet and can support TCP connections between sender and receiver. How(cid:173)
`ever, many machines that are not on the Internet still want to send and receive
`email from Internet sites. For example, many companies intentionally do not
`
`Ex.1006.677
`
`DELL
`
`

`

`660
`
`THE APPLICATION LA YER
`
`CHAP. 7
`
`S: 220 xyz.com SMTP service ready
`C: HELO abc.com
`S: 250 xyz.com says hello to abc.com
`C: MAIL FROM: <elinor@abc.com>
`S: 250 sender ok
`C: RCPT TO: <Carolyn@xyz.com>
`S: 250 recipient ok
`
`C:DATA
`
`S: 354 Send mail; end with "."on a line by itself
`C: From: elinor@abc.com
`C: To: carolyn@xyz.com
`C: MIME-Version: 1.0
`C: Message-Id: <0704760941.AA00747@abc.com>
`C: Content-Type: multipart/alternative; boundary=qwertyuiopasdfghjklzxcvbnm
`C: Subject: Earth orbits sun integral number of times
`C:
`C: This is the preamble. The user agent ignores it. Have a nice day.
`C:
`C: --qwertyuiopasdfghjklzxcvbnm
`C: Content-Type: text/richtext
`C:
`C: Happy birthday to you
`C: Happy birthday to you
`C: Happy birthday dear <bold> Carolyn </bold>
`C: Happy birthday to you
`C:
`C: --qwertyuiopasdfghjklzxcvbnm
`C: Content-Type: message/external-body;
`C:
`access-type=" anon-ftp";
`C:
`site="bicycle.abc.com";
`C:
`directory=" pub";
`C:
`name="birthday.snd"
`C:
`C: content-type: audio/basic
`C: content-transfer-encoding: base64
`C: --qwertyuiopasdfghjklzxcvbnm
`C:.
`
`C: QUIT
`
`S: 250 message accepted
`
`S: 221 xyz.com closing connection
`
`Fig. 7-47. Transferring a message from elinor@abc.com to carolyn@xyz.com.
`
`want to be on the Internet for security reasons. Some of them even remove them(cid:173)
`selves from the Internet by erecting firewalls between themselves and the Internet.
`Another problem occurs when the sender speaks only RFC 822 and the
`
`Ex.1006.678
`
`DELL
`
`

`

`

`

`662
`
`Final Delivery
`
`THE APPLJCA TION LA YER
`
`CHAP. 7
`
`Up until now, we have assumed that all users work on machines that are capa(cid:173)
`ble of sending and receiving email. Frequently this situation is false. For exam(cid:173)
`ple, at many companies, users work at desktop PCs that are not on the Internet and
`are not capable of sending or receiving email from outside the company. Instead,
`the company has one or more email servers that can send and receive email. To
`send or receive messages, a PC must talk to an email server using some kind of
`delivery protocol.
`A simple protocol used for fetching email from a remote mailbox is POP3
`(Post Office Protocol), which is defined in RFC 1225. It has commands for the
`user to log in, log out, fetch messages, and delete messages. The protocol itself
`consists of ASCII text and has something of the flavor of SMTP. The point of
`POP3 is to fetch email from the remote mailbox and store it on the user's local
`machine to be read later.
`A more sophisticated delivery protocol is IMAP (Interactive Mail Access
`Protocol), which is defined in RFC 1064. It was designed to help the user who
`uses multiple computers, perhaps a workstation in the office, a PC at home, and a
`laptop on the road. The basic idea behind IMAP is for the email server to main(cid:173)
`tain a central repository that can be accessed from any machine. Thus unlike
`POP3, IMAP does not copy email to the user's personal machine because the user
`may have several.
`IMAP has many features, such as the ability to address mail not by arrival
`number as is done in Fig. 7-40, but by using attributes (e.g., Give me the first
`message from Sam). In this view, a mailbox is more like a relational database
`system than a linear sequence of messages.
`Yet a third delivery protocol is DMSP (Distributed Mail System Protocol),
`which is part of the PCMAIL system and described in RFC 1056. This one does
`not assume that all email is on one server, as do POP3 and IMAP. Instead, it
`allows users to download email from the server to a workstation, PC, or laptop
`and then disconnect. The email can be read and answered while disconnected.
`When reconnection occurs later, email is transferred and the system is resyn(cid:173)
`chronized.
`Independent of whether email is delivered directly to the user's workstation or
`to a remote server, many systems provide hooks for additional processing of
`incoming email. An especially valuable tool for many email users is the ability to
`set up filters. These are rules that are checked when email comes in or when the
`user agent is started. Each rule specifies a condition and an action. For example,
`a rule could say that any message from Andrew S. Tanenbaum should be
`displayed in a 24-point flashing reel boldface font (or alternatively, be discarded
`automatically without comment).
`Another delivery feature often provided is the ability to (temporarily) forward
`incoming email to a different address. This address can even be a computer
`
`Ex.1006.680
`
`DELL
`
`

`

`SEC. 7.4
`
`ELECTRONIC MAIL
`
`663
`
`operated by a commercial paging service, which then pages the user by radio or
`satellite, displaying the Subject: line on his beeper.
`Still another common feature of final delivery is the ability to install a vaca(cid:173)
`tion daemon. This is a program that examines each incoming message and sends
`the sender an insipid reply such as
`
`Hi. I'm on vacation. I'll be back on the 24th of August. Have a nice day.
`
`Such replies can also specify how to handle urgent matters in the interim, other
`people to contact for specific problems, etc. Most vacation daemons keep track of
`whom they have sent canned replies to and refrain from sending the same person a
`second reply. The good ones also check to see if the incoming message was sent
`to a mailing list, and if so, do not send a canned reply at all. (People who send
`messages to large mailing lists during the summer probably do not want to get
`hundreds of replies detailing everyone's vacation plans.)
`The author recently ran into a most extreme form of delivery processing when
`he sent an email message to a person who claims to get 600 messages a day. His
`identity will not be disclosed here, lest half the readers of this book also send him
`email. Let us call him John.
`John has installed an email robot that checks every incoming message to see if
`it is from a new correspondent. If so, it sends back a canned reply explaining that
`John can no longer personally read all his email. Instead he has produced a per(cid:173)
`sonal FAQ (Frequently Asked Questions) document that answers many questions
`he is commonly asked. Normally, newsgroups have FAQs, not people.
`John's FAQ gives his address, fax, and telephone numbers and tells how to
`contact his company. It explains how to get him as a speaker and describes where
`to get his papers and other documents. It also provides pointers to software he has
`written, a conference he is running, a standard he is the editor of, and so on.
`Perhaps this approach is necessary, but maybe a personal FAQ is the ultimate
`status symbol.
`
`7.4.5. Email Privacy
`
`When an email message is sent between two distant sites, it will generally
`transit dozens of machines on the way. Any of these can read and record the mes(cid:173)
`sage for future use. Privacy is nonexistent, despite what many people think
`(Weisband and Reinig, 1995). Nevertheless, many people would like to be able to
`send email that can be read by the intended recipient and no one else: not their
`boss, not hackers, not even the government. This desire has stimulated several
`people and groups to apply the cryptographic principles we studied earlier to
`email to produce secure email. In the following sections we will study two widely
`used secure email systems, POP and PEM. For additional information, see (Kauf(cid:173)
`man et al., 1995; Schneier, 1995; Stallings, 1995b; and Stallings, 1995c).
`
`Ex.1006.681
`
`DELL
`
`

`

`664
`
`THE APPLICATION LA YER
`
`CHAP. 7
`
`PGP-Pretty Good Privacy
`
`Our first example, PGP (Pretty Good Privacy) is essentially the brainchild
`of one person, Phil Zimmermann (Zimmermann, l 995a, l 995b ). It is a complete
`email security package that provides privacy, authentication, digital signatures,
`and compression, all in easy-to-use form. Furthermore, the complete package,
`including all the source code, is distributed free of charge via the Internet, bulletin
`boards, and commercial networks. Due to its quality, price (zero), and easy avai(cid:173)
`lability on MS-DOS/Windows, UNIX, and Macintosh platforms, it is widely used
`today. A commercial version is also available for those companies requiring sup(cid:173)
`port.
`It has also been embroiled in various controversies (Levy, 1993). Because it
`is freely available over the Internet, the U.S. government has claimed the ability
`of foreigners to obtain it constitutes a violation of the laws concerning the export
`of munitions. Later versions were produced outside the United States to get
`around this restriction. Another problem has involved an alleged infringement of
`the RSA patent, but that problem was settled with releases starting at 2.6.
`Nevertheless, not everyone likes the idea of people being able to keep secrets
`from them, so PGP' s enemies are always lurking in the shadows, waiting to
`pounce. Accordingly, Zimmermann's motto is: "If privacy is outlawed, only
`outlaws will have privacy."
`PGP intentionally uses existing cryptographic algorithms rather than inventing
`new ones. It is largely based on RSA, IDEA, and MD5, all algorithms that have
`withstood extensive peer review and were not designed or influenced by any
`government agency trying to weaken them. For people who tend to distrust
`government, this property is a big plus.
`PGP supports text compression, secrecy, and digital signatures and also pro(cid:173)
`vides extensive key management facilities. To see how PGP works, let us con(cid:173)
`sider the example of Fig. 7-49. Here, Alice wants to send a signed plaintext mes(cid:173)
`sage, P, to Bob in a secure way. Both Alice and Bob have private (Dx) and public
`(Ex) RSA keys. Let us assume that each one knows the other's public key; we
`will cover key management later.
`Alice starts out by invoking the PGP program on her computer. PGP first
`hashes her message, P, using MD5 and then encrypts the resulting hash using her
`private RSA key, DA- When Bob eventually gets the message, he can decrypt the
`hash with Alice's public key and verify that the hash is com::ct. Even if someone
`else (e.g., Trudy) could acquire the hash at this stage and decrypt it with Alice's
`known public key, the strength of MD5 guarantees that it would be computation(cid:173)
`ally infeasible to produce another message with the same MD5 hash.
`The encrypted hash and the original message are now concatenated into a sin(cid:173)
`gle message, P 1, and compressed using the ZIP program, which uses the Ziv(cid:173)
`Lempel algorithm (Ziv and Lempel, 1977). Call the output of this step Pl.Z.
`Next, PGP prompts Alice for some random input. Both the content and the
`
`Ex.1006.682
`
`DELL
`
`

`

`SEC. 7.4
`
`ELECTRONIC MAIL
`
`665
`
`KM : One-time message key for IDEA
`
`: Concatenation
`
`Bob's public
`RSA key, Es
`
`\
`KM -I RSA I
`1.::1 _ C::l vi::l Pt Z ~ ~ the""""''
`!
`l
`P_ ft'.~''._~-~-_r~- I ~~-7-~
`
`Alice's private
`RSA key, DA
`\
`
`ASCII text to
`
`\ \ - -
`
`/
`
`P1 compressed
`
`Original
`plaintext
`message
`from Alice
`
`Concatenation of
`P and the signed
`hash of P
`
`Concatenation of
`P1 .Z encrypted
`with IDEA and KM
`encrypted with Es
`
`Fig. 7-49. PGP in operation for sending a message.
`
`typing speed are used to generate a 128-bit IDEA message key, KM (called a ses(cid:173)
`sion key in the PGP literature, but this is really a misnomer since there is no ses(cid:173)
`sion). KM is now used to encrypt Pl.Z with IDEA in cipher feedback mode. In
`addition, KM is encrypted with Bob's public key, Es. These two components are
`then concatenated and converted to base64, as we discussed in the section on
`MIME. The resulting message then contains only letters, digits, and the symbols
`+, I and=, which means it can be put into an RFC 822 body and be expected to
`an-ive unmodified.
`When Bob gets the message, he reverses the base64 encoding and decrypts
`the IDEA key using his private RSA key. Using this key, he decrypts the message
`to get Pl .Z. After decompressing it, Bob separates the plaintext from the
`encrypted hash and decrypts the hash using Alice's public key. If the plaintext
`hash agrees with his own MD5 computation, he knows that P is the con-ect mes(cid:173)
`sage and that it came from Alice.
`It is worth noting that RSA is only used in two places here: to encrypt the
`128-bit MD5 hash and to encrypt the 128-bit IDEA key. Although RSA is slow, it
`has to encrypt only 256 bits, not a large volume of data. Furthermore, all 256
`plaintext bits are exceedingly random, so a considerable amount of work will be
`required on Trudy's part just to determine if a guessed key is correct. The heavy(cid:173)
`duty encryption is done by IDEA, which is orders of magnitude faster than RSA.
`Thus PGP provides security, compression, and a digital signature and does so in a
`much more efficient way than the scheme illustrated in Fig. 7-23.
`
`Ex.1006.683
`
`DELL
`
`

`

`666
`
`THE APPLICATION LA YER
`
`CHAP. 7
`
`PGP supports three RSA key lengths. It is up to the user to select the one that
`is most appropriate. The lengths are
`
`1. Casual (384 bits): can be broken today by folks with large budgets.
`
`2. Commercial (512 bits): might be breakable by three-letter organizations.
`
`3. Military (1024): Not breakable by anyone on earth.
`
`There has been some discussion about a fourth category: alien (2048 bits), which
`could not be broken by anyone or anything in the universe, but this has not yet
`been adopted. Since RSA is only used for two small computations, probably
`everyone should use military strength keys all the time, except perhaps on aged
`PC-XTs.
`The format of a PGP message is shown in Fig. 7-50. The message has three
`parts, containing the IDEA key, the signature, and the message, respectively. The
`key part contains not only the key, but also a key identifier, since users are permit(cid:173)
`ted to have multiple public keys.
`
`I
`
`•
`
`,____________ Base64
`
`Message 1------ Compressed, encrypted by IDEA
`
`ID
`of
`Es
`
`KM
`
`Sig.
`hdr
`
`T
`i
`m
`e
`
`T
`ID
`y
`of
`p
`EA e
`s
`
`MOS
`hash
`
`File
`Msg
`hdr name
`
`T
`i
`m
`e
`
`1----1
`DA
`
`Fig. 7-50. A PGP message.
`
`Encrypted
`by
`
`Message part
`Signature part
`key part
`~~--~-----,~------~------~
`(
`
`)
`
`Me
`
`(
`)
`
`:J
`
`The signature part contains a header, which will not concern us here. The
`header is followed by a timestamp, the identifier for the sender's public key that
`can be used to decrypt the signature hash, some type information that identifies
`the algorithms used (to allow MD6 and RSA2 to be used when they are invented),
`and the encrypted hash itself.
`The message part also contains a header, the default name of the file to be
`used if the receiver writes the file to the disk, a message creation timestamp, and,
`finally, the message itself.
`Key management has received a large amount of attention in PGP as it is the
`Achilles heel of all security systems. Each user maintains two data structures
`locally: a private key ring and a public key ring. The private key ring contains
`one or more personal private-public key pairs. The reason for supporting multiple
`pairs per user is to permit users to change their public keys periodically or when
`one is thought to have been compromised, without invalidating messages
`
`Ex.1006.684
`
`DELL
`
`

`

`SEC. 7.4
`
`ELECTRONIC MAIL
`
`667
`
`currently in preparation or in transit. Each pair has an identifier associated with it,
`so that a message sender can tell the recipient which public key was used to
`encrypt it. Message identifiers consist of the low-order 64 bits of the public key.
`Users are responsible for avoiding conflicts in their public key identifiers. The
`private keys on disk are encrypted using a special (arbitrarily long) password to
`protect them against sneak attacks.
`The public key ring contains public keys of the user's correspondents. These
`are needed to encrypt the message keys associated with each message. Each entry
`on the public key ring contains not only the public key, but also its 64-bit identif(cid:173)
`ier and an indication of how strongly the user trusts the key.
`The problem being tackled here is the following. Suppose that public keys
`are maintained on bulletin boards. One way for Trudy to read Bob's secret email
`is to attack the bulletin board and replace Bob's public key with one of her choice.
`When Alice later fetches the key so-called belonging to Bob, Trudy can mount a
`bucket brigad