- cypherpunks-legacy - lists.cpunks.org

Re: Contempt of court
by karn＠qualcomm.com 24 Jun '93

24 Jun '93

At 08:50 AM 6/17/93 CDT, Mike McNally wrote: In the days of >yore, numbers runners and gangsters and nefarious bad guys would keep >records on cellulose (?) flash paper which could be ignited and >destroyed very rapidly should Elliot Ness be seen approaching the >front door. Nitrocellulose. Very popular before the development of cellulose acetate, mylar and other modern polymers. It was the standard material used for movie film stock, which explains the bunker-like construction of the projection rooms in many older movie houses. Newer theaters often display signs in their projection rooms saying "Safety film only". (Now you know the meaning of the phrase "KODAK Safety Film" along the edges of your print negatives.) Today the main civilian use of nitrocellulose that I know of (other than in smokeless gunpowder) is to make ping-pong balls. Try igniting one sometime (in a safe area!) >Another (simpler) suggestion made by a friend was to devise >motion-sensitive devices which would cause total corruption of >information stored on a disk if it were moved. I've heard Gail Thackeray claim that hackers she'd raid would put big electromagnets in doorways to erase magnetic media as it was being seized. She never actually gave any proof of this, and it did always seem just a little far-fetched given the relative ease with which a hacker could just encrypt his/her incriminating data. I once asked her what she'd do once the "bad guys" started encrypting, and she said "I'm hoping you guys will tell us". (At the time I was one of the so-called "good guys", working for Bellcore.) Phil

1 0

An Awsome party coming up
by crunch＠netcom.com 23 Jun '93

23 Jun '93

Greetings Cypherpunks!! We are looking for folks with laptop computers with both MS-DOS and Mac compatability to participate in an upcoming fun event to take place at Pyramid lake in Nevada. The dates are 16th thru 18th of July, where a table will be set up for those with laptops. Our purpose and goals are to make copies of PGP available to those that don't have net access, generate PGP keys, sign keys, and hand out literature to those folks interested in cryptography and the Cypherpunks cause. The event itself will offer a great time to those attending, as there will be camping, swimming, and raving, as well as other happenings to make a total memorial weekend. The event costs $30 for the weekend, and the money goes towards the Western Shoshone and Paiute Indian nation, so the money goes to a worthy cause. I am trying to set it up so that those bringing laptops and who are willing to sit at the table for a period of time, copying disks, generating PGP keys, signing keys, etc will NOT have to pay the $30. What we need from Cypherpunks: ** Make up some brocures and hand out material describing the interests of the Cypherpunks. These can be created using PageMaker, or other page layout software, and can be xeroxed for handouts. ** Volunteers who have laptops (Both Dos and Mac, and possibly others) who can make them available for key generation, PGP distributions, etc. They would NOT have to let their laptops out of their sight, but just be there for a specific time to answer questions, and do what was previous described. So, do we have any volunteers willing to participate in this rather unusual venture? For those people out of the area, and who might be planning a trek out to the west coast, this might be a great time to come. Pyramid lake is out in the Nevada Desert, there is NO shade, so tarps and other camping equipment would also be necessary and desirable. Anyone with RV's, Campers, etc would be really useful for the ocassion. So be looking forward to a great time. Bring your family and kids, I'm sure they will enjoy the happenings, as there is also swimming, horse back riding, fishing, and all of the other camping activities. Brings lots of water, ice, and drinks. Please contact me, and I'll try and put it all together. Right now, I need to collaborate and work on the wording of the brocure. Thanx John D.

1 0

Re: Digital Cash$$$$
by bear＠eagle.fsl.noaa.gov 23 Jun '93

23 Jun '93

