December 2003 - cypherpunks-legacy

DC nets
by John Clark 17 Dec '03

17 Dec '03

I want to thank Tim May for his posting on DC nets, you packed a lot of information into a short post and I have NEVER seen it explained more clearly. John K Clark johncla(a)freenet.scri.fsu.edu

1 0

Escrow Officer Trading Cards <fwd>
by rarachel＠photon.poly.edu 17 Dec '03

17 Dec '03

Forwarded message:

1 0

No Subject
by nobody＠rebma.rebma.mn.org 17 Dec '03

17 Dec '03

about the credit card transactions. i was stupid and lost the one reply that showed interest. but the data i have is for one network only. it's TeleMoney, run by Ceridian (used to be Control Data), and there's no encryption on the transaction at all. the information would end up pretty long, and i don't want to bomb this list. interested people should send me mail instead. include a pgp public key. to get mail to me, use remailer(a)rebma.mn.org and include the following at the beginning of your message: :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.6 hIwC15oMrSC6gKkBBACF5WvZBz0336fvlIJslMD02PCVJM/5hZeC85Uwd88Z9u8k 9Cbs979V6N/JqqOQmC/88u58sFyYqqsRGrxxjhjZGEeE0wDHRniS4ALjts/22dry NYr7ep9O4nzYtHU4ac1BeYm1AbSyk4jbjSIw8a6D0l6SI3L72alKSQxCzyZvkqYA AABQoCjtMyZ8kngK9ZCf3vR9l1yltdp/QoiWBXLhZ43VMi/GIV8VWcVsL5KD9lTW QRC5Kxpq0RqOazjdrdxPOaN9/43IIVPAj50KnKpSyFyWnf0= =bdsK -----END PGP MESSAGE-----

1 0

Re: Request: tamper-proofing executables
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Tamperproofing things that aren't hardware is difficult. If your code is sufficiently non-obfuscated to be worth tampering with, Bad Guys can tamper with the tamper-checking code just as easily as they can with the useful-stuff code. One way around this is to leave digital-signature-checking to exterior programs, e.g. include a PGP signature (probably in a separate file to avoid mushing it into your binaries) and let them check the signature from their own copy of PGP. (Or for cheapness without patent problems, distribute a RIPEM-sig instead.) Some people have suggested code that does things like encrypt some critical parts of the code and decode them on the fly at runtime, using a key that's generated by checksumming the file and XORing with the last 8 bytes or some variant. Sufficiently persistent Bad Guys can respond to this by grabbing the code from memory as they run it, and you can play games with them about decoding stuff a piece at a time, etc. (All of this is of coure easier in LISP or interpreted languages.....) How much work you want to put into this depends on how much effort you think the Bad Guys are willing to spend cracking your code. I've heard people talk about doing totally encrypted computation, but I'm not sure whether anything practical hs been implemented. Bill # Bill Stewart AT&T Global Information Solutions, aka NCR Corp # 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 fax-6399 # email bill.stewart(a)pleasantonca.ncr.com billstewart(a)attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465

4 3

Xerox glyphs
by John Young 17 Dec '03

17 Dec '03

Pointer: Xerox glyphs encoding process. Publication: The New York Times, July 10, 1994; Section 3; Business; p. 9. Title: Smart Paper Documents for the Electronic Age. Subhead: A new coding method hides computer data in plain view, By: John Holusha. A quote from an illustration: A Xerox technology, known as glyphs, would enable paper business documents to carry thousands of characters of information hidden in unobtrusive gray patterns that can appear as backgrounds or shading patterns. Glyphs could be used for encoding machine-readable data onto paper documents.

2 1

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

using RSA-the-cryptosystem to secure RSA-the-company's patent?
by Jef Poskanzer 17 Dec '03

17 Dec '03

Apropos the recent thread on tamper-proof programs... Can anyone think of a way that RSA-the-company could include some sort of RSA-cryptosystem-secured check in a release of PGP so that it would only interoperate with other versions that have the same check? I don't see how it could be done, but it's sure an intriguing idea. --- Jef

2 1

