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.
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
On Jan 5, 10:19, Peter Breton wrote: 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
participants (6)
-
eab@msc.edu
-
eric@parallax.com
-
mch@sqwest.wimsey.bc.ca
-
Peter Breton
-
tcmay@netcom.com
-
uri@watson.ibm.com