December 2003 - cypherpunks-legacy

Re: Selection key crypto protocol trial balloon
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

wcs(a)anchor.ho.att.com writes: > > Um no. The main thing is that what is extracted with the selection key is > > _different_ from what was put in... > > But the only things the selectioon key can extract are what the senders > put in plus what the system did to it once it was there, which is not > informationally different than what the senders put there. True, just as ciphertext is not different, informationally, from plaintext. It's just a pair of transformations, both by the system, one in response to the sender and the other in response to the receiver. A bit like an airlock - if the two transformations are the right ones, extraneous information such as the identity should not pass through. > I suppose you could play some games by sending the message in > multiple parts, with parts sent by 1-way anonymous remailer, > but there's still a certain amount of traffic analysis you can do. > > Bill ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "In between the breaths is rishab(a)dxm.ernet.in the space where we live" rishab(a)arbornet.org - Lawrence Durrell Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

Re: Selection key crypto protocol trial balloon
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Hal <hfinney(a)shell.portal.com>: > Let me get straight where we are. Rishab's concrete proposal was not an > implementation, but rather a set of requirements. There was no > suggestion about any specific algorithms that would meet those > requirements, right? The question is whether any such algorithm could > exist. Right. > It is hard for me to see how this could possibly work. The message > receiver sends this "selection key" to the intermediary, and that somehow > pulls out the saved message, but in a form such that the intermediary > doesn't recognize it. And the intermediary himself can't tell exactly > which message is produced. But it is nevertheless exactly the message > which was meant for this particular receiver. It need not be the same information - i.e. if the encryption process adds enough noise to the message, the extraction process might by lossy, without any total loss for the receiver. This may be possible particularly if Fourier-style transforms are used, as the "selection key" could pick up less "frequencies" of a message than are stored at the intermediary. > The thing is, the receiver does not have much more information than the > intermediary. The same could be said of a private/public key pair. What is crucial is the association between the keys. This said, while I can imagine separate systems for the intermediary loosing correlation between incoming and outgoing messages (eg - it's _really_ tough, without fancy pattern recognition, to associate a JPEG with the original), and for generating three associated keys (secret splitting? something to do with Brands' blind signatures?), I really can't imagine a way of putting it all together. Someone will have to be inspired, as Diffie was... ----------------------------------------------------------------------------- For Electric Dreams subscriptions and back issues, send a mail to rishab(a)arbornet.org with 'get help' as the message Subject. Rishab Aiyer Ghosh rishab(a)dxm.ernet.in rishab(a)arbornet.org Vox +91 11 6853410 Voxmail 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

stupid legislation in Oregon
by Greg Broiles 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Ugh. This has been a stupid week. Oregon House bill 2319 was introduced by Rep. (Kevin?) Mannix on 1/16/95, and referred to the House committee on Commerce on 1/18/95. Rep. Mannix has also introduced another bill, HB 2310, which "Creates the crime of electronically furnishing obscene material to minors; punishes by maximum one year imprisonment, $10,000 fine, or both." HB 2310 was introduced 1/13/95, and referred to the House Judiciary committee on 1/16/95. He's introduced 38 bills so far this session - including others re mandatory minimum sentencing for felony convictions, one which appears to bar surrogate-pregnancy agreements, and another (HB2303) which prohibits physicians from performing artificial insemination on an unmarried woman. Damn this fucking state. I'll be on the phone with my representative in the morning to see if I can find out more. Westlaw's legislative tracking database doesn't have much information. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzsecH3YhjZY3fMNAQH9DwP9GA1oai9JA2ftMSCLKH+jnfqxD/svI0ZD N1yWpHwStmoZ3x6fr9MRpqFIwAfsTzfj+P0B07HBy1V53pVhKw+bFyCZZ+/ZmA7u lAXR/eR6xr53ZMZJt2SSsFElE8VB8syjJRWe48a37q+3Ma9iGhvlfLx5IuX+qZR7 E9de+WMg/Pw= =rOtS -----END PGP SIGNATURE-----

1 0

Delphi and Encryption??
by Harry S. Hawk 17 Dec '03

17 Dec '03

RUPERT'S BIG PLANS Media mogul Rupert Murdoch has big plans for his Delphi Internet Services -- he wants to boost it from fifth to first place in online service providers. "Internet, Delphi and TV as it becomes interactive, all will become very much integrated," predicts HarperCollins' publishing VP. By choosing existing software modules, such as Mosaic, instead of developing its own graphical user interface, Murdoch hopes to leapfrog the competition and come out on top. Delphi's data encryption technology will also enhance its ^^^^^^^^^^^^^^^^^^^^^^^^ position among privacy-conscious consumers. (Upside Feb.'95 p.39) Anyone know anything?? /hawk

