emks@uokvax.UUCP (01/26/85)
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 <word> parameter indicates the software to encrypt
the body, and the second, optional <word> 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.UUCPnesbitt@mcc-db.UUCP (Vance Nesbitt) (05/22/85)
> 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 <word> parameter indicates the software to encrypt > the body, and the second, optional <word> 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 ***
lauren@vortex.UUCP (Lauren Weinstein) (05/25/85)
While encrypted mail is certainly technically possible in the UUCP net environment, I see serious political problems with attempting to use it, except where ALL HOPS along a path have agreed to its use. The problem is that many site administrators would probably be concerned about the possibility of highly commercial or somehow illegal messages flowing through their systems. As the proportion of mail that was encrypted increases, administrators, already hard-pressed in many cases to justify current phone costs, would be in even worse shape. While most mail flows through all sites without being looked at by administrators (we assume, anyway), I suspect that encrypted mail would raise fears about misuse that don't exist now. Given the "free forwarding" nature of the net, I just don't think encryption fits-- unless all hops agree in advance, of course. --Lauren--
kay@warwick.UUCP (Kay Dekker) (06/05/85)
In article <203@mcc-db.UUCP> nesbitt@mcc-db.UUCP (Vance Nesbitt) writes: > >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 *** Well, I spent some time trying to work out what Vance was trying to say but all I could get out of it (with my limited cryptographic knowledge) was I FRANCIS BACON WROTE SHAKESPEARES PLAYS AND MY FRIEND LORD N**** WROTE HIS SONNETS Nice, but uninteresting. What did you really mean to say, Vance? Which encryption method did you use? Kay. -- "It takes a coward like you to insist that Michael Jackson's nun is living in your computer." "flame" output. ... mcvax!ukc!warwick!flame!kay
earlw@pesnta.UUCP (Earl Wallace ) (06/08/85)
Gee, I think I missed something....