Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site mcc-db.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!gymble!lll-crg!dual!mordor!ut-sally!mcc-db!nesbitt From: nesbitt@mcc-db.UUCP (Vance Nesbitt) Newsgroups: net.crypt Subject: Re: Secure Mailers--Some Thoughts Message-ID: <203@mcc-db.UUCP> Date: Wed, 22-May-85 14:08:07 EDT Article-I.D.: mcc-db.203 Posted: Wed May 22 14:08:07 1985 Date-Received: Fri, 24-May-85 22:43:37 EDT References: <12900007@uokvax.UUCP> Organization: MCC (Austin, TX) Lines: 250 > There's been quite a flurry of activity about secure mail transmission > recently. Let me make some observations, and I'll sit back and see > what y'all have to say. > > NOTE: I posted this note to net.crypt, even though I'm talking about > a secure *mail* system. I think that key distribution problems, mail > system cryptologic security, and related matters belong here. I hope > that any offspring discussion won't bore net.crypt readers. > > The purpose of a secure mailing system is presumably to protect the contents > of the "envelope" and, perhaps, the address [e.g. AIGs on AUTODIN and > BOOK-style messages]. Additionally, secure systems might be used to > avoid disclosure of flurries of activity--since you'd be generating a > constant stream of messages, a would-be thief wouldn't be able to identify > the high-valued messages from the medium- or low-valued ones. > > There are, currently, no encrypted mailers registered with the Network > Information Center (NIC@SRI-NIC.ARPA). But the RFC-822, "Standard for > the Format of ARPA Internet Text Messages," provides for optional use > of encrypted mailers. Specifically, it states this: > > ===== ===== > > 4. MESSAGE SPECIFICATION > > 4.7. OTHER FIELDS > > 4.7.3. ENCRYPTED > > Sometimes, data encryption is used to increase the privacy > of message contents. If the body of a message has been encrypted, > to keep its contents private, the "Encrypted" field can be used > to note the fact and to indicate the nature of the encryption. > The first parameter indicates the software to encrypt > the body, and the second, optional is intended to aid > the recipient in selecting the proper decryption key. This code > word may be viewed as an index to a table of keys held by the > recipient. > > Note: Unfortunately, headers must contain envelope, as well > as contents, information. Consequently, it is necessary > that they remain unencrypted, so that mail transport > services may access them. Since names, addresses, and > "Subject" field contents may contain sensitive information, > this requirement limits total message privacy. > > Names of encryption software are registered with the Network > Information Center, SRI International, Menlo Park, California. > > ===== ===== > > Okay, so we are allowed to encrypt our mail under Internet rules. > > Once we've decided to encrypt our mail (presumably--for now--between two > sites with prior arrangement), how do we transmit the key information? > > I haven't seen any good stuff on commercial encryption key handling. The > Department of Defense has good rules on key handling, but some places may > not want to (or be able to) follow DoD's strict rules. > > Keying material falls into three distinct time frames: > > -- Past Keying Material. Past keying material should be destroyed by > some appropriate means after use. Although it won't be of much > use alone, it may give away information like > > --- The exact algorithm used to encrypt information. > > --- If enough past keying material is available, the algorithm > used to generate keys. VERY dangerous, indeed. > > --- If encrypted messages are captured and held, past keying > material may allow the culprit to decrypt the message > without expending any cryptanalytic effort. > > -- Current Keying Material. Current keying material should be stored > in some tamper-resistant encryption device. [Independent encryption > boxes seem to be much better than software encryption for speed > and physical key security.] Of course, if someone had both your > current key and your algorithm (presuming it's a two-way cipher), > he could destroy any modicum of message security you might have > presumed. > > -- Future Keying Material. Future keys are the most serious security > risk, since future keys are usually stored in a quantity which > might cover many future key cycles. They also usually provide a > key change schedule--information which most any thief would want. > These keys should be afforded the best protection possible. > > The DDN Subscriber Security Guide suggests that crypto keys be stored > in a secure container (i.e. a container with a lock) to which no > more than 10 people have keys or combinations. > > What do you think about key distribution? Some of you might see couriers > and tamper-resistant packaging as the only means of reasonably secure key > distribution. I think that's what DoD requires, but I really doubt that > anyone would send encrypted classified information through USENET... > Although I suppose that wouldn't be against DoD regulations, since the > *encrypted* text is considered unclassified. > > For a number of DES-grade commercial applications, I think that REGISTERED > mail and double-wrapped envelopes would provide sufficient security for > the future keying material. > > I suppose that a number of encryption systems and key distribution systems > could meet these requirements. [Your comments?] But what about a system > which would allow a person with whom I've had no prior contact to send > me mail in a secure manner? Public-key systems bring the Diffie-Hellman > trap-door model to mind--a system about which I don't know much. I'm not > certain about its level of confidentiality. > > But what about a more practical matter than the encryption scheme. Think > about this: how would these public keys be distributed? In a specific > community of interest, electronically publishing this information wouldn't > be too difficult, but to publish this information on a per-user basis > top-level-domain-wide seems almost impossible. No, it *does* seem > impossible. > > Perhaps there could be some sort of system-keying or domain-keying. I > mean that the information could be prepared for decryption at the domain > level. Example of what I mean (my words aren't making the mark): > > There exist two sites: OSGD.CB.ATT.UUCP > VAX-A.OU.S-CEN.UUCP > > And both CB.ATT.UUCP and OU.S-CEN.UUCP are registered at > some place. > > CB.ATT.UUCP and OU.S-CEN.UUCP might specify, in their registry, > some public key. > > mark.OSGD.CB.ATT.UUCP mails a message to emks.VAX-A.OU.S-CEN.UUCP > which is confidential. > > The OSGD machine's mailer looks up the OU public key and encrypts > the mail using some publically available algorithm. > > The envelope would be transported by intermediate machines as > any other message, without attempting to decrypt the message. > > The message would be decrypted at the destination domain (OU) > and the user's local key (i.e. enroll/xsend/xget scheme or > something) would reencrypt the message locally and dump it in > an appropriate for emks.OU.S-CEN.UUCP's later reading. > > Sound plausible (or a step in the right direction)? > > Two problems which need to be resolved: > > If the message would be so sensitive that even the system admini- > strator shouldn't see it (bogus concept), then mark.OSGD and emks.OU > must have exchanged keys previously. The message would be encrypted > beforehand using some previously agreed upon system and key--the > mailer's encryption would be just an additional encryption on > top. > > The UUCP/USENET administration people would have to mandate a > particular system key change schedule and publish a key change > well before each key change cycle. This would preclude systems > from choosing some gonzo date/time for key change. If the public > keys are not distributed well in advance, some sites may not get > the new information soon enough for the key change. > > Mail that is in-transport at the key change time creates > a problem unless the old keys are retained for a while and > the header specified which key edition was used in the message. > > Public keys may not provide optimum security. Knapsacks are probably > here. > > Some advantages: > > There are few decrypted points (the originating and the destination > domains). > > The public keys may be reasonably easily maintained by 2d or 3d > level domain managers. This will require much thought, if this is > ever seriously considered. > > Users don't have to have a registry of every (!) UUCP (or other > domain) user. > > Wow. I didn't mean to write a dissertation. > > Please send your comments via news or mail. > > Happy hunting. > > kurt > > Kurt F. Sauer AC 405 360-5172 > 2420 Bonnybrook Street AV 884-3883/2297 (messages only) > Norman OK 73071-4324 > > {ctvax,mtxinu!ea}!uokvax!emks.UUCP P . . w q . . .a .q .z . q Q .e .e *sdfasdfasdfasdfasdf asdfasdf asdfasdfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff q q . .q Q Q Q ** REPLACE THIS LINE WITH YOUR MESSAGE ***