Re: using RSA-the-cryptosystem to secure RSA-the-company's patent?
by Jef Poskanzer 17 Dec '03

17 Dec '03

>The point of this is, why would *you* care? I can understand why RSA >_might_ care, but I don't see Phil Zimmermann agreeing to it, and I >don't see how anyone could force it into PGP at this point. They got the stupid version number thing in; if they had thought of a better trap, they could probably have gotten that in instead. The point is, the secret key would not be in the source code. I can't think of a way to use that; you can't; RSA couldn't; but I'm not convinced it's impossible. --- Jef

2 1

LD's Cypherwonks list
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Peterwheat(a)aol.com: > found this by doing a keyword search (cryptography) in America Online's > database of mailing lists. I thought it might be of interest to the > cypherpunks mailing list: > > CYPHERWONKS: The Development of Cyberspace I subscribed to this when LD first announced it early last December. I never received any mail. At that time I do believe Julf had said something supporting this list. Incidentally the address for LD in your database on AOL is ancient. And the description message seems watered down. The original post was full of LD's paranoid gems -- here's an excerpt for your entertainment: > anonymity. However, we do not necessarily believe that others are > required to read anonymous postings. To the contrary, we believe that > the individual should have the tools and freedom to filter his or her > own mail based on real identities. In particular, we condemn the > practice of `pseudospoofing,' the dangerous deception where a person > builds up a pseudonym and misrepresents it as being that of a real > person's identity. We police each other on the list to prevent it, and > require a promise that our members refrain from it. While our trust can > be betrayed, only those that are honest are true cypherwonks, and > anyone who betrays our trust we consider a dishonist hypocrite, or worse, > a *traitor* Note the Detweilerese: pseudospoofing, honest and true, hypocrite, *traitor*. ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "Clean the air! clean the sky! wash the wind! rishab(a)dxm.ernet.in take stone from stone and wash them..." Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

PGP for Russia...
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

"Robert M. Humphrey" <Robert(a)rmh.khabarovsk.su>: > Anyone with any ideas how I can get going on PGP or something else under > the circumstances would be more than welcome. Do you have telnet/ftp access? I believe the .su domain does have full Internet connectivity... If you do, you should pick up PGP version 2.6ui from ftp.dsi.unimi.it /pub/security/crypt/PGP/pgp26uix.zip Even if you're a US citizen you can't export PGP from the US under US law, so don't try it from CompuServe. If you don't have net access, the only way is to have someone split PGP into dozens of UUENCODED parts and mail it to you. If no one else volunteers to do this from outside the US, ask me. (Yes, I am lazy, and maybe someone's already got a split UUENCODED PGP ;-) Rishab ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "Clean the air! clean the sky! wash the wind! rishab(a)dxm.ernet.in take stone from stone and wash them..." Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

Tamper-Proof Software? No!
by collins＠newton.apple.com 17 Dec '03

17 Dec '03

Hello, Software only products cannot be made unconditionally tamper-proof, for the following definition of `tamper-proof': "An attacker, on their own machine (over which they have complete control), given a copy of the software that `runs' on that machine but includes mechanisms so that it won't run under certain conditions (the `tamper-proofing'), cannot produce a piece of software that lacks the tamper-proofing." By this definition, I am not addressing, e.g., pirates attempting to unlock a software distribution without the key, nor getting a bogus agent to run in a protected environment like Telescript, nor programs where a significant part of its functionality happens inside a physically tamper-proof `dongle'. Tamper-proofing is a fundamentally different problem from secret communication. The latter is `How can two parties exchange information such that no third party can learn it?' The former is `How can one party tell a secret to a second party, and at a later time, take it back?' You can't `un-tell' a secret. The functionality of your program is the secret. If that secret is revealed (and when you run the program, it will be) there's nothing left to protect; the secret is out. Tamper-proofing mechanisms amount to questions, answers, and actions. Each can be supplied by either the software itself or some outside entity (e.g., the OS, a `dongle', a network key-server, etc.). They come in many forms, but they can be reduced to "Is this the original software?", "yes" or "no", and `continue' or `quit'. In the case where it is the software itself that decides whether to run or quit (and since the attacker has complete control over the environment, it must be), the attacker is not constrained to defeating an arbitrarily hard authentication scheme. It is sufficient to avoid the test or refuse to quit. Replace each call to a tamper-detection routine with a call to a routine that has the same side-effects as the original would when no tampering has occurred (which can be observed). Thus, if the software checksums itself---remove the code that asks for the checksum, or remove the code that quits if the checksum doesn't match. If the checksum is required to decrypt some part of the program---build a copy of the software that is already decrypted, or use the saved checksum from an original run. If the program uses the value returned by a dongle to decrypt part of itself---watch it happen once, then keep the decrypted part. If a network server won't give you an open socket until the software answers an unpredictable question about itself that the modified program cannot answer---relay the question to an unmodified instance of the program. Sooner or later, in the course of execution, the `useful' part of your software will be presented, unencrypted and ready to run (if not without strings) to the CPU. Even if this happens only a little bit at a time, the attacker can record those hunks and assemble them into a new, unencumbered package. The attack might not be cheap! But people will do it if the reward exceeds the cost. If there is functionality you want to protect unconditionally, don't give it away! Sell a service instead. Hope this helps, Scott Collins | "That's not fair!" -- Sarah | "You say that so often. I wonder what your basis 408.862.0540 | for comparison is." -- Goblin King ................|.................................................... BUSINESS. fax:974.6094 R254(IL5-2N) collins(a)newton.apple.com Apple Computer, Inc. 5 Infinite Loop, MS 305-2D Cupertino, CA 95014 ..................................................................... PERSONAL. 408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Forwarding & Reference Pointers
by Stuart Smith 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >greg(a)ideath.goldenbear.com (Greg Broiles) writes: >> Count this as a vote in favor of pointers to information instead of >jgostin(a)eternal.pha.pa.us writes: > Count this as a second, plus some kind of summary of the article >referenced. :-) This is a silly way to prove a point, but count this as a third.. <sigh> - -- Baba baby mama shaggy papa baba bro baba rock a shaggy baba sister shag saggy hey doc baba baby shaggy hey baba can you dig it baba baba E7 E3 90 7E 16 2E F3 45 * 28 24 2E C6 03 02 37 5C Stuart Smith <stu(a)nemesis.wimsey.com> -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLiAWI6i5iP4JtEWBAQHfEwQAjBsf3djmjC+x6iCGZQVfQTbLqic+CgBy pM/TFLVZWd7GxmsQSG8oOXpyo4WnAVDDsj2p/o7jNArUSFotbB5ZNEWJgrQV7c0Y MVj08Tj4YtnPzfZaa9y3qN0R01smLp/q6RwiM2c2THRXkA7egqO0MXwUHyN2+wIN ua3UJz8nhww= =rNRk -----END PGP SIGNATURE-----

1 0

Re: Bit counting
by gtoal＠an-teallach.com 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. Ray, you've missed the point of some of the explanations; VERY FAST cpu's as unbelievably fast as long as they are executing *on-chip* - as soon as they have to go to RAM for a table lookup, they suffer a performance hit equivalent to executing large amounts of in-line instructions - one array lookup might be worth 200 straight opcodes. Hence why an in-line scheme has to be found for critical inner-loop stuff. The precise details vary according to the pipelining and the amount of on-cpu instruction cache. G PS We'd seen the Escrow Officer Trading Card skit on t.p.c when it first was posted a couple of months ago ;-)

2 1

Cross-posting problems
by m5＠vail.tivoli.com 17 Dec '03

17 Dec '03

I don't know much about how the majordomo software works, so this suggestion may be impossible. A solution to the decision point Mr. Choate and others find themselves in opposition over might be to add functionality to the list software that would allow articles to be cross-posted in a more sophisticated way. The article could be routed to a special majordomo sub-address which would file the article under some supplied title and then post to the list a brief announcement that the article had been deposited there. There'd be another "ftp" server port for retrieving the articles. Clearly, some provisions would have to bee made for sweeping out the repository, but with some discipline this seems like it might make everybody happy: those who dislike the volume of the direct crossposts would be able to skip by based on subject header alone. Those who appreciate the opportunity to read something they otherwise missed would have a pretty easy time fetching the articles. [ If this is already possible, or if it has been suggested and even beaten into the ground, I apologize; I haven't had much caffeine yet this morning :-] | GOOD TIME FOR MOVIE - GOING ||| Mike McNally <m5(a)tivoli.com> | | TAKE TWA TO CAIRO. ||| Tivoli Systems, Austin, TX: | | (actual fortune cookie) ||| "Like A Little Bit of Semi-Heaven" |

1 0

Re: Tamper-Proof Software? No!
by rjc＠gnu.ai.mit.edu 17 Dec '03

17 Dec '03

In your essay, you overlook the use of pseudo-code interpreters and cryptographic code mangling. It is not possible to make software unconditionally tamper proof, but it is possible to make it hard, perhaps as hard as finding a hamiltonian of a graph. I speak as a person with a 3 year cracking/tampering background. Let me pass on an experience I once had: I was trying to crack this game with a dongle. The code had dongle checks spread throughout it. I thought I could merely search for the signature of the dongle check and fix all of them, but the check was different each time, disguised by indirect addressing, illegal instructions, interrupt tricks, and stack tricks. The only solution was a tedious process of tracing the execution of the program and backtracing the failure routine. That wasn't the only problem though. On top of the dongle checks, checks for the dongle check routine and various checksum routines were spread throughout the code. In fact, there were so many of these checks that trying to separate the "useful part" of the program, and the dongle checks was hard because they were virtually everywhere. yes, it cost the game speed, but the game wasn't one that was particulary synced wih the display. Anyway, it took about a week of hacking on and off to find them all. There were about 30. What if there had been 1000? What if the code wasn't pure assembly, but a p-code interpreter which executed not a straight byte-code, but an actual recursive encryption algorithm in the interpreter? In other words, 0x80 might stand for "add a to b" in one instance, but in the next instance, "suicide mode" Perhaps the library i/o for the p-code itself also changes/gets mangled through the process. Furthermore, let us assume that this mangling is in some sense, cryptographically strong. A few things become very hard: 1) writing a decompiler for the general case 2) separating the "application" from the "protection" Why? Because in some sense, you'd have to rewrite the interpreter, or the application to remove all the "suicide" instructions. The p-code could be set up so in fact, most instructions are suicide unless decrypted properly. Thus, if you were to remove one suicide instruction, all of a sudden, a perfectly legimate section of code would become riddled with them. Removing protection would no longer be as simple as "NOPing out" the instruction. The code would be, by the nature of the interpreter, interdependent in a way far deeper than "checking for the presence of the dongle check routine" (note: this scenario is not isomorphic to the usual protection trick of having an interrupt decrypt the next instruction to be executed and encrypting the previously executed instruction. In that scenario, the re-encrypter can be disabled, so that after a complete execution, the code is plaintext for the debugger to save to disk. Here, the problem is that the code is never "decrypted" in the first place. What changes, is the meaning of the instruction set itself.) I suppose, one could attempt to isolate the suicide routine and just make it do nothing. That still doesn't solve the problem that a section of code has been mangled and probably not doing what it is supposed to. While a determined hacker could still break through this, I'd say that it would make the effort not worth it in most cases. Currently, most software protection is so simple that an hour of so in a debugger can isolate a manual check, and remove it. Most of the time, code is only skimmed. My cryptographic p-code proposal forces the hacker to virtually disassemble and understand the function of the entire interpreter, write a decompiler, remove any protection algorithms from the code, and then somehow, fix the interpreter so that the code still works. Imagine the task of having to create a plaintext which will generate a certain MD5 hash. Here, you'd have to remove the protection, but make sure the cryptographic execution flow of the interpreter matched the original. i.e. coming up with *different* code (sans protection) that causes the interpreter to decode the stream in the same manner. (if you want to know how code is p-compiled, I can explain later after I flesh it out more. I suspect I am probably reinventing the wheel for the Nth time, but I haven't read anything on it, so I may as well make a fool of myself.) Instead of picturing my p-code proposal, picture a much simpler idea. A seething morass of code, most of it garbage, protection decoys, all of it interdependent with other checks (chained in various ways), and somewhere in the middle of it all, is the application. I don't care what romantic vision of teenage hackers you have, it is possible to make removing the protection require the effort of rewriting a large chunk of the application. One of the other things I used to do was "NTSC fixing", taking PAL frequency games and fixing them for US computers. In some cases, it was simple (chop off the bottom of the screen, adjust rasters and timing) But sometimes, it required rewriting a portion of the graphics engine. This was no joy and sometimes I just gave up. If crackers had to alter just 10% of an application to get it to work unprotected, I think that would be a sufficient deterrent to most of them. Depending on how much speed you wanted to trade off, you could probably make the code arbitrarily "deep" (or, as Tim likes to talk about, imagine a hacker that has to crack a program encoded as DNA!) digression: Now grant me something more powerful. Imagine in the future that most software is in the form of distributed objects and that many of those objects reside and execute on remote systems. If these remote systems require cryptographic authentication before they allow a remote execution (e.g. Telescript), copy protection can be conditionally secure as RSA. Cracking would require writing a replacement object or buying one, presuming of course, major objects weren't trade secrets and you only had the API to work with. (once again, the function arguments could be permuted crytographically, so that even if you had the API, you still couldn't write a replacement) The result, is that you'd have to pay for software because software would consist of a client + object services, and the objects would require cryptographic cash/authentication to use, and replacements would be hard to write. However, unlike dongles, the system would be totally automatic and convenient, so there would be none of the problems associated with traditional protection (pain of look-up-in-the-manual or dongle). The same system could be extended to hypertext publishing where documents are distributed all over the net in different databases. One could pirate a "snapshot" of a document, but what makes the documents valuable is the dynamic quality of hypertext, being able to lay it out however you choose, and follow links. This means you need constant access to the databases, and therefore you pay for the service. My point in writing all this, is to disagree with Tim's implication in the cryptoanarchist manifesto, that cryptographic technology will eliminate intellectual property. Cryptography doesn't eliminate barbed wire, it is the ultimate fence. While it could provide untracable networks for "information laundering", it can also provide authenticated networks for unpiratable software, or teach us how to compile code in a manner that is "expensive" or as Tim might say "logically deep". (too deep to unravel its full meaning.) (I agree if Tim meant that it would make *legal* protection of iprop impossible, but I consider legal protection irrelevent anyway. If I need something protected, I'll do it myself, not depend on government) Well, I've said my peace. Now Tim can tear my argument to pieces. ;-) -Ray Any and all mistakes the result of lack of sleep...ZzzzT. "Information wants to be free..." "Not if Mathematics has anything to say about it."

1 0

Mass forwards vs. pointers
by Philippe Nave 17 Dec '03

17 Dec '03

On the off chance that someone is actually keeping score, I'll cast a vote for pointers instead of forwards. I don't pay for access (look closely at my address to see why), but my mail setup lumps all my mail in the inbox indiscriminately; to find critical messages from co-workers and automated software processes, I've got to wade through all the mail from the lists I subscribe to. This morning, there were 80+ messages from cypherpunks alone. If this list becomes, in effect, Usenet without Usenet newsgroup mechanisms, I'll have to bail out in order to get anything done for my Real Job (TM). I used to get Cypherpunks mail on a Unix box, and there I had a slick little Perl script sitting in my mail pipe to route Cypherpunks mail into a secondary Elm folder. This was nice, since it routed mailing list traffic away from my standard inbox. Now, though, I'm running through Microsoft Mail - until I figure out a way to separate list traffic from other mail, I'm really touchy about high-volume list traffic. Does anyone have a FAQ (or a brainstorm) on how to route Microsoft Mail messages to appropriate folders based on message content? -Philippe (No .sig, no PGP sig either - damn PC WinDoze mail software ......... )

1 0