December 2003 - cypherpunks-legacy

Re: FORTRESS REMAILERS
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

To my mind, remailer vulnerability starts with the Net addresses used to send to them and send from them. It seems to me that a fortress remailer must have solve two problems: 1) Getting a message to the remailer without knowing the remailer's Net address. 2) Sending a message from the remailer without revealing a Net address. Problem 1 can be easily solved by having users send messages to various new groups the remailer scans. The messages would be encrypted with the remailer's public key. The remailer continuously scans for new messages encrypted with its public key. When it finds one, it decrypts it and processes it. Problem 2 it the tricky part. How can the remailer inject a message back into the public Net without revealing its Net-location? If the remailer could sovle this problem, then why couldn't everybody use the same solution, eliminating the need for remailers? The one possibility is that the solusion requires something that most average users can't do or can't acquire economically (i.e. most everybody can grow their own food, but why bother). I haven't come up with any really good ideas here. Here are a couple thoughts: a) Using various hacker tricks to forge "From:" e-mail addresses. b) Use short-lived addresses. Set the remailer up some how so it can frequently acquire new e-mail addresses. Each address would only be used to forward a limited number of messages, and then it would be abandoned. Jim_Miller(a)suite.com

1 0

Little Brother will watch you!
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Of some interest to the list. Rishab ------------------- Electric Dreams Weekly column for The Asian Age by Rishab Aiyer Ghosh #30, 26/September/1994: Lamplighters in cyberspace After diving into cyberspace for a while, people are often relieved to temporarily return to brickspace - which is what I call the 'real world'. On the other hand, it would be nice if the knowbots and electronic agents that will one day cater to all your information needs could do the same for your lights and thermostat. Maybe they could learn your personal lighting preferences for different hours of the day, and adapt to your activities and moods. Technology is a decorated excuse for laziness. When you have the information superhighway at your doorstep, why not invite it inside? Let software reach beyond the World Wide Web into the World Wide Lamplighter, let programs change more than your accounts or your photographs, and you've opened up a whole new area of information technology - appliance control. Gadgets have been controlled by computers long before the infobahn was even dreamt of. Large, cumbersome gadgets that manufacture jet engines or process iron to steel. But your bedside lamp still waits for you to turn it off. Appliance control devices basically help you turn your bedside lamp off for you - they control the resistance in a light dimmer, or the current to a motor that opens a door, or the thermostat of an air conditioner. Appliance control devices are themselves controlled by software. The software could come from anywhere - even an electronic network. Cyberspace meets refrigerators. Appliance controllers could be attached to everything. One for each lamp, power point, door, window shade and chair leg. All the controllers will be networked, so that they can talk to each other, to the set-top box on an interactive TV or to a notebook computer at the other end of the world. To intelligent agents, the digital butlers trained to learn your preferences as you work in the realm of information, talking to an appliance controller would be as natural as searching for a book in an electronic library. Feedback sensors associated with appliances could inform the agents how you like your pizza, or when to darken the room as you fall asleep, reading. They would also switch things of as you leave the room, saving you the trouble as well as the pangs of guilt. Of course it would be like living not with Big Brother, but dozens of little Lilliputian ones, watching, listening and working for you. To realize this dream, in 1988, Apple Computer co-founder Mike Markkula started Echelon, a company to promote and manufacture networked appliance controllers. Echelon's controller, the Neuron chip, is a little device that talks to the universe through radio. Echelon hopes that its product will become the standard and start appearing just everywhere, but for the moment the major market is industrial. Manufacturers long used to computers controlling devices that build cars and trains are beginning to place appliance controllers within them. A Motorola study suggests that the average home in the year 2000 will have a little under 250 controller chips, but currently homes have only 50 or so, mainly in VCRs, microwave ovens and other hi-tech devices. So until twenty- first century consumers are ready for synchronized lights that turn on as you enter the room, and are willing to trust the complex software that will drive large controller networks, cyberspace pioneers will just have to dream on. Blurring the boundaries between cyberspace and brickspace, between information and reality, appliance control devices and networks can greatly increase the efficiency of living. They can save energy, improve security, and make you feel quite pampered in a comfortable home. Unless, that is, your sulking apartment refuses to let you in. Rishab Aiyer Ghosh is a freelance technology consultant and writer. You can reach him through voice mail (+91 11 3760335) or e-mail (rishab(a)dxm.ernet.in) --====(C) Copyright 1994 Rishab Aiyer Ghosh. All rights reserved====-- This article may be redistributed in electronic form only, provided that the article and this notice remain intact. This article may not under any circumstances be redistributed in any non-electronic form, or redistributed in any form for compensation of any kind, without prior written permission from Rishab Aiyer Ghosh (rishab(a)dxm.ernet.in) --==================================================================--

