Testing for encryption. (fwd)
Yeah, yeah, yeah. Only problem is the constraint that GPG must be specified as the allowed source encryption standard a priori. This was NOT in the original problem description. There is NO algorithm which will determine if an arbitrary piece of text is encrypted by an arbitrary algorithm. You can tell, at least statistically if a particular piece of arbitrary text ISN'T a particular algorithm or language either. Again, not the same problem. ____________________________________________________________________ Before a larger group can see the virtue of an idea, a smaller group must first understand it. "Stranger Suns" George Zebrowski The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- -------------------------------------------------------------------- ---------- Forwarded message ---------- Date: 21 Feb 2001 19:44:33 -0000 From: Septic Remailer Admin <septic-admin@nym.alias.net> To: Jim Choate <ravage@EINSTEIN.ssz.com> Subject: Testing for encryption. -----BEGIN PGP SIGNED MESSAGE----- #!/usr/bin/perl # name: encryption_check.pl # purpose: Tests if STDIN is encrypted. Prints file to STDOUT if # it is encrypted. Discards unencrypted files. # requires: /bin/tempfile from debianutils, /usr/bin/gpg # TODO: # Does it need to detect Mixmaster messages? # It should handle pings (i.e. plain text) to another remailer # by checking rlist or some arbitrary whitelist. # author: septic-admin@nym.alias.net # date: 4 OCT 2000 # license: GPL if (!-x "/bin/tempfile") { die "requires /bin/tempfile"; } if (!-x "/usr/bin/gpg") { die "requires /usr/bin/gpg"; } my $TMP = `tempfile` || die "cannot create temp file"; my $ENCRYPTED = 0; # Store the file. open(TEMPFILE, ">$TMP") || die "cannot open temp file"; while (<>) { print TEMPFILE; } close(TEMPFILE) || die "cannot close tempfile"; # Test the file. open(GPG, "gpg --batch 2>&1 <$TMP|") || die "cannot open GPG pipe"; while (<GPG>) { if ($_ =~ /^gpg: encrypted/) { $ENCRYPTED = 1; } } close(GPG); # Insert code here to test destination against whitelist (for pings). # Print the file to STDOUT if it is encrypted. if ($ENCRYPTED) { open(TEMPFILE, "<$TMP") || die "cannot reopen temp file"; while (<TEMPFILE>) { print; } close(TEMPFILE); } unlink $TMP || die "cannot unlink temp file"; -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQCVAwUBOpQLgHT63FdzI1K1AQELwAQAr44gXDXjrHGzhF+Dj7YTw37hBkDrQaBf QhmCRf22ikzWEazvWIqCCMOMRd5nB+bD454JWI5G7QWAOHNvU8lL2S4kxRIFqNyr gA1vdrs5MlzRYQptjz2HpFpfx7BEO1mxsSXrlsCqOrNkAYmnhicfVgoMXcdYyQul Rvw13C4kasw= =UEL2 -----END PGP SIGNATURE-----
Jim Choate wrote:
Yeah, yeah, yeah. Only problem is the constraint that GPG must be specified as the allowed source encryption standard a priori. This was NOT in the original problem description.
that, of course, depends mostly on what you consider the "original". for the current FAQ thread, the original problem description given does read very much like using one specific software IS an acceptable option.
There is NO algorithm which will determine if an arbitrary piece of text is encrypted by an arbitrary algorithm.
nobody's discussing that point, jim. not now or in the past. we are all very well aware of the fact that you can easily define the problem in a way that is unsolvable. fortunately, most real-world problems do have constraints on them that redefine the problem to one that CAN be solved, often trivially. EOT
On Thu, 22 Feb 2001, Tom wrote:
that, of course, depends mostly on what you consider the "original". for the current FAQ thread, the original problem description given does read very much like using one specific software IS an acceptable option.
Supply the part of the message which you believe specifies the source encryption algorithm? ____________________________________________________________________ Before a larger group can see the virtue of an idea, a smaller group must first understand it. "Stranger Suns" George Zebrowski The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
Jim Choate wrote:
Yeah, yeah, yeah. Only problem is the constraint that GPG must be specified as the allowed source encryption standard a priori. This was NOT in the original problem description.
There is NO algorithm which will determine if an arbitrary piece of text is encrypted by an arbitrary algorithm. You can tell, at least statistically if a particular piece of arbitrary text ISN'T a particular algorithm or language either. Again, not the same problem.
Yes, but you >CAN< specify that PGP and GPG and OpenPGP and other flavors are acceptible. However, for a closed mailing list you simply require a particular (or a set of) flavor of email encryptors which the listserver will understand. Simple. Solved. Done. So your arguement is bullshit. These have clear text tags indicating what the encrypted data was encrypted with. End of story. You can check the level of entropy in a block, which will tell you that it is either random, random looking, or encrypted. Certain encryption algorithms MAY have some characteristics over just plain random data. For instance WWII engima had a flaw whereby if you encoded an "A" you would never get back an "A". This was very useful for Bletchley. If you're trying to detect whether or not there's hidden stego in something there are several ways to find out. One is simply if you get two copies of the same media, you can compare them. Another is to look for statistical differences in the low bits based on the program that generated them. You'll find that the low bits of audio for instance aren't all that random usually... etc... If you've got a good stego program, it will try to compensate for the bits it changes. Depending on how good it is, you can figure it out. -- ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :Surveillance cameras|Passwords are like underwear. You don't /|\ \|/ :aren't security. A |share them, you don't hang them on your/\|/\ <--*-->:camera won't stop a |monitor, or under your keyboard, you \/|\/ /|\ :masked killer, but |don't email them, or put them on a web \|/ + v + :will violate privacy|site, and you must change them very often. --------_sunder_@_sunder_._net_------- http://www.sunder.net ------------
Re: preventing accidental cleartext from getting reflected: If the mail agent blocks cleartext, great, your recipients won't ever be sent cleartext by your reflector. But we can make the problem harder if we care about someone sniffing the careless sender's message. To prevent this, you can either use an online-SSL system, or you can insist that your members set their email crypto plugin to *always encrypt* when sending to your list. If you're actually building an encrypted-only-remailer, may be able to save participants some tedium by having the remailer have one key for the list-submission-address, and resending messages with individual subscribers' key. Otherwise each subscribe must use a feature called "Groups" in PGP's Eudora Plugin 6.x (which they may not have if e.g., they use command line versions) and *each has to maintain a local copy of the membership list*, which defeats the purpose of using a remailer. Actually these functions belong in the listserver (remailer) not the SMTP agent. 1. filter on: list of acceptable substrings such as headers, 'CDR:' tokens, etc.; and/or entropy threshold and/or; recognized digsigs from members of the list 2. decrypt 3. for each list member encrypt msg from previous step and send ....... "What company did you say you were from, Mr. Hewlett?" ---Walt Disney to Bill Hewlett eetimes 22.01.01 p 32
At 05:54 PM 2/21/01 -0600, Jim Choate wrote:
There is NO algorithm which will determine if an arbitrary piece of text is encrypted by an arbitrary algorithm. You can tell, at least statistically if a particular piece of arbitrary text ISN'T a particular algorithm or language either. Again, not the same problem.
The problem is to find a reasonable way for a relay to refuse to forward unencrypted messages. So that participants don't accidentally reveal the discussion. *Not* to identify the language or cipher algorithm. *Where* do you get that idea? (Rhetorical, I realize who I'm replying to..) A general and reliable heuristic is to measure entropy. This will of course pass unencrypted compressed files (including possibly jpeg, mpeg, etc.). A more reliable 'cheat' is to look for headers. This can also enforce an additional (and perhaps unwanted) requirement that a certain tool is used. But again, malicious posters will be able to spoof this. ....... "What company did you say you were from, Mr. Hewlett?" ---Walt Disney to Bill Hewlett eetimes 22.01.01 p 32
participants (4)
-
David Honig -
Jim Choate -
Sunder -
Tom