December 2003 - cypherpunks-legacy

Remailer usage statistics
by ghio＠kaiwan.com 17 Dec '03

17 Dec '03

I added a new feature to my remailer. Send mail to ghio(a)kaiwan.com with Subject: remailer-stats for a list of statistics on remailer usage for the last 24 hours. It will report the number of messages remailed in the last 24 hours, how many of them were encrypted with PGP, and how many of them were delayed with latency (regardless of whether or not the message has been sent out yet). It also shows a graph of how many messages were received each hour. This should help people time their latent messages to arrive or depart at particularily 'busy' times in order to confuse someone who is attempting traffic analysis. Also, by popular demand, I have added a help file. Send mail to ghio(a)kaiwan.com with Subject: remailer-help and it will send you a help file.

1 0

Faster bit count on 680x0
by jimn8＠netcom.com 17 Dec '03

17 Dec '03

A few ways of counting bits without a lookup table were proposed. Here's a method that should be faster: ; (preamble) move.w (source)+,d0 clr.w d1 clr.w d2 ; bit count ; body of code that counts bits repeat 16 ; repeat the following section of code 16 times: add.w d0,d0 ; shift most significant bit into carry addx.w d1,d2 ; add zero in d1 plus carry bit to bitcount in d2 rpe ; end of repeated section The result in d2 is the number of 1 bits in (source). The repeated section of code is 64 bytes long, well under the cache size of an '020, so it can be repeatedly executed to count multiple source words without having to reload the instruction cache. My duties at Apple have constrained how much I can do for speech compression at modem rates (a project I want to do for secure phone applications, Cypherpunk style) but if anyone has some 68K code they'd like optimized, drop me email. Freeware type efforts preferred-- I already have a job :) - Jim Nitchals QuickTime engineering team Apple Computer, Inc.

1 0

Re: Remailer chaining helper program.
by ghio＠cmu.edu 17 Dec '03

17 Dec '03

roy(a)sendai.cybrspc.mn.org (Roy M. Silvernail) wrote: > Was it here that I saw mention of a program to generate chained remailer > traffic automatically> Pointers appreciated, and thanks! Well, I've had this file in my ftp dir for awhile... but I don't think anyone knew where to find it. Since it's short, I hope nobody will flame me for posting this. It's a csh script... I'm sure you can follow the general format and adapt it. You may need to replace 'queuemail' with 'sendmail' in the last line, depending on your system. cd ~/pgp ~/pgp/pgp -feat hfinney <~/private/anonmsg >~/pgp/remailers/temp echo "::" >~/pgp/remailers/message echo "Request-Remailing-To: hfinney(a)shell.portal.com" >>~/pgp/remailers/message echo "" >>~/pgp/remailers/message echo "::" >>~/pgp/remailers/message echo "Encrypted: PGP" >>~/pgp/remailers/message echo "" >>~/pgp/remailers/message cat ~/pgp/remailers/temp >>~/pgp/remailers/message rm ~/pgp/remailers/temp ~/pgp/pgp -feat catalyst <~/pgp/remailers/message >~/pgp/remailers/temp echo "::" >~/pgp/remailers/message echo "Request-Remailing-To: catalyst(a)netcom.com" >>~/pgp/remailers/message echo "" >>~/pgp/remailers/message echo "::" >>~/pgp/remailers/message echo "Encrypted: PGP" >>~/pgp/remailers/message echo "" >>~/pgp/remailers/message cat ~/pgp/remailers/temp >>~/pgp/remailers/message rm ~/pgp/remailers/temp echo "To: remailer(a)chaos.bsu.edu" >~/pgp/remailers/outgoing echo "From: mg5n(a)andrew.cmu.edu" >>~/pgp/remailers/outgoing echo "" >>~/pgp/remailers/outgoing cat ~/pgp/remailers/message >>~/pgp/remailers/outgoing rm ~/pgp/remailers/message /usr/andrew/etc/queuemail -f ~/pgp/remailers/outgoing -a remailer(a)chaos.bsu.edu