1 0

Re: SUFFERANCE remailers
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 8:11 PM 9/27/94, Gary Jeffers wrote: > Anybody got any idea at all how to build a Fortress remailer? As I see it, the main things one must defend a single machine acting as a remailer against are physical accesibility, denial of service and violation through monitoring mail flow. The physical accesibility problem is tricky, but obviously has been done for other physical items.. Stick it somewhere secret. Of course you can't know how secret it is until someone tries to find it. Wireless communication, as others pointed out, are pretty nessessary for this. The other two problems are software, and have been discussed quite a bit here. The answers above aren't bery compelling, and I don't see much way around this. Groups with large amounts resources are typically good at finding things when they put thier minds to it. The solution here, and I think this has been talked about here, too, is to create redundant destributed remailers. Issues here are trust, protocol and availability. Trust could be developed through the web of trust method, encouraged by existing remailers using this protocol, but the key issue is being able to trust a message going over potentially insecure remailer nodes can be considered valid if delivered. That way if Julf ends up being a under-deep-cover NSA agent and this hypothetical remailer-web is infested with bad-guys, there is still nothing they can do except render a message undeliverable. I'm trying to come up with something good here, but am still working on it. The vision I have for remailers in a perfect world is that everyone runs one and bounces around message 'packets' (small parts of the message (all signed and encrypted multiple times, of course) according to specific instructions. In a less than perfect world, a smaller network running this method could be created. This takes the form of the originator dumping the message into the stream, and forwards them off to some other sites. The message would be split into small packets which are encrypted multiple times to multiple different sites into the stream. This would probably have to be done by software, as it would be a complex task to manually split, encrypt etc. any but the smallest message. The software would need to be kept up to date about all potential public keys to encrypt to, and need to pick a set at random from this info. It would also insert routing intstructions as needed. The next site checks to see if it can decrypt the packet it recieves. If it can, it does so and sends it forwards it somewhere else, and repeat. If not, it just sends it onward. This continues for n layers of encryption for each packet, with the final message in the form of x packets encrypted only once ending up at the proper destination, which reassembles the message. All remailers reorder packets and insert noise as apporpriate. Obvious problems are bandwidth, time delay and having a site the message was signed to go down. The last issue can be taken care of by having group keys for this purpose, so that a given layer of encryption can be decrypted by any one of n sites with key m. This adds the problem of someone collecting all the keys and being able to crack the whole thing, but I think this is surmoutable. Band width and time delay stem from the same problem, and obviously this system would never work on the internet as it stands. If this web were, say, 300 sites worldwide, then they could work conjunction with the pre- existing remailers now available. Also, if the network grew to the point where it was impracticle to bounce at random, intermediate steps could be added, such as 'send me to austalia' or 'send me to mafiaNet', which would then cut down the number of bounces before a layer of decription was achived. As far as availability, well, it doesn't exist. Comments? Is this dumb? Did I just duplicate someone elses idea?

1 0

Re: TIS, SKE, & CyberCash Inc.
by Carl Ellison 17 Dec '03

17 Dec '03

>From: wfgodot(a)iquest.com (Michael Pierson) >Date: Tue, 27 Sep 1994 19:05:54 -0600 > (E) shall preserve the functional ability of the government > to interpret, in a timely manner, electronic information > that has been obtained pursuant to an electronic surveillance > permitted by law; This really bothers me. If the government today has a functional ability to interpret in a timely fashion information it has obtained, that is purely an accident (that the communicating parties chose not to encrypt) and the pure accident is likely to remain (because they will continue so to choose). However, the government has been trying to establish an enforceable right to succeed at gathering intelligence by surveillance and it has never been granted that right and should never be. Giving it a right to tap deals with gov't actions (permitting tapping). Giving it a right to understand what it taps deals with citizen actions (prohibiting encryption). Citizens have always had a right to try to keep a secret from the gov't and on this one point, we should not yield one micron. There should be *no* move at all toward establishing a right of the gov't to understand what it taps. Sorry -- I realize I'm preaching to the choir -- but this is *the key issue* to me and I wanted to push it. - Carl

1 0

Apple patents OTP reuse!
by nobody＠leri.edu 17 Dec '03

17 Dec '03

Like a lot of people, I often get angry when I read US patents. At best, I'll get confused or bored. Tonight, probably for the first time ever, I found comic relief in the otherwise sterile pages of a patent. Check out US Patent 5,345,508, "Method and Apparatus for Variable-Overhead Cached Encryption", by Lynn, Zweig and Mincher, assigned to Apple Computer, issued September 6, 1994. These guys have patented the notion of reusing one-time pads. That's right, reusing one-time pads! To "cut the computational overhead", they say, they generate a PN sequence once and then reuse it by XOR with successive packets until a "use limit" is reached. Quoting: "When the maximum count value specifies that the PN sequence is to be used only once, the security afforded by the present invention will be high, but a new PN sequence must be generated for each message sequence transmitted and so the computational overhead will also be high. If the maximum count value specifies a maximum count value [sic] greater than one, the PN sequence stored in the cache will be reused to encrypt the maximum count number of message sequences. The resulting ciphertext messages will be more vulnerable to statistical cryptoanalytic attack as the maximum count value increases..." No shit! Talk about missing out on some absolutely fundamental concepts... There may actually be a silver lining to this utterly silly patent. Although I've only looked it over briefly, it seems to unintentionally cover the TIA's so-called voice "privacy" technique for TDMA digital cellular -- i.e., generating a pseudorandom sequence at the beginning of a call and then reusing it for every frame. Maybe Apple could be persuaded to agressively sue everybody so cellular will switch to *real* encryption... :-)

