March 1993 - cypherpunks-legacy

Re: Piercing anonymitiy and censorship
by pmetzger＠shearson.com 02 Mar '93

02 Mar '93

> From: Theodore Ts'o <tytso(a)athena.mit.edu> > > Date: Tue, 2 Mar 93 14:15:15 EST > From: pmetzger(a)shearson.com (Perry E. Metzger) > > Of course there are ways -- and they need not be so drastic. You could, > for instance, simply prevent non-subscribers from posting to your list, > and use public key to verify identities. This would allow you to swiftly > stop abuse. I've already noted this twice. You've claimed this is impractical, > but the tools to do this, AND WITHOUT PATENT PROBLEMS, already exist and > would be cheap to implement. > > If they are so cheap to implement them, could someone please implement > them FOR THE USENET GROUPS? (Where you don't have a concept of > subscribers or non-subscribers?) I don't have time Ted, I have really busy schedule. But, this is the thumbnail of what you want. 1. Build a decent tool to handle the public key sigs on news format message files and tell you if the file sender corresponds with the signature -- a variant on RIPEM (more like a half hour hack) should be able to do this. 2. Change the shell scripts handling incoming control messages inside the news software to check signatures against a trusted list. 3. Set some scripts handling incoming moderated newsgroups that check the signature against a trusted list. 4. Build a tool that checks that incoming signed messages correspond with signatures stored in the signature database for the site, and somehow flag non-authenticated or otherwise bogus signed messages. Add a header line to give out this info so rn and other newsreaders can nuke non-authenticated messages or what have you. Sounds like this begins to give you a large fraction of what you want without changing too much, and I bet its a few days of hacking. Its primitive, but it seems like the right thing for a start and you can take it from there. I specify keeping signatures on your news server and checking them there to keep users from needing special new newsreaders and to keep them from needing to run the signature code over and over again; presumably they can trust their sysadmin and if they cant they can get new tools so they don't have to. > I here lots of *talk* of how easy it is to do this, or how easy it is to > do that. If it's so easy, why doesn't someone prove it to the rest of > us by actually doing it. I hate to bring the Real World down upon you > guys, but talk is cheap; code sometimes isn't. As I've said, I don't have time myself, but the above is really easy for someone with a good knowledge of C News, RIPEM and the like. The hardest part is handling a key database and doing key management since RIPEM has no such provisions, but you can likely fix that. Then there is the issue of getting RSA to permit your hacks to RIPEM to get out, which I suspect they would. Okay, maybe not a few days, but certainly not much of a challenge here and you have the start of the system we were talking about. Among other things, it fixes forged control messages (presumably you would leave cancel messages alone, but it could let you authenticate newgroup and delgroups, which is a big problem), forged moderated messages, and give you the start of what you would need to start ignoring unsigned messages or messages from users you don't like on newsgroups. The stuff for non-moderated newsgroups would be primitive, but it would be a start and would let users have the option of deciding what they want to do with non-authenticated messages. Perry

2 1

Re: Future of anonymity (short-term vs. long-term)
by pmetzger＠shearson.com 02 Mar '93

02 Mar '93

> From: Theodore Ts'o <tytso(a)athena.mit.edu> > > Date: Tue, 2 Mar 93 10:51:31 EST > From: pmetzger(a)shearson.com (Perry E. Metzger) > > You aren't arguing for non-anonymity. You are arguing that free > speech is bad. > > No, I am not argueing for non-anonymity. Please stop defending your > position by putting misrepresentations in my mouth. > > Believe me, I understand why anonymity has its features. I am just > pointing out some of its bad sides, which you seem to refuse to accept > even exist. Of course I accept that they exist. However, I believe the benefits outweigh the problems, and in any case it matters little what we think since we cannot reasonably stop such systems from arising. > If the only way you can defend your position is by ranting and raving > and calling me a censorship-loving Nazi, then perhaps we should just end > this discussion right here. I don't believe I called you a Nazi. I also believe you took my quote out of context. Perry

1 0

anarchism (was: Re: Dining Crypto -- An Introduction) (fwd)
by kwaldman＠tanstaafl.extropy1.sai.com 02 Mar '93

02 Mar '93

> (Those of you who don't believe me, look at the railroad industry in > the end of the 19th century.) No free market here, government gave them the land for the railroad for free or very low cost. > That's only what I thought of off the top of my head. If the New York > Times or some publication of similar stature were to pick up the "best Or maybe NBC could pick the best ones :-) > Marc The basic trouble with government is, no matter what the quality of ideas they have, they tend to put a gun to your head. "For your best interest of course" Voluntarily yours, Karl Waldman

1 0

META: prefixes for easy filtering
by root＠rmsdell.ftl.fl.us 02 Mar '93

02 Mar '93

> is problem: break the current list into topic areas. A similar situation occurred a while ago on the Extropians list. Many people were complaining about excess volume, people were unsubscribing, and there was talk of splitting the list into many sublists. There are some problems with sublists. Many people would subscribe to all the lists, or many of them. List management chores ((un)subscriptions, bounces, address changes, etc) would increase. Many messages would get "cross-posted" to several or all lists, and thus would appear many times in everyone's mail box, thus even increasing the number of messages to sift through. There are other problems, which I will not mention now. I proposed a simple solution which is in use now, and has greatly increased the quality of the list, makes it easy for everyone to only read the messages they want, and does not require deployment of any new software. The actual volume has not decreased, probably it even increased. But the information flow is so much more manageable. The solution is the use of prefixes in Subject: lines. When you post, prefix your Subject: line with a short "tag" such as "ANON:", "DCNET:", "PGP:", "DCASH:", or others. For example, you would see subjects like PGP: new version available ANON: an new idea for anonymous replies etcetera. When reading your mail, just have your mailer sort the mail by Subject: line (if your mailer can't do that, get a new mailer), and all messages about PGP will come together, all messages about anonymous remailers will be in one area, etc. Then it's easy to delete them all without reading, to save them to a file for future reference, or to read them if that is a topic you are interested in. The beauty of this system is it's anarchistic nature. There is no need for people to maintain an official list of prefixes, or to vote on new ones (as is done with newsgroups), or to ask someone to create one (as would be necessary for mailing sublists). There's no need for the group as a whole to agree on anything. Just start using them. Try to find a logical prefix for each message that matches its subject area. Most likely people posting on the same topic will choose same or similar prefix. After some initial fluctuation, different prefixes for the same topic will converge to one that will become customary for that topic. New prefixes will pop up every once in a while, and the ones not used will fade from the group memory. This is a flexible, dynamic system. As a starting point I will make up a prefix for each of the sublists you proposed (if you don't like my prefix, use a different one!): ANON: anon/pseudo_cpunks Anoymity/Pseudonymity REMAIL: remailers_cpunks Remailer Technology DCNET: dining_cpunks DC Nets RANDOM: random-cpunks Random Generators DCASH: digimoney_cpunks Digital Banking PGP: pgp_cpunks PGP App/Current Info FLAME:-) ziplips_cpunks Crypto-Censorship WHISTLE: fweee_cpunks Whistleblowers (The "Keith Peterson Area"?) MEET: physmtgs_cpunks Physical Meetings/Conferences Here are some more: META: discussions on the list about the list itself, such as this post, or the post I am replying to which suggested splitting the list. Complaints about high volume, messages saying something does or does not belong on the list, etc, would use this prefix. ANNOUNCE: important messages that everyone may be interested in. FRIV: for jokes, parodies, other frivolous posts. If a post fits in more than one subject area, the main prefix should be put first, for sorting purposes. The other prefix(es) would follow, separated by slashes. For example "PGP/ANNOUNCE: new version available" or "RANDOM/FRIV: why not just flip coins?". This is in no way mandatory, it's just a convention that developed on Extropians, and it may be advantageous to use it, to ease further processing. Some other ideas: You can use procmail, elm filter, slocal, or any other mail processing tool to handle messages with different prefixes. For example if you are a very busy person, or are reading your mail over a low-speed link, you may want to save all REMAIL/ANNOUNCE messages in a "remailers" file, delete all FRIV, META, and FLAME messages, and for each other prefix, save the message to an appropriate folder for reading later. If you were not interested in discussion, but wanted to keep up on what's going on, you would have the filter delete all the messages from the mailin list that do not have an ANNOUNCE: prefix. Or, if you have enough time and/or are using a high-speed connection, you may just sort all the messages by Subject: thereby lumping all the messages on a subject together. Then you can decide which you are going to read first, which ones you want to delete, etc. If this idea takes off, and most people will start using prefixes, further evolution of the concept is possible. For example a group of extropians are developing some software on the list host machine that will let people customise their subscription, for example choosing not to receive messages with a certain prefix, not to receive messages that don't have a prefix, or choosing to receive only some selected prefixes, plus any new prefixes that come to use. All this is sometime in the future. Right now, let's start by just prefixing each subject line with an appropriate prefix. -- Yanek Martinson yanek(a)novavax.nova.edu

1 0

976-OVERDOSE
by deltorto＠aol.com 02 Mar '93

02 Mar '93

Fellow Cypherpunks, I know that some of you have lives, jobs and studies and you probably, like me, are ofttimes overwhelmed by the sheer voluime of mail on this list. I have a simple proposal to solve th is problem: break the current list into topic areas. These would include: anon/pseudo_cpunks Anoymity/Pseudonymity remailers_cpunks Remailer Technology dining_cpunks DC Nets random-cpunks Random Generators digimoney_cpunks Digital Banking pgp_cpunks PGP App/Current Info <- new vers info/var. plat's ziplips_cpunks Crypto-Censorship fweee_cpunks Whistleblowers (The "Keith Peterson Area"?) physmtgs_cpunks Physical Meetings/Conferences <- CFP, events... and several more that I've forgotten, I'm sure... We should clearly state the general thread of each topic. People could subscribe to as many as they want to and thus dramatically reduce the amount of mail they get on topics about which they have little or no interest. I'm learning a lot from the list, but the sheer volume of the postings is becoming pretty unmanageable. We seem to have a range of subspecies developing, so it make sense to cater to them seperately. I hope we can remedy this situation before many more people have to unsubscribe. Most newcomers from Mondo articles, etc. should probably be subscribed to the <announce> list first, then maybe we could periodically post synopses of what's available on the other topics and let them wander in more deliberately. I hope everyone appreciates that my approach is geared toward bringing in more quality participation and not a flurry of curiousity-cats who dash in and out and post UNSUBSCRIBE mail to the whole list (thus gumming things up even further). What do you Punks think? I hope to see a comment or two about this from people, I think it's an issue whose time has come. "An ounce of prevention os worth a pound of cure" as they say. dave "verbum sat spaienti est" del torto

2 1

Re: more ideas on anonymity
by Tiia Roth-Biester 02 Mar '93

02 Mar '93

>However, is it illegal to use false ID in order to conduct perfectly legal >transactions in order to preserve privacy/anonymity? How about it, any of >you guys associated with the CPSR, EFF, or ACLU, can you answer this one? >Murdering Thug Lexus research elided... >(Matthew J Miszewski) At Common Law, you could call youself anything you wanted as long as there was no intent to defraud. Generally you can still do this today. Matthew-In the case you dug up what sort of identity documents were used? Obviously, forging government ID documents is a separate crime. If you are signing something "under penlty of perjury" or "with a warranty of truthfullness" the person you are dealing with may be able to throw the agreement (whatever it is) out. There is also the possibility of legal action. You can cross the language out before signing (we are always free to negotiate) and hope that the bored clerk you are dealing with doesn't notice or if you are using forms that can be obtained in advance in blank you can remove the offending language and replace it with nondescript language using DTP technology. Avoid using government ID and substitute "soft ID" such as employment ID or school ID. Since anyone in America is free to form a "company" or a school ID can also be issued. Obtain a secured VISA card or a VISA debit card in a nome de guerre. This is pretty good ID. If the financial institution is overseas, you may not have to provide proof of identity. In this country (or Canada) bank accounts -- including secured credit card accounts -- can still be obtained in a nome de guerre if you work at it. If you aren't engaging in other illegal activity, prosecutions for using an alternate identity are rare. Duncan Frissell

1 0

Poor Man's Time Release Crypto
by Eric Hughes 02 Mar '93

02 Mar '93

An obvious but very important point about any time release protocol can be observed in the following one: 1. Publish some non-random encrypted data. 2. Wait. Computational increases will eventually make cracking the code feasible. Your secret will be revealed, but you just don't know when! Technological progress puts an upper bound on the amount of time a secret can remain secret. Likewise, Diffie-Hellman is forward secure, but only until taking discrete logs in the chosen ring is feasible. Eric

1 0

PGP distribution
by Giuseppe Cimmino 02 Mar '93

02 Mar '93

OK, a short note. I'm willing to round up some old 3 1/2" 720K floppies and time on a disk duplicator to facilitate PGP distribution at Interop here in DC next week. To be specific: If someone wants to organize the distribution, I'll help in the production. -Giuseppe

1 0

Re: A novel (?) return address idea
by wcs＠anchor.ho.att.com 02 Mar '93

02 Mar '93

John Gilmore writes: > There seems to me to be a serious problem with the "novel return > address" idea. The information that ties together multiple anonymous > messages from the same person is out in the world, encrypted by a > single key in a conventional cipher. I'm not sure there IS a good answer for anonymous news-posting with replies. For email, you can create a use-once-then-delete anonymous reply address, which hangs around until a reply happens or garbage-collection hits, but this isn't practical for news or multiple-recipient email - you need to keep an alias around for multiple replies to use. You can assign a new reply address for each posting, which is in some sense more secure, but it means that there are now many copies of the poster's email address and public-key (though multiple public keys may be a win.) But if the remailer site gets compromised, these are about as risky as multiple messages cryptically pointing to one copy of the address. (Unless the mapping from anon-reply-id to real-id is cryptographically protected.) (These comments also apply to the dossier problem below.) If the key-compromise issues you bring up below can be fixed, then this method is more secure than the one-anon-address-per-user for all postings method that seems to currently be in use, and if users can get a new return-address-id on request, and delete old return-address-ids on request (features you really need anyway), it's basically equivalent. > Furthermore, breaking the key will be possible by sending test-probes > and doing exhaustive search. E.g. if you add 128 bits of salt, > someone can send five or ten messages to themself through the > remailer, and accumulate ten encrypted addresses that are known to be > for the same sender. When decrypted, these keys will have maybe a 16- > or 32-bit "return address ID" and 128 bits of salt. The attacker can > then search the key space for keys that include large numbers of > identical bits when decrypting those ten keys. This search is easily Hmm. So it's not good enough to just lump 32 bits of address-id and 32 bits of salt together, because a key-search over 56-bit keys will trigger on the ones that get the same first 32 bits for multiple cyphertexts. What if you use triple-DES instead of single-DES as the cypher, which increases the key search space to at least 112 bits? This is presumably big enough, especially since the return-address-id doesn't directly give you the address, though that can be easier to crack. > The idea also suffers from the dossier problem -- all the information > about return addresses will exist in a single place (at the remailer > site) where it's tempting for a government (or other adversary of > privacy) to try for it. Deleting old addresses and getting new ones helps. Joe's suggestion of changing the keys also helps: including a few bits in the crypted address that are essentially another salt to let you pick the crypt key, but of course this means you need to keep ALL the older keys loaded in the system (or at least the last N), either stored (bad) or typed in (also bad.) I suppose you'd at least store them crypted. If you periodically dispose of the oldest ones, then you've limited the amount of time the correspondence is exposed, which is a good thing, but you've also made it impossible to reply to really old messages. (I guess a certain fraction of the postings will be requests for the poster of <message-ID> to repost something?) Also, this kind of remailer/reposter may still be chained - there's no need for the return address to be a _real_ return address. Bill Stewart

1 0

tapping
by Timothy Newsham 02 Mar '93

02 Mar '93

[forwarded from elsewhere] > > [From Data Communications, January 1993] > > INVENTION CUTS CABLING TIES > > An inventor working from a garden shed in the U.K. has come up with a device > that enables PCs and other LAN equipment to send and receive data through > the plastic outer jacket of copper LAN cabling-- without piercing the > cabling. Called the Watsonlinc Cable Coupling Transformer, the device > allows users to attach LAN equipment at any point in a network without going > through time-consuming and costly cable attachment procedures. The > Watsonlinc, which must be placed directly next to a cable's outer jacket, > uses a proprietary technique to reduce noise interference while picking up > and transmitting data signals. Watsonlinc-equipped network interface cards > (NICs) will appear in the next 12 months, according to inventor Mike Watson > (Walton-on-Thames, U.K.), who says the device's production cost of about $5 > per unit will not significantly increase NIC sticker prices. The Watsonlinc > works with both shielded and unshielded twisted-pair copper cabling, is > small enough to fit on laptop PC internal adapters, and is capable of > handling all common LAN speeds, Watson says. The internationally patented > invention works just as well with voice signals. Predictably, it already > has been licensed for use in telephone surveillance equipment. > >

4 3