December 2003 - cypherpunks-legacy

WOW!
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, I just totaled up the "Bring Dimitri to San Francisco" pledges. The pledges add up to an amazing US$681 and some guava pastries. Airfair should be around US$300. That, plus hotel should come in under the amount pledged so far. I'd still like additional pledges, however, I want to be certain we're covered and as an expression of the mood of the list. I intend to front the entire amount myself and then ask the "pledge partners" for a pro rated payment based on the actual cost and their proportionate pledge amount. It's interesting to me that several pledges have come from list members who are far removed from San Francisco. One or two of them plan to attend Dimitri's meeting, but most just want to have it happen. I've only had one request for anonymity, but I have kept names confidential without a clear go-ahead from them. (If you have already pledged or pledge in the future, please let me know if you mind if I post your name/nym.) Now there's only one thing missing--Dimitri's response. My open letter to him contained an explicit and unambiguous invitation to address a Cypherpunk meeting on any topic he wanted. I asked him for a clear yes or no, but have received nothing. Perhaps Dimitri prefers shooting from ambush. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

5 6

Re: binding cryptography
by James A. Donald 17 Dec '03

17 Dec '03

At 09:53 PM 10/14/96 +0200, Ulf Moeller wrote: > So governments can wiretap > law-abiding citizens, but not criminals. What use is a system like > that? For the government, very useful indeed. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

Cynthia Dwork talk: Non-Malleable Cryptography
by frantz＠netcom.com 17 Dec '03

17 Dec '03

Sorry for the late post. I'm way behind in reading my mail. Bill --------------Begin forwarded message--------------------- Date: Mon, 14 Oct 1996 09:27:14 -0700 From: "Francois V. Guimbretiere" <francois(a)cs.stanford.edu> X-Mailer: Mozilla 2.01 (X11; I; Linux 1.3.48 i586) To: secure(a)lists.Stanford.EDU, colloq(a)cs.stanford.edu Subject: Cynthia Dwork talk: Non-Malleable Cryptography Sender: owner-secure(a)lists.Stanford.EDU Precedence: bulk Title: Non-Malleable Cryptography Speaker: Cynthia Dwork, IBM Almaden Research Center Time: Tuesday 15 Oct 1996, 4:15pm, Gates 104 ABSTRACT: The notion of {\it non-malleable} cryptography, an extension of semantically secure cryptography, will be defined. Informally, in the context of encryption the additional requirement is that given the ciphertext it is impossible to generate a {\it different} ciphertext so that the respective plaintexts are related. Common public key cryptosystems are quite malleable: for example, in RSA it is trivial to compute $E(2x)$ given only $E(x)$. Although defined with public key cryptography in mind, non-malleability issues also arise in private-key cryptography. Indeed, the security of many common protocols, such as Kerberos, relies implicitly on the inability of an adversary to compute $E(f(N))$ given only $E(N)$, for simple functions $f$. The talk will focus on non-malleable public key cryptosystems. with a few remarks on non-malleable schemes for private-key cryptography, string commitment, and proofs of possession of knowledge. This is joint work with Danny Dolev and Moni Naor. ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe secure" to majordomo(a)lists.stanford.edu ------------------------------------------------------------------------- Bill Frantz | Tired of Dole/Clinton? | Periwinkle -- Consulting (408)356-8506 | Vote 3rd party. I'm | 16345 Englewood Ave. frantz(a)netcom.com | Voting for Harry Browne | Los Gatos, CA 95032, USA

1 0

[Repost] PipeNet
by Lucky Green 17 Dec '03

17 Dec '03

Below is a repost of the original PipeNet article from February, 1995. The author is Wei Dai. -----BEGIN PGP SIGNED MESSAGE----- A week ago I made a suggestion for a new protocol for untracibility, but only got one response. I'll try again, this time more forcefully. I'm not trying to convince anyone to implement this (though of course you're welcome to!), but just to think about it and give me feedback. Why is another protocol needed? Right now we have only two, each of which has its own set of tradeoffs. To summarize: Mix-Net (i.e., remailer-net): high latency, moderate bandwidth costs, and low complexity DC-Net: moderate latency, high bandwidth costs, and high complexity While the DC-Net will probably never be widely used, the remailer-net has a fair chance of one day providing a way for many people to send e-mail that not even governments can trace. However, I don't think this is enough. Efficient social and business relationships require that people be able to converse to each other in real time. Cryptoanarchy will not come about if people cannot do this anonymously. How well can two pseudonymous agents negotiate a contract if each message they send must be delayed several hours? The protocol I sugguested would have low latency, moderate bandwidth costs, and moderate complexity. It would be well suited for people to interact anonymously in a textual environment. This is what I wrote: > Imagine a server that allows you to open a > low bandwidth (let's say around 100 cps, in order to reduce costs) > link-encrypted telnet session with it, and provides you with a number > of services, for example a link-encrypted talk session with another > user. You'll need to maintain the link 24 hours a day to defend > against statistical analysis, and of course you can chain a number of > these servers together in a way similiar to chaining remailers. Lance pointed out the chain cannot be built quickly. This is not a problem if servers connect to each other with relatively wide link-encrypted pipes and multiplex your connection into these pipes. In this system, latency would never be more than a few seconds, bandwidth cost is N*100 cps (point to point), N being the number of links in your chain. Implementation would probably be harder than remailers, but much easier than DC-Nets. The protocol would also provide both sender and receiver untracibility without any need for broadcasting. Wei Dai P.S. I never gave a name for the protocol... let's call it Pipe-net. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzgewDl0sXKgdnV5AQGzvAQAgFaOxOzFPgS031z4jZRYUJp/+3BS5Con Kza7WsvZPvxzaNLh9ecD3aCx5dtf4muaiUKjC2HIItaLKEdZZPdzUGFd4wg1cY8G k8mvYNzDImr3ZtQ0HiqQ59PWhznad0GuhjQajB7RtpI+K/Z4uBaUEZGVoZZT+LHN MSjOl/k/yfg= =jgq6 -----END PGP SIGNATURE-----

1 0

cryptlib 2.00 free encryption library released
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

Version 2.00 of cryptlib is now available from ftp://garbo.uwasa.fi/pc/crypt/crypl200.zip and also from ftp://ftp.franken.de/pub/crypt/misc/cryptl200.zip. The library provides an easy-to-use interface which allows even inexperienced crypto programmers to easily add strong encryption and authentication services to their software. The library contains DES, triple DES, IDEA, MDC/SHS, RC2, RC4, RC5, SAFER, SAFER-SK, Blowfish, and Blowfish-SK conventional encryption, MD2, MD4, MD5, RIPEMD-160 and SHA hash algorithms, and Diffie-Hellman, DSA, and RSA public-key encryption, as well as a comprehensive high-level interface with functions such as cryptCreateSignature() and cryptExportKey(). The library is supplied as source code for Unix (shared or static libraries), DOS, Windows (16- and 32-bit DLL's), and the Amiga. The library provides a standardised interface to a number of popular encryption algorithms, as well as providing a high-level interface which hides most of the implementation details and provides an operating-system-independant encoding method which makes it easy to transfer encrypted data from one system to another. Although use of the the high-level interface is recommended, experienced programmers can directly access the lower-level encryption routines for implementing custom encryption protocols or methods not provided by the library. The library API serves as an interface to a range of plug-in encryption modules which allow encryption algorithms to be added in a fairly transparent manner. The standardised API allows any of the algorithms and modes supported by the library to be used with a minimum of coding effort. As such the main function of the library is to provide a standard, portable, easy-to-use interface between the underlying encryption routines and the user software. In addition the easy-to-use high-level routines allow for the exchange of encrypted session keys and the creation and checking of digital signatures with a minimum of programming overhead. The library has been written to be as idiot-proof as possible. On initialization it performs extensive self-testing against test data from encryption standards documents, and the API's check each parameter and function call for errors before any actions are performed, with error reporting down to the level of individual parameters. The library implements a security perimeter around the encryption functions, with encryption contexts consisting of an arbitrary handle referring to (hidden) data held within the library. No outside access to state variables or keying information is possible, provided the underlying OS provides some form of memory protection. If the OS supports it, all sensitive information used by the library will be page-locked to ensure it is never swapped to disk. There is one small bug I found about an hour after it was released (sigh), you can't use CRYPT_USE_DEFAULT as a parameter to cryptCreateContext() due to missing parentheses in crypt.c. Incidentally, if someone in Europe with a high-bandwidth link to the rest of the world could provide a permanent site for cryptlib betas that'd be useful, since the current beta distribution system is rather ad hoc. Peter.

1 0

Royalties
by pclow 17 Dec '03

17 Dec '03

Dear C'punks I understand from a previous post that if I were to commercialised PGP in a package, I have to pay some royalties(?) to the owners(?) of IDEA. My apologies to the list for repeating the question which is, who do I pay to and how much. Thanks.

3 5

Sameer should sue the SPA
by Matthew Ghio 17 Dec '03

17 Dec '03

Let's see, what can Sameer sue the SPA for... 1) Filing a frivilous lawsuit, of course. 2) Extortion. "Sign this or we'll sue." 3) Libel and Defamation. "SPA's false statements about Mr. Parekh have harmed his reputation as a software publisher, and cost him profits..." 4) Conspiracy to violate the ECPA by demanding logs and records which may contain private/confidential information. (Dunno about this one, but it's worth a shot.) 5) Anything else? How much $ in damages do you think he can get? Also, SPA is going after C2 because one of their customers allegedly had a link to a pirate site - but they have (apparently) not gone after the pirate site itself! Could someone explain to me how there can be a finding of contributory copyright infringement, when there is no direct copyright infringement? Fonovisa v. Cherry Auction is an often-cited case here. In this case, a lawsuit was brought against the swap meet operators only after action had been taken against the vendors of the illegally copied material. It does not seem logical that c2 could be liable for contributory infringement when no actual infringement has (yet) been shown to exist.

4 3

Re: COMMUNITY CONNEXION SUED IN FRIVOLOUS LAWSUIT
by Bill Stewart 17 Dec '03

17 Dec '03

At 06:03 PM 10/14/96 -0700, Steven L Baur <steve(a)miranova.com> wrote: > http://www.spa.org/piracy/CODE.htm > ... > 8. Do not sponsor, endorse, or advertise access to infringing > software. I wonder how a "Hack Netscape" or "Hack Microsoft" contest fits in with this, to name two major public services run by C2...... # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk Imagine if three million people voted for somebody they _knew_, and the politicians had to count them all.

1 0

Oregon DMV database online once again...
by Cerridwyn Llewyellyn 17 Dec '03

17 Dec '03

The Oregon DMV database will once again be searchable on the web, in a few days, at http://www.notek.com/or-dmv. Suggestions on what sorts of privacy-related propaganda should be on the page are welcome (and encouraged: currently there's really nothing there...) Also, looking for a volunteer to write a quick press release we can send to Oregon media, regarding the reasons behind the page, etc. (I suck at such things, and would prefer if someone else with a talent for writing on cypherpunk-type topics would do it.) A few details, for those who want to know: the actual databases are stored on a 486DX/33 (the only machine I could spare for the task..) running linux 2.0.13 with 8 megs o' RAM. The search isn't quite as speedy as Genocide2600's (the previous home of the Web-Searchable dmv database), but it's reasonably fast. The license database is indexed on last name, the plates database is currently indexed on plate number, but when I can find more harddrive space, it will also be indexed (and thus searchable) by last name, which is a bit of an expansion on Genocide 2600. Anyway, all that's really left is a few hours of work tidying up the cgi/database server code and finishing the actual web page, which I should get to tomorrow or possibly the next day. I'll post a notice when the page is officially up, but in the meantime, please let me know what type of privacy propaganda/tools/info (if any) would be appropriate. Thanks... //cerridwyn//

1 0

AS2805.65 standard?
by Min-Ming Chin 17 Dec '03

17 Dec '03

Hi, there, Anyone heard of the Australian security standard AS2805.65? Beats me...

1 0