1 0

Indian Supreme Court ends state control of the airwaves
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

The Indian Supreme Court yesterday (9th February, 1995) directed the government to create an independent autonomous regulatory body for the airwaves (like the US FCC) and end the state monopoly on broadcasting and satellite uplinks. The judges took an interesting position that the "GREATER IMPACT" OF ELECTRONIC MEDIA and its "wider range of circulation of information" as opposed to the press, CANNOT BE USED TO RESTRICT or deny THE RIGHT TO FREE EXPRESSION. This may have important consequences, for all over the world, including in the US and India, the electronic media is denied freedoms allowed to the press with the excuse that it's somehow different. The three-judge bench, comprising of Justices PB Sawant, S Mohan and BP Jeevan Reddy, made the ruling after an government appeal against a previous ruling by the Calcutta High Court. The Calcutta High Court had earlier upheld the right to telecast as fundamental, which would theoretically prevent any regulation or censorship whatsoever. The consensual Supreme Court judgement, while denying the government's power of monopoly, upheld its right to subject the electronic media to regulation and censorship. However, Justice Reddy, in his separate ruling did not mention censorship. He pointed out that the century-old Indian Telegraph Act of 1885, which has been ingeniously extrapolated to support the government's monopoly over electronic media and right to 'licence' data networks, was "wholly inadequate and unsuited for" electronic media, and said that Parliament should enact new laws to govern such media. Unfortunately the Supreme Court has no powers to legislate, and new laws have a habit (as seen with the Digital Telephony Bill in the US) of increasing, rather than decreasing, government authority. The explicit statement that the electronic media should not be more restricted than the press will, hopefully, prevent that. The legal battle started with the Doordarshan, the state TV monopoly, objecting to the Cricket Association of Bengal's contract with Trans World International granting the latter worldwide broadcasting rights to a cricket tournament. Doordarshan used the 1885 Act to prevent TWI from uplinking to satellite, till the courts intervened. ----------------------------------------------------------------------------- For Electric Dreams subscriptions and back issues, send a mail to rishab(a)arbornet.org with 'get help' as the message Subject. Rishab Aiyer Ghosh rishab(a)dxm.ernet.in rishab(a)arbornet.org Vox +91 11 6853410 Voxmail 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

GSM and cellular crypto
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Richard Parrett (?) wrote: > GSM uses less than strong encryption, by the way. I forget the > technical details, but it is of the level that governments can > fairly readily crack, but beyond the reach of most private > organisations. (So no more 'Squidgy-gate'). It would, however, > be quite feasible to add additional second stage encryption > to phones (since the dataflow is digital point-point). I wonder > if Nokia, a Finnish company well outside the scope of COCOM, > might offer a feature like this. All operaters of cellular networks in India are to use GSM, and Nokia has been running an enormous ad campaign, it is very likely to be the market leader in instruments. I don't know about any encryption provided, though. ----------------------------------------------------------------------------- For Electric Dreams subscriptions and back issues, send a mail to rishab(a)arbornet.org with 'get help' as the message Subject. Rishab Aiyer Ghosh rishab(a)dxm.ernet.in rishab(a)arbornet.org Vox +91 11 6853410 Voxmail 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

a draft petition against S.314
by slowdog 17 Dec '03

17 Dec '03

[A draft petition, comment, but do it QUICKLY.] In united voice, we sign this petition against passage of S.314 ("The Communications Decency Act of 1995") for these reasons: S.314 would prohibit not only individual speech that is "obscene, lewd, lascivious, filthy, or indecent", but would prohibit any provider of telecommunications service from carrying such traffic, under threat of stiff penalty. Even aside from the implications for free speech, this would cause an undue - and quite possibly unjust - burden upon operators of various telecommunications services. In a time where the citizenry and their lawmakers alike are calling for and passing "no unfunded mandates" laws, it is unfortunate that Congress might seek to impose unfunded mandates upon businesses that provide the framework for the information age. The threat of such penalty alone might result in a chilling effect in the telecommunications service community, again creating an environment contrary to the principles of free speech, press, and assembly - principles which entities such as the internet embody as nothing has before. We ask that the Senate halt any further progress of this bill. We ask that the Senate be an example to Congress as a whole, and to the nation at large - to promote the general welfare as stated in the Preamble to the Constitution by protecting the free flow of information and ideas across all of our telecommunications services. - dog

1 0

HR830 - Anyone tracking this?
by mgh5868＠ultb.isc.rit.edu 17 Dec '03

17 Dec '03

The recent version of the EFFector Online had some information about the House of Representative's Bill HR830. They say that this bill is being rammed through Congress and would cripple FOIA. It would seemingly change any public information that is given value to non-public information. Does anyone have any further information? Mike

1 0

Re: MIME based remailing commands
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- <SNIP my comments> >Ah, I see how you are doing it. Having re-read your docs, I gather >that when un-armored the file is in an encrypted binary format, and >when decrypted at least the non-header portion of the file is still >binary? I think this is a good way to do it; it addresses the point >Eric made recently about size expansion when an armored file is >encrypted at each step. > That is about right. Inside the armor is a bunch of binary data. 20 header blocks, and the message block. The first message block is a PGP encrypted to the remailer, and contains the next destination. The other 19 headers, and the message block are IDEA encrypted with a key and IV in the first header. When decrypted, the second header is seen to be PGP encrypted to the next remailer, and the rest is encrypted with the key in that header. The remailer Shifts up all the headers, sticks junk in the 20th header, and rearmors the whole thing. This is rather more active manipulation than the current remailers. >The one thing I would mention is that "::" was not originally intended >as an indication that the message was to be remailed. Rather, this was >simply a "header pasting token" which could be used to move a few lines >from the body up into the header for those people who can't set header >fields on outgoing mail. Then the presence of "Anon-To:" or whatever >in the header is what actually causes the action. So you don't need to >use "::", you can just set your headers directly and get the same >effect. (This is not to say you need to do it like this, just that >that is how the original design that Eric created worked.) > I realize that. It was easy to implement, since I already had to check for :: to be compatible with type 1 messages. >If you did want to follow this model, you could think about using a >MIME header to indicate the type of the message contents rather than >the "::". Another alternative would be to use a different special >field in the mail header, like perhaps your "Remailer-Type: 2.0", but >I'm not sure that a new top-level header field is the right place for >this. It looks to me like most of the standard headers deal more with >moving the message around rather than with telling what would be done >with it on receipt. It's kind of a fine line but it looks to me like >more of a job for a MIME content type since that is really what it is >for. You could use something like: > >MIME-Version: 1.0 >Content-Type: application/remail; version="2.0" > >or > >MIME-Version: 1.0 >Content-Type: application/remail-mark-2 > >Then the rest of the message could look just as you have it. Or, to use >a little more of the existing standard, you could add: > >Content-Transfer-Encoding: base64 > >and take out your BEGIN and END lines since it looks like you are using >base64, although the augmented kind that PGP uses with the CRC at the >end; you'd have to lose the CRC in that case. (I wonder if PGP will do >that in the MIME-PGP integration draft that is supposedly being worked >on.) > >One question is, how do you actually send your messages in the >mixmaster client and servers? Do you go directly to sendmail, or do >you use a user agent like /bin/mail? If the former then it doesn't >seem like it would be too hard to add these header fields. On the >receiving end then hopefully also it would not be much harder to match >the Content-Type: string than the one you are using. > >The advantage, again, is that to a considerable extent this kind of >application is exactly what MIME was planning for with the "application" >content-type. This lets you mark the contents of the message in a >standard way. And you are already using something very close to the >base64 encoding that MIME specifies. So this does seem like a good >opportunity to go with the internet mainstream by following this >standard. If this seems like something you want to do I'm sure our MIME >experts here can tell how to define a new content type. > >Hal > I agree that changing mixmaster to search for a MIME line, rather than the :: would be no effort at all. I use sendmail for the client and the remailer (actually they are the same code), so adding new headers is easy. Unfortunately I am having some problems with sendmail. Sendmail is marking the messages as "Apperently To:" rather than "To:". Any idea what might cause that? I am not sure I want to give up the CRC on the armor (esp. since I am using the PGP tools routines and not my own), but I would be interested in defining a new MIME content type. So, experts, what all is involved in that, and is there any problem with starting to use a MIME type before it is official? -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLzsIElVkk3dax7hlAQFlmgP9FNxSrabWU7CyiRu1Kv28Lz2htuukq1Ul ANG4y/arJ9gseBvOxDKVDLVKWN1c2XyOKrEbUTVXxHDhk/WwhfpvJE/UrVWQuFEP eaFZB4G1xBvyjkx+DoQxsLVTEVcF1V54Mo5tfARBGCqf7aHqQGoLiRu8kR6i04fj nPgOrMeE5Bk= =vg7R -----END PGP SIGNATURE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Check out my essay on the next generation remailer Mixmaster on the WWW page. For anon remailer info, mail remailer(a)nately.ucsd.edu Subject: remailer-help "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

3 2

http://www.vocaltec.com/gti.html
by Duncan Frissell 17 Dec '03

17 Dec '03

As seen on page B1 of today's WSJ: > [Image] > > Talk over the Internet with your own voice. > Communicate with people from all over the world. > And all this with your existing Internet account. > > Internet Phone (TM) is a unique software product that opens a new and > exciting dimension for Internet users. With Internet Phone you can use > the Internet to speak with any user all over the world! Yes, real-time > voice conversations over the Internet, at the price of a local phone > call or even less. > > All you need is Internet Phone, a TCP\IP Internet connection and a > Windows-compatible audio device. Plug in a microphone and speaker, run > Internet Phone, and, by clicking a button, get in touch with Internet > users all over the world. Whether you want to meet new friends, get > information personally, or make the direct business contact, Internet > Phone is for you. A friendly graphic user interface and a smart > Voice-Activation feature make conversation a snap. VocalTec's > sophisticated voice compression and voice transfer technology makes > sure your voice gets across in a flash, using only a fraction of the > available bandwidth. > > Internet Phone always presents you with an updated list of topics and > on-line users for you to choose. You can even set up Quick-Dial > buttons which give you immediate access to frequently called users. > Once you establish contact with a user, communication is carried out > directly over the Internet. > > [Image] > > How can I order Internet Phone? > > To be able to fully use Internet Phone over the Internet, you need a > unique registration code. The Internet Phone software license can be > purchased for only US$49! This is a special limited time offer (The > standard retail price is $99). All you need to do is fill out and send > us this order form, and we will supply you with the registration code. > > You can even download the Internet Phone software and evaluate it for > free! Without the registration code, you can use all of the Internet > Phone features, but are limited to 90 seconds of speech. You have > nothing to lose - check it out. > > You can download your free evaluation copy of Internet Phone from > ftp://ftp.vocaltec.com/iphone.zip. > > For business and power users, VocalTec offers the Internet Phone Kit. > The Internet Phone Kit includes, in addition to the Internet Phone > software, unique hardware that improves sound quality and dramatically > reduces bandwidth consumption. > > Internet Phone System Requirements: > > 486SX PC - 25 MHZ, 8MB RAM (recommended) > > WinSock 1.1 > > An Internet TCP\IP connection (minimum connection: a modem > SLIP\PPP connection of 14,400 baud) > > Windows 3.1 > > Windows-compatible audio device > > SEE ALSO: > > > [Image] Ordering Internet Phone > > [Image] Internet Phone: Main Features > > [Image] Request More Information > > [Image] VocalTec Home Page > > > ------------------------------------------------------------------------ > > VocalTec Inc. * 157 Veterans Drive, Northvale, NJ 07647 * Tel: > 201-768-9400 Fax: 201-768-8893 * info(a)vocaltec.com

1 0