1 0

Re: Anyone seen the 'quantum cryptanalysis' thread on sci.crypt?
by doug＠OpenMind.com 17 Dec '03

17 Dec '03

Tim May: >In any case, the Shor work on a quantum factorer is interesting, but >is at least several decades away, in my opinion. And even then it is >likely to be "workable" out to some number of digits (roughly, number >of digits = precision needed), by which time the conventional advances >in computer power will mean we're all using 10,000-bit moduli >(especially if we have just heard that NSA has just spend $32 billion to >build a Shor machine able to factor 3000-bit moduli :-} ). I won't argue whether Shor's work will be implemented or not within any given time period, but I thought that one of the most important properties of it is that once (and if) achieved, the resources required to factor increasingly large moduli lengths go up only polynomially, not exponentially. Doug Cutrell

2 1

Datacom watchdog set up in INDIA
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Datacom watchdog set up in India -------------------------------- The Forum for Rights to Electronic Expression (FREE) has been formed in India as a body dedicated to extending fundamental rights to the electronic domain. FREE owes its creation to an attack on Indian datacom by the Indian government, in the form of exorbitant licence fees (a minimum Rs. 1.5 million = US$50,000 each year for a BBS, much higher for e-mail). The Indian government also dug up the 1885 Indian Telegraph Act, a legacy of our British colonial masters, and used it to reserve for itself the right to uplink to a satellite, as well as to require the provider of any telecom value-added service to ensure that no objectionable or obscene messages are carried on the network. Value added services covered under these guidelines include e-mail, voice mail, BBSes, video conferencing, etc. Any specially authorised officer of the government, "if satisfied that it is necessary or expedient to do so" in the interests of security of the State, friendly relations with foreign states, or for preventing incitement to the commission of an offence, may also tap into the system. As yet, FREE does not have any office bearers or staff. All discussions are carried out by the entire membership on the FidoNet echo FREE. Posting to the echo makes you a member of FREE, unless you specifically ask not to be made one. Decisions on what may be published as a FREE document are taken by consensus. The first document that FREE published was a letter to the Indian government making suggestions relating to telecom policy. All published FREE documents and related material are available by Gopher to mahavir.doe.ernet.in and will soon be available at the EFF Gopher/Web/FTP site: gopher://gopher.eff.org/1/Groups/FREE http://www.eff.org/pub/Groups/FREE/ ftp://ftp.eff.org/pub/Groups/FREE/ To get the FREE echo on FidoNet or for any other correspondence with FREE, send mail to free(a)arbornet.org. ----------------------------------------------------------------------------- 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

