RFC-822 header processing in perl

I've written a perl script to parse RFC-822 style headers.  It was a
good deal harder than I had thought it would be.  Since it's over 300
lines (with comments) I won't post it, but will mail it to anyone who
wants to play with it.  It has the following features:

Doesn't touch anything unless you ask it to.  Leaves the ordering and
whitespace/folding of header lines unchanged.

Allows you to replace any header line (which appears only once) with
an arbitrary value, which is appropriatly folded on output.

Allows you to delete any header line, or add a header line to the end
of the header.  These are special cases of replacing a header line.

Allows you to access the value (stuff after the :) of any header line.

Given a list of addresses, returns an array of canonicalized addresses.

The last item is the hard part.  It correctly parses the sample
addresses in the RFC-822 paper, as well as some really gnarly looking
junk that I threw at it.  It correctly handles the various types of
quoted strings, and backslash quoting, not splitting addresses at
quoted commas.  It removes nested comments from addresses.  It deletes
the group name from a list of addresses without screwing up quoted
colons.

It should be useful as a first step in alias processing.  That's what
I'll be adding next, when I figure out exactly how I want to do it.

-- eric messick
eric@toad.com

Hi,

  I'm fairly new here and not sure if this topic has come up before, but
I'll offer it anyway:

 In using encrypted communications, how does one avoid the problem of
calling attention to the message BECAUSE it is encrypted? "If he went to
the trouble of coding it, there MUST be something in there!!" Granted that
if everyone begins encrypting, this problem will vanish... are there
practical solutions in the meantime? (eg, Codes that look like plaintext?)
	
	
		Peter

->calling attention to the message BECAUSE it is encrypted? "If he went to
->the trouble of coding it, there MUST be something in there!!" Granted that
->if everyone begins encrypting, this problem will vanish... are there
->practical solutions in the meantime? (eg, Codes that look like plaintext?)

a good point indeed.  I know of no software that works the way it seems
you would like.  The best would be encryption software that makes your
'secret' message look like the kind of message that you would actually
be sending to the recipient.  Some kind of message that (when read by
a human) makes sense, and seems innocuous.  This sounds like a VERY
difficult problem, and one that is not likely to be solved any time soon
(in the sense of having this be done 100% by software).

Another option would be to have the message fit the letter-frequency,
letter-pair frequency, etc... that 'normal' messages have.  The idea
here is that messages may be scanned for unusual (i.e. non-english text)
properties in this regard, and then scanned further by humans and/or
computers in the order of their 'interestingness'.  So to defeat this
kind of scanning, your 'secret' message should 'appear' to be a 'ordinary'
message.

--

Edward A. Bertsch (eab@msc.edu)   Minnesota Supercomputer Center, Inc.
Operations/User Services          1200 Washington Avenue South
(612) 626-1888 work               Minneapolis, Minnesota  55415
(612) 645-0168 voice mail

Edward Bertsch says:
>
> ->calling attention to the message BECAUSE it is encrypted? "If he went to
> ->the trouble of coding it, there MUST be something in there!!" Granted that
> ->if everyone begins encrypting, this problem will vanish... are there
> ->practical solutions in the meantime? (eg, Codes that look like plaintext?)

Well, my opinion is - the only way to go is to SHORTEN the transition
period. Switch to all-encrypted e-mail ASAP.

> a good point indeed.  I know of no software that works the way it seems
> you would like.
> ............................................This sounds like a VERY
> difficult problem, and one that is not likely to be solved any time soon
> (in the sense of having this be done 100% by software).

Agreed. Theoretically possible - practically infeasible. Plus imagine
message size... Plus it depends on how clever a scanner-program can
be - if eavesdroppers have enough CPU power, they could check for
the "validity" as well, i.e. right word sequences, not just
amount...

> Another option would be to have the message fit the letter-frequency,
> letter-pair frequency, etc... that 'normal' messages have.  The idea
> here is that messages may be scanned for unusual (i.e. non-english text)
> properties in this regard, and then scanned further by humans and/or
> computers in the order of their 'interestingness'.  So to defeat this
> kind of scanning, your 'secret' message should 'appear' to be a 'ordinary'
> message.

Again, it will, or will not work, depending on how smart the scanning
program is. There's no reason why it can't detect, that your letters
don't form valid English (German, Swedish, Arabic, whatever) words,
*or* the words don't form valid sentences...

I repeat - the surest way is to get over the hump sooner.
--
Regards,
Uri         uri@watson.ibm.com      scifi!angmar!uri 	N2RIU
-----------
<Disclamer>


From cypherpunks-request  Tue Jan  5 10:49:28 1993

Peter Breton writes:

>  In using encrypted communications, how does one avoid the problem of
> calling attention to the message BECAUSE it is encrypted? "If he went to
> the trouble of coding it, there MUST be something in there!!" Granted that
> if everyone begins encrypting, this problem will vanish... are there
> practical solutions in the meantime? (eg, Codes that look like plaintext?)

The study of how to hide the _existence_ of an encrypted message is
called _steganography_.

Messages have traditionally been:

-placed on microdots and hidden inside letters, under stamps, etc.

-transformed into innocuous-looking messages ("Hello, Peter! Things
are going very well on this January morn.")...typically used with book
codes

-deposited in physical "dead drops," such as in tin cans by the side of
the road, in the branches of trees, etc. (all agreed-upon in advance,
of course)

The cypherspace domain offers new degrees of freedom for hiding such
messages:

-messages may be packed into the "least signficant bits" (LSBs) of
digital images, GIFs and TIFFs, sound samples, etc. As these bits are
at the "noise floor" for modern recording technology, message bits can
be easily made indistinguishable from "real" bits. A simple GIF image,
such as those posted worldwide in the various "pictures" groups, can
easily hold 50K bytes or more just in the LSBs (of each of the
colors). A standard 2-hour digital audio tape (DAT) can carry 80 M
bytes in the LSBs alone! (Imagine the Customs Department trying to
stop someone from carrying out the blueprints to the Aurora spy plane
packed into the LSBs of their favorite tape!)

-similar systems can be used to pack bits into the "ragged right"
margins of messages like this one, where the precise word spacing
carries some bits. Not very many, of course. And the spacing is
susceptable to munging.

-raw data, such as weather reports and sports scores, can be used.
Used since the dawn of espionage, and featured as a plot device in the
French thriller "Soft War," this method is certainly still possible to
use.


As the amount of bits moving around increases dramatically, so, too,
will the avenues for sending encrypted messages.

-Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | PGP Public Key: by arrangement.

On Jan 5, 10:19, Peter Breton wrote:
> Subject: purloined letter
> 
>   Hi,
> 
>   I'm fairly new here and not sure if this topic has come up before, but
> I'll offer it anyway:
> 
>  In using encrypted communications, how does one avoid the problem of
> calling attention to the message BECAUSE it is encrypted? "If he went to
> the trouble of coding it, there MUST be something in there!!" Granted that
> if everyone begins encrypting, this problem will vanish... are there
> practical solutions in the meantime? (eg, Codes that look like plaintext?)
The best way to prevent this type of traffic analysis is to encrypt
everything. As a second best, encrypt all correspondence with a specific
person.

Mark

-- 
Mark Henderson, SoftQuad Inc, 108-10070 King George Hwy, Surrey, B.C. V3T 2W4
Internet:  markh@wimsey.bc.ca, mch@sqwest.wimsey.bc.ca, mch@holonet.net
UUCP: {van-bc,sq}!sqwest!mch Telephone: +1 604 585 8394  Fax: +1 604 585 1926
RIPEM public key available by Email/finger mch@holonet.net/keyserver