1 0

Anon Mailing List
by Jonathan Rochkind 17 Dec '03

17 Dec '03

I'm in the process of working on some perl scripts to implement a fully anonmous mailing list. I mentioned interest in this a month or so ago on cypherpunks, but i think it might have been during some of the list troubles, so many might have missed it. At any rate, I have very little unix programming experience, but since no one else seemed to be working on an anon mailing list, although sev eral people said they had given it some thought, I figured I might as well give it a try. The basic idea is simply that anon-remailers will be used, so that the mailing list doesn't need anyone's real address; it can send list mail to them through the anon remailers using encrypted re-send to blocks. Additionally, the list would send out all mail pgp-encrypted with the individual keys of list members. (yes, this could be proccesor-time-consuming). And incoming mail would be required to be encrypted to the list, and signed by a list member. And PGP-signature-checking would be used for authentication of unsubcribe commands, and such. Possibly, remote list maintanance with signature-checking for authentication might be coded. Anyhow, I'm not sure whether I should attempt to modify some existing mailing list code, or just write my own from scratch (which seems like it actually might be easier). But I could try to modify majordomo, or more likely SmartList. SmartList is some scripts and recipe files for procmail to implement a mailing list. procmail is a incoming mail proccessing program. I want to make sure this stuff can be run from inside a normal user account, if neccesary, which is easy to do with SmartList. I'm not familiar with the inner workings of majordomo. The reason I'd modify preexisting stuff is because they are already set up to deal with rather obscure possible errors in rather complicated ways that I might not want to duplicate myself. But I'm not sure how significant this is, and I'd really rather write it from scratch myself, and not have to deal with puzzling through someone elses code. (Yeah, I'm lazy). What do you all think? I've put in a little bit of meta-level effort in writing it from scratch. I've come accross DMB databases as a way of keeping the records of members pseudonyms, anon-remailer address blocks, and anon-remailer addresses. Is this a good idea? The documentation I saw on DBM databases suggested that there might be a unpredicable size limitaton of 1000 bytes or so, which could conceivably become prohibitive with especially long encrypted remailer address blocks. But I don't know of any other easy way to maintain such a database. I'm _not_ going to write my own database maintanance code; I wouldn't know where to begin. Any suggestions? I'd appreciate any input people have for me.

1 0

Re: Bit counting
by rarachel＠prism.poly.edu 17 Dec '03

17 Dec '03

Again, if its speed you want, you can't beat look up tables no matter how hard you try. A 256 byte table will work just fine, and it's four add statements with possibly a shift, but the shift too can be bypassed. Observe: int bitcount(long *value) { char *c; c=(char *) value; // convert long pointer to a char pointer. return table[c[0]]+table[c[1]]+table[c[2]]+table[c[3]]; } The above may be slightly less efficient than a XOR, ADD and SHIFT operation that the original function showed, however this is CPU dependant. For a 16 bit: int bitcount(int *value) { char *c; c=(char *) value; return table[c[0]]+table[c[1]]; } This will kick the ass of that call, because there's a single add and only two memory fetches. Further, for a single byte, you can implement this as a macro function which gets rid of all the overhead: #define bitcount(value) table[value] Granted, this wastes memory, but it depends on whether you're willing to trade clarity for speed. The three above functions assume lots of things about the bit size and such, yes, but that's not the point. They are CLEAR in their functionality, and FAST. The eight line function I showed is also clear in functionality, but is slower. Personally I'd rather have clarity than speed. I'm not interested in breaking cyphers as much as I am in writing them, so brute force isn't something I'd look to using. I've seen far too much weird code in my time to want to use that "simple" ADD/XOR/SHIFT function. As "simple" as it seems, there are alternatives. IF you want a really high speed method of counting bits, do it in hardware with a dedicated chip and shove it up the parallel port or directly on the machine's bus. If you're trying to break cyphers, you will undoubtedly do this. If you are not, it's far safer to write clean, clear, precise understandable code which won't require a second or thrid glance even with comments. (That of course is how this got started in the first place... the Cray Opcode that did this. :-) }

1 0

RE: Mass forwards vs. pointers
by Blanc Weber 17 Dec '03

17 Dec '03

From: Philippe Nave Does anyone have a FAQ (or a brainstorm) on how to route Microsoft Mail messages to appropriate folders based on message content? ............................................... 1. You can use the Message Finder feature in MS Mail to collect all of the messages, say To: "cypherpunks" and then move all of these to a folder. You can also select all the email sent directly to your name or to a specific alias, read these, and continue searching the inbox this way for messages groups. 2. There's a software program from Beyond Incorported called WinRules 1.0, which will filter incoming messages according to who the message is From, To, CC, words in content, attachments, etc. and route them to folders, optionally popping up a message or a sound as a folder receives email throughout the day. It also has some other neat features which you can set to deal with email traffic. Blanc

1 0

Re: Request: tamper-proofing executables
by Ian Farquhar 17 Dec '03

17 Dec '03

>This is as useful as writing your own PCode interpreter and encrypting the >PCode as it runs. Whoop de doo. :-) Somewhat easier, though. And utilizing single-step defeats a lot of debuggers too, who don't expect programs to use it. The tool of choice for killing such systems is an ICE, although most hackers do not have access to these. >Capture it in memory, save the memory >image to the disk, write some code to reload it, and restart it again. Exactly the point I made in the original article: the code to do the decryption is vulnerable. >There's no way to do this securely without hardware. Ditto in my original article. >The best thing to do is to build a custom CPU with custom RAM and seal it in >some epoxy with self destructive materials in it. This is excruciatingly >cumbersome, and you have to deal with the problem of heat dissipation. (Since >the CPU is a custom made one, you can't simulate it or break it. Since you >have no access to RAM, you can get RAM images, etc.) And it's not particularly secure, either. There are well-known techniques for defeating such approaches. These are discussed in the CMU paper I referred to. Ian.

1 0

"uncrackable" executables
by dfloyd＠runner.utsa.edu 17 Dec '03

17 Dec '03

As to altering MS-DOS executables, the only option that I see that someone cannot go through is a dongle with the MD5 image signed by your public key burned on the ROM. The dongle will be optional, and for user verification that the program works. I wonder if one can boot off the dongle... have it do its tests in rom on applications....?

2 1

Framed by another state for a non-crime
by hkhenson＠cup.portal.com 17 Dec '03

17 Dec '03

If anyone has a good contact with the ACLU, this is a time to use it! Date: Sun, 10 Jul 94 16:49:03 PD Lines: 83 DRAFT MOTION (Note this is not a motion, but an early draft by a non-lawyer -- -me- about one aspect of the AA BBS case. I have been very concerned with what I have found about the performance of the courts. It has turned out to be a lot worse than I thought. Keith Henson) On July 8, 1994 Judge Julia Smith-Gibbons, United States District Court for the Western District of Tennessee in Memphis TN, verbally ruled that defendant's motion to dismiss (improper venue based on the North American Free Trade Agreement and others) was denied. Her words were that her order denying the motion was "in the typewriter." Defendants and defendant's attorney expect (on the basis of her previous judicial conduct) to be handed the written order at the time of trial, precluding any interlocutory appellate remedies. Defendants Robert and Carleen Thomas are therefore forced to appeal Judge Gibbon's ruling without an order reduced to writing and signed by the court. However, her verbal ruling is "final" with respect to this issue. If this interlocutory appeal were delayed until after trial the Thomases' would be irreparably harmed, even if acquitted. Not only would they lose the cost of trial, which could not be recovered civilly, but they would have to shutdown their business as it requires part time physical presence. (Trial in this area would not be as onerous in that the business could continue to be operated with a few hours attention each night.) These motions are being filed in both the Sixth and Ninth Cir- cuits because the underlying case involves an *assault* on the authority of the Circuit Courts, and therefore upon the entire court system. When the Courts lose their capacity to function normally it is termed insurrection. The case at hand may be close to this state. As is made clear by attached documents, a *district* court in the Sixth Circuit is attempting to enforce authority over persons and property in the Ninth Circuit on the basis of a manufactured "crime". The gross inequity performed by law enforcement agents in manufacturing the child pornography charge could be proved at trial, but the *law* on which the "crime" is based (Title 18, Section 2252 of the Federal Code) has been ruled "unconstitutio- nal on its face" in the Ninth Circuit (US vs X-citement Video, Inc., 982 Federal Reporter Second Edition, page 1285, Dec. 16, 1992). At the time of the search of the Thomas's home and business, (January 10, 1994) this statute *could not* be used to prosecute *any* person in the Ninth Circuit because it is an unconstitutional law, and unenforceable. (Judge Gibbons was notified on June 22, 1994 of these facts.) On January 26, 1994 a Federal Grand Jury in Memphis Tennessee returned an indictment against Robert Thomas citing section 2252, a section which *could not be applied* by any Ninth Circuit District Court to a citizen in that circuit or any other Circuit. (There were other sections cited including section 2256 calling for forfeiture of tens of thousands of dollars of computer hardware to the Tennessee authorities, and possibly the sysops home, car, etc.) The effect--if a district court in one section of the country is allowed to charge citizens on laws ruled unconstitutional in the Circuit where they live--is to completely undermine the authority of all the Circuit courts in the country. This case is about liberty and property, but taken to the extreme, a person could be removed from his home by a District Court operating in another part of the country and executed. This appeal is about nothing less than the authority of *any* Federal court to protect the life, liberty and property of any citizen of the United States. If this appeal is not granted, it will show that the District courts can ignore another Circuit's laws and do anything they want with a citizen's life, liberty and property. It will show that the Circuit courts do not have the authority to protect life, liberty, or property for the people within their circuit, and ultimately will undermine the courts ability to protect any inhabitant of the United States. (Net.folks--please comment!)

1 0

Bug in PGP2.6 when editing your key
by Jeffrey I. Schiller 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- We have found an important bug in PGP 2.6 (and 2.5). Problem: If you store your pass phrase in the PGPPASS environment variable or supply it via the PGPPASSFD hack and you edit your key (pgp -ke) you may lose. Specifically if you edit your key and do *not* change your pass phrase, then it gets clobbered and you lose access to your private key. What to do if this happens to you: You will know that this has happened because you will edit your key and then not be able to use your private key. *IMMEDIATELY* restore your secring.pgp and pubring.pgp from the ".bak" versions that PGP automatically creates. This will put things back the way they were. Work Around: You can avoid this problem when editing your key by doing one of the two things below. 1) Remove the PGPPASS environment variable (or don't use PGPPASSFD) when editing your key. You will then have to manually type in your pass phrase when editing your key, but the pass phrase will not get clobbered this way. 2) If you still use the PGPPASS environment variable, then when the key editing process asks you if you wish to change your pass phrase answer "y" (i.e., tell it that you wish to change your pass phrase) it will then prompt you twice for your new pass phrase. Note: You can set it to what it was, effectively not really changing it. PGP will not know the difference and your pass phrase will not get clobbered. Status: This problem has a known fix and it will be included in the next release. -Jeff -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAgUBLiCWkVUFZvpNDE7hAQF/GQIAoWi86mx1TylR5CUWInJrYy/L5kNB0qqB Uo/gA+u4M7YYeFEVF+voeBBRW686j2ksWaMA3ERTN8o6HWc5hrcf+A== =fXWk -----END PGP SIGNATURE-----

1 0