>As far as using digibanks on Native American territory, most of the >rules restricting Federal control seem pretty flexible when the Feds want >something, and even states can often get away with restricting gambling >on reservations. Also, the Constitution gives CONgress the power to >regulate commerce with foreign nations, Indian tribes, and between states, >so they can still regulate any interactions between digibanks on >Indian reservations and elsewhere. (Sigh - the Commerce Clause has been >rabidly overused, but it's written in a way that lets them do nearly anything.) This still raises some interesting possibilities: Items: Federal law requires that Indian tribes be permitted to offer all forms of gambling permitted _anywhere_ under state law. Indian reservations have a serious problem with poverty, unemployment, etc. Most gambling is hard to arrange at a distance, but it is possible to form _digital cards_ and then play any of the usual card games. Idea: An Indian tribe in an appropriate jursidiction installs a Internet node with digital cash (backed by checks, credit cards, etc) and _digital cards_. Or even a Compuserve account. (ugh). Anything, as long as the processor is located on Indian land. It offers real-time poker games. For real money. From anywhere in the world. :-) (BTW, you would _not_ offer blackjack, or only with _very_ large decks, because of the large potential for card counting programs). Just to confuse issues further, the poker software is owned by a nonprofit organization and licensed to the Indian nation with the condition that a portion of their profits go towards education. When someone claims that the tribe is offering gambling in an area where it is prohibited, you can legitimately claim that the actual processing is done on the Indian land; the only thing done in other jurisdictions is communications. Example: if a man stood just outside of the reservation and yelled instructions to a confederate at a game just inside the boundary, would that be illegal gambling _on the part of the House_? In this case, digital cash isn't _required_ since the House could simply keep accounting records directly. However, it would make it simpler for the House to honor outside bets, if a person could get a "chip" from the House, pay off a bet to a third party with the "chip", and then the third party could use the "chip" himself. Bear Giles * * Don't let them index you on a key field. Order my Special * * Report "How to Defeat a Data Base and Preserve Your Privacy" * * * ********************************************************************

1 0

Re: weak stenography and hiding readdat.exe
by skyhawk＠cpac.washington.edu 23 Jun '93

23 Jun '93

The simplest effective way I know of to hide an executable (such as readdat.exe) is to have it masquerade as another program, preferably one that is complex enough to justify its size. (You couldn't hide PGP in cat, but you could hide it in Mathematica.) You'd want the original program to be something you compile yourself, like some large X program, or gcc, or emacs. (You can hide *anything* in emacs. In fact, you can make pgp a hidden *primitive* in emacs. Hmmmmmm... Or Perl. Hmmmmmmm.....) That way you don't have a file that differs noticably from your OS release (they might check sizes and checksums), and you don't want to bother with patching a binary anyway. Then you've got the problem of invoking the alter ego of your program. Methods I've used in the past include new command-line flags, time of day, multiple "normal" invocations with slightly strange flags (this would save simple state information in /tmp), and special environment variables. To avoid leaving a trail to the hidden goodies, it's important to wipe any special arguments from argv[] (or your language's equivalent), insure that any special environment variables look completely innocent since ps(1) will display them to anyone who asks, (both assuming you're on a multiuser Unix box), and to not leave an intact .history file where some bright anti-subversive in the SS lab could see it on your confiscated hard drive, or your university's confiscated backup tapes. To make cleaning up simpler, you could hack your shell's history mechanism to not put incriminating strings into your .history. Leaving a false trail is better than simply removing the real trail, after all. (You wouldn't really need to do the same thing for your accounting log, if your machine keeps it at all, since it would only have the name of the executable. It would be important, though, that your program's public function be something that you could credibly be using 20 times a day. Compiler, linker, editor, finger, archie...) I've never had to worry about someone running a virus-style checker for naughty code, since mine's all been home-grown, but if there is a particular routine (say, pgp) that's hidden all over, Nick Szabo's excellent idea for using a virus-type mutation engine would be essential. For distribution of something like this, all we'd really need to do is co-opt some project that is distributing code on the net already, preferably something big. Then we could set up an ftp site for the binaries, for those people who don't want to bother with compiling the program. Wink wink, nudge nudge. (And many projects do this anyway.) The development of the "cover" program could go on in parallel, thus justifying continuous releases of the binaries, and the source is available (sort of) thus making the ruse that much more effective. Scott -- Scott Northrop <skyhawk(a)cpac.washington.edu> (206)784-2083 ObVirus: The demand for obedience is inherently evil. ObVirus2: As a juror in a Trial by Jury, you have the right, power and duty to acquit the defendant if you judge the law itself to be unjust.

2 1

Re: Origin lines in remailers
by wcs＠anchor.ho.att.com 23 Jun '93

23 Jun '93

There are several possible solutions to the origin-lines problem, but they offer different benefits and place different requirements on the users; unfortunately there's been no agreement on what the users should have to do, so there's no agreement on "best" solutions. 1) Chop off anything that even *looks* signature-like, whether the user intended it or not -- I consider this ugly, evil, and unreliable, and likely to chop stuff I want kept and leave stuff I'd like chopped, but there are users out there (e.g. variants on alt.highly.personal.stuff or alt.whistleblowing) who are assumed to be computer-naive and used to this kind of automagic anonymity, and maybe they need it, especially if they don't realize that some systems *do* add them since their local system doesn't. A "Dont-Mess-With-Trailers:" header line would help a bit. I don't know how much of M. ___ Blue Wave/QWK v2.12 -- M. Stirner - via RBBS-NET node 8:914/201 INTERNET: M..Stirner(a)f28.n125.z1.RBBS-NET.ORG was added by the author, how much by the Blue Wave and/or 8:914/201, or even for certain whether M. Stirner is the author or merely a machine owner; I'm guessing the author, and I'm guessing everything but the initial "M." was added automagically under the machine-owner's control. 2) Cut-Here: lines of various sorts, either following a pre-specified syntax or a MIME-like flexible syntax. I like this approach, since it gives the user a reasonable level of control and very seldom guesses wrong, but there are so many standards to choose from, and a proper implementation would have to leave in the line (or add an equivalent) at each hop to avoid accretion of path-traces, and make sure it gets the correct syntax for each following remailer. And the user *does* have to explicitly request it, which some people view as a problem, especially if they don't know the characteristics of the later mail-handlers in the chain. 3) Encryption-based systems, which only retain the encrypted portion; this means the user has to know more about the remailers being used, and there has to be a standard for expressing which remailers to forward to if more than one will be used (which it probably will be, for anybody security-aware enough to really want an encrypting remailer.) It *does* give you absolute control over how much gets through, but also makes most steganography more difficult. Solving the problem for message *headers* is tougher than solving it for trailers, since you need to know how much to retain of the beginning, and need to avoid trashing the information required to successfully deliver the mail with enough information that its intended recipient can decode and use it. Bill

1 0

Re: Digital Cash$$$$
by wcs＠anchor.ho.att.com 23 Jun '93

23 Jun '93

Do the money-laundering laws require reporting all transactions, or only movement of currency and gold? Digicash is most like EFT, which is transmitted encrypted today - does all of that have to be reported, or only the "real" paper money that backs up the numbers? As far as using digibanks on Native American territory, most of the rules restricting Federal control seem pretty flexible when the Feds want something, and even states can often get away with restricting gambling on reservations. Also, the Constitution gives CONgress the power to regulate commerce with foreign nations, Indian tribes, and between states, so they can still regulate any interactions between digibanks on Indian reservations and elsewhere. (Sigh - the Commerce Clause has been rabidly overused, but it's written in a way that lets them do nearly anything.) There's also the issue of tribal law, but most of the tribes are probably run by small numbers of reasonable people that you can talk to about things, and you can at least shop around to find them, unlike Federal bureaucracies which you're stuck with.

1 0

Re: Corporate Ethics and the Profit Margin
by wcs＠anchor.ho.att.com 23 Jun '93

23 Jun '93

gg(a)well.sf.ca.us writes: > Re Robert. Good one there, catching me saying "positive reinforcement for > PKP and negative reinforcement for AT&T." The thing is, I agree corporations > don't have feelings, but Jim Bidzos *does* have feelings and he is > singularly responsible as an individual, to a range of constituencies. [...] > That's not the case with AT&T which is a HUGE bureaucracy. If someone > would find the single individual in AT&T who got them involved with the > Clipper thing, we might have an interesting round of questions to ask. The > thing is though, once you're dealing with a specific person, the > relationship of adversariality has to be modified to take into account the > respect for the individual human being. A nice distinction, and possibly useful tactically. (Disclaimer: This represents about 10**-7 of AT&T's official position, i.e. I'm a stockholder like most employees, and nobody listens to me, at least not when I'm right :-) It's more than a single individual; it'd mainly be the managers of the group that makes their current line of secure phones for the government. Some of the phone models already have special government encryption chips; this is yet another design variant, and not a really major decision to make as long as there's enough tentatively-promised volume to expect a decent return on the investment. Motorola's in about the same situation. Back when the STU-III first came out, the government was talking about total sales of maybe half a million units to governments and contractors; I don't think sales were anywhere near that large... The interesting questions are whether there are any other strings attached, especially about whether that group will also attempt to market non-wiretapped phones to the public (I don't have any knowledge on that one), and also what the impact is on the parts of our "huge bureaucracy" which weren't in on the secret until we read about it in the New York Times or on the net but will be affected by it (much discussion is still going on, especially by people on standards committees which are getting pressured by the NIST and co-conspirators to specify SkipJack/escrow in industry standards.) The rest of the U.S. telecomm industry is in about the same situation. If you want to pressure AT&T or other large corporations, one popular approach is to buy stock and put a stockholder question on the ballot for the annual meeting; unfortunately the government's trying to railroad everybody into using Clipper fast enough that that's probably not practical here, but there are SEC rules on how to do it, and it does reach a lot of people and make a lot of noise if you can pull it off before it becomes moot, even if you lose (directors of large corporations almost always oppose stockholder resolutions - if do they support something, they can just do it and avoid the need for the voting process.) Having never done this myself, and don't know the costs or level of effort involved, but enough wackos put enough things on stockholder ballots that sane people like us can probably do it as well. It's important to make any ballot questions SHORT, clear to the uninitiated, positive, non-adversarial, and actionable, which ain't easy for complex topics like crypto. Bill

1 0

Re: Digital Cash$$$$
by bear＠eagle.fsl.noaa.gov 23 Jun '93

23 Jun '93

Phil Karn writes: > >Recall that the US has money-laundering laws that require you to file a >form every time you move $10,000 or more in or out of the country. If the >First Digital Bank of Cyberspace is offshore, it could come under these >laws, at least with respect to priming your account with real money. > >It's an interesting question whether they could then get you for sending >more than $10,000 of digital cash across the border without filing the >form. It's even more interesting if you encrypt all these cross-border >transactions... This could tie a lawyer up in fits, because even if you sent digital cash across the border, you could still produce a _spendable_ copy in the originating country! In fact, you could have the same 'bill' residing on media in a dozen countries! You couldn't legally spend more than one copy of the digital cash, of course, but digital cash (unlike hard cash) can be located in several places -- and probably would be if you're talking about a substantial amount of money. >Another wonderful set of laws we can credit to the "war on drugs". Many countries restrict or monitor the flow of currency across their border; this isn't simply a result of the WoD. However, the WoD was the main reason publicly acknowledged. Bear Giles

2 1

Origin lines in remailers
by M..Stirner＠f28.n125.z1.RBBS-NET.ORG 23 Jun '93

23 Jun '93

In response to to call for more remailer traffic, I have been attempting to disseminate the instructions for remailer use among users not members of this list. One of the problems that has arisen is the retention of the origin lines placed at the bottom of the outgoing message by various gates & net whatnot (see bottom of this message for an example). Just before I lost access to this list a few months ago, I know that there was a discussion on how this problem could be solved with both the Cypherpunks & Penet remailers, but a conclusion had not been reached by the time I left. I did not notice a reference to this problem/solution in either the Penet or Cypherpunks remailer helpfiles (which seem to be both unchanged from earlier this year). If this problem has been solved, would some kind soul post the fix here for us? Thanks. M. ___ Blue Wave/QWK v2.12 -- M. Stirner - via RBBS-NET node 8:914/201 INTERNET: M..Stirner(a)f28.n125.z1.RBBS-NET.ORG

2 1

REMAIL: public keys
by Karl Barrus 23 Jun '93

23 Jun '93

A while ago Dave Sun suggested keeping a file containing the public keys of the remailers in an easy to get format. (I'm embarrased how long it has taken me to do this!) I recently upload the keys I have, signed by myself and occasionally others. I recently uploaded a tar-gzip file with the public keys I have, and an MSDOS zip file of the same info will follow shortly. I'd like to (at least) get the remailer operators to sign their keys. I must apologize in advance because once I went through my key ring and removed all the "unknown signator" signatures, and thus have probably erased the signatures that some put on in the first place. If this is the case, please send me the remailer keys, your public key, and I'll add them both to my ring so I won't have those errors in the future! /-----------------------------------\ | Karl L. Barrus | | elee9sf(a)menudo.uh.edu | <- preferred address | barrus(a)tree.egr.uh.edu (NeXTMail) | \-----------------------------------/

1 0