new rules: filing electronic tax returns
by LAURENN%smtpgate＠earth.wri.org 17 Dec '03

17 Dec '03

Hi there -- I haven't seen this mentioned, or maybe I missed it, but doesn't the following message scare you? ... no tax-return filing electronically without fingerprints on file? ... how are CPA's and lawyers somehow exempt??? doubleplusungood. -- LaurenN(a)wri.org ------------------------------------------------- Subject: Edupage 9/22/94 NEW RULES FOR FILING ELECTRONICALLY With the number of fraudulent claims for tax refunds increasing, the IRS is tightening up on who can file returns electronically. New applicants must be 21 years old, must be U.S. citizens or have permanent resident alien status, must authorize a credit check and agree to be fingerprinted. Lawyers, CPAs and enrolled agents need only show proof of their professional status. (Wall Street Journal 9/21/94 A1)

1 0

Re: Fortress Remailers
by macorp!moonlight!ken＠uu4.psi.com 17 Dec '03

17 Dec '03

Could one set up a virtual remailer that floated around a set of news groups? The active remailer would pass an encrypted token to a randomly chosen member of the set which would become the remailer for the next interval. A compromized member of the set might then eat the token, rendering th remailer inoperative, but maybe that could be overcome. Although I don't have much more than a layman's grasp of cryptography my basic thought is to consider the set of potential mailers the way one would consider some known element in a cryptographic scheme, such as a randomly accessed lookup table, so that if a cracker couldn't determine the next element in the table, she couldn't determine where the remailer would be next, either.

1 0

Re: 3DES
by GRABOW_GEOFFREY＠tandem.com 17 Dec '03

17 Dec '03

>Quick question. There's a brief mention in Applied Cryptography that >triple DES uses: > > Eabc(x) = Ea(Db(Ec(x))) > >as opposed to: > > Eabc(x) = Ea(Eb(Ec(x))) > >in order to preserve some symmetry properties. Can anyone give a >better explanation? I thought it goes like this: Eab(x) = Ea(Db(Ea(x))) Anyone? G.C.G. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Geoffrey C. Grabow | "What we demand are rigidly defined | | Oyster Bay, New York | areas of doubt and uncertainty!" | | | -------------------- | | grabow_geoffrey(a)tandem.com | Clipper, SkipJack & Digital Telephony | | | JUST SAY NO!!! | |----------------------------------------------------------------------| |PGP 2.6 fingerprint = AA 9E 35 12 F8 93 72 8D 1C E5 D5 BC 74 BE 49 D3| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0