- cypherpunks-legacy - lists.cpunks.org

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

17 Dec '03

Forwarded message:

1 0

A proposal for handling "forwards"
by doug＠OpenMind.com 17 Dec '03

17 Dec '03

How about setting up a second e-mail list on majordomo, called "cypherpunks-fwds" or "cypherxtra" or some such thing. I, for one, am quite appreciative of receiving such posts as Jim Choate's forwards... but my disk space is abundant and my connection is permanent and not metered. I can understand why many people would prefer not to receive such things. This way people can choose whether they want to receive these types of longish, possible repeats (including the EFF announcements) or not. I guess I can think of reasons this might not be such a good idea (the new list might be completely empty, or it might be flooded with garbage, etc). But there it is... Doug __ __ __ __ Doug Cutrell / ) /__) /_ /\ / /| /| / /\ / / ) doug(a)OpenMind.com \_/ / (_ / \/ / |/ | / / \/ /__/ ===================================================================

2 1

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

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: 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

"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

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

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

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