December 2003 - cypherpunks-legacy

Paper on NetCheque and requirements of network payment services
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>From: bcn(a)ISI.EDU >Date: Thu, 12 Jan 1995 11:11:49 -0800 >Posted-Date: Thu, 12 Jan 1995 11:11:49 -0800 >Original-From: Clifford Neuman <bcn(a)ISI.EDU> >To: www-buyinfo(a)allegra.att.com >Subject: Paper on NetCheque and requirements of network payment services >Status: U > >There is a new paper available on NetCheque(TM) and requirement of >network payment services. The paper will be presented at IEEE Compcon >in March. The paper can be retrieved from prospero.isi.edu in > >/pub/netcheque/information/netcheque-requirements-compcon95.ps.Z. > >Clifford Neuman ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

San Diego CPunks Symposium
by Claborne, Chris 17 Dec '03

17 Dec '03

CPUNKS symposium Thursday, Jan 26, 1995 Invitation to all Cypherpunks to join the San Diego crowd at "The Mission Cafe & Coffee Shop" were I hope to get an update of weasel man's new anonymous e-mail server, "mixmaster", exchange keys, and generally shoot the shit. Don't forget to bring your public key fingerprint. If you can figure out how to get it on the back of a business card, that would be cool. Place: The Mission Cafe & Coffee Shop 488-9060 3795 Mission Bl in Mission Beach. Time:1800 Their Directions: 8 west to Mission Beach Ingram Exit Take west mission bay drive Go right on Mission Blvd. On the corner of San Jose and mission blvd. It is located between roller coaster and garnett. It's kind of 40s looking building... funky looking (their description, not mine) I will be wearing a BRIGHT PURPLE BICYCLING JACKET. Try to be their by 18:30 since we may move the meeting. See you there! Weasel man, don't forget to bring the latest info on mixmaster. Fish man, sweep the place for bugs. Anarchist, the FBI has already setup surveillance. Law man, bring the logo and your e-mail address of the month :) New guy, bring your fingerprint. NOTE: My e-mail address, "chris.claborne(a)sandiegoca.attgis.com" permanently replaces my .ncr.com address. Both address work for now but NCR address will eventually be killed. 2 -- C -- P.S. Tell your wife/husband you are going to a symposium. Unless she/he looks in the dictionary, she/he won't know that your are really going to a drinking party! ... __o .. -\<, chris.claborne(a)sandiegoca.attgis.com ...(*)/(*). CI$: 76340.2422 PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Avail on Pub Key server.

1 0

RELEASE: Secure Edit beta 0.5
by tjb＠acpub.duke.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- RELEASE: secure edit beta 0.5 for Macintosh Miyako Software has released an improved version of secure edit. It is now available for FTP from ripem.msu.edu in the directory pub/crypt/mac, and at other ITAR-compliant sites. Finger tjbryce(a)amherst.edu for an updated site list, as well as information on other products by miyako software. All releases are signed with the Miyako Software public PGP key. Version b0.5 sports the following new features: FOR EASE OF USE AND UTILITY: * extensive balloon help * an undo command * print command * a find command (useful for storing sensitive information with secure edit) * windows menu with tile and stack commands * copy with line breaks inserted, for composing email or pgp messages * much better and faster compression and a smaller base file size * secure edit now uses Colin Plumb's fast 68k assembly IDEA implementation * you can turn off the annoying ¶ marks * the menu blinking clunky has been fixed * the window update annoyance has been fixed * various interface clunkies have been fixed * new and more intuitive icons have been drawn FOR SECURITY: * much better random number management using the code written by Colin Plumb for PGP * random data is snarfed from all events the application observes (such as your keystrokes), the time these events occur, and by continuously tracking your mouse position, even when backgrounded. the pool of random data is maintained between sessions and is encrypted based on these random events before it is written to disk and before use. * so that every file is encrypted on a different IDEA key, making cryptanalysis of one useless agaist others, your key is salted with 128 bits of random data, stored in the clear for decryption, to make a 'session key'. thus, the key used to encrypt every file will be different, even if you used the same passphrase. this makes cryptanalysis of one file useless against others. * the salt is concatenated with MD5[passphrase] many times and this concatenated string hashed to generate the 'session key' for the file from your pass phrase. The number of times it is concatenated is calibrated to make it take about half a second - not a big performance loss, but it makes brute force attack of weak passphrases up to thousands of times more costly. * semi-splay compression is utilized, which is faster than the lame old compression (written by me :( ) and which gets >50% file reduction. It strengthens the encryption by reducing the redundancy in the plaintext. It also continually modifies the compression encoding system based on the data as it goes along, making the interpretation of compressed data dependent on the data that has come before it * you can verify keys against Curve Encrypt keyfiles * documents that are saved in plaintext format clearly distinguished by "TEXT:" in the window title * the source code has been cleaned up :-) and much improved to make it easier to verify yourself that the program is strong and secure. ------THE BASICS------ (from version a 0.3.4) SECURE EDIT is an editor designed for editing sensitive text buffers. It is designed to prevent plaintext from ever being written to disk, even if only momentarily. You might fail to overwrite or encrypt such plaintext properly, or your opponent might be able to retrieve some of the information even though you wiped it (see docs for details). Word Processors generally create temp and scratch files that leave plaintext on your drive whether you like it or not. Secure edit fixes this problem. Sometimes you need to quit in a hurry and have all your data encrypted and saved. Or you might prefer to have your files encrypted at all times so that you never forget to re-encrypt a file you worked on, and so that files are never in plaintext form while you are working with them. Secure edit sports the following features to serve these and other data security needs: * Plaintext is never written to disk - Secure Edit locks all sensitive buffers in memory so that virtual memory will never swap them to disk. This includes the text you are editing as well as any encryption keys in use. * Secure Edit never creates plaintext temp or scratch files * Secure Edit offers the option of saving files directly in encrypted format so you never have plaintext on the hard drive. * Your data is compressed and encrypted in RAM with the IDEA algorithm, then written to disk in encrypted format. * Secure Edit can mantain a secure, private clipboard, interconverting with the system clipboard only when you use OPTION-cut,copy, and paste. This prevents the system from getting a copy of your sensitive data and possibly writing it to disk, or leaving it around for another user to see. * Secure Edit can open foreign text files, and DOD wipe them on request when you save the file in encrypted format. * Secure Edit offers a default passphrase option so you only need to enter your passphrase once. It also offers the option of validating your phrase against secure validation information that can be used to check that you have entered your standard pass phrase, but which cannot be used to recover the passphrase. This prevents you from saving under a bad passphrase and losing data. * Secure Edit offers a time-out option, whereby it will save all files and quit after a certain idle time period * Secure Edit offers an option-quit feature, whereby it will assume it is okay to save all files, and save and quit as quickly as possible * Secure Edit is available to U.S. citizens in the U.S. at an ITAR-compliant site near you. I'm presently uploading it to ripem.msu.edu and others. * source code is, of course, available. * Questions about Secure Edit should be directed to me, at <tjb(a)acpub.duke.edu> Thanks for your attention. Tom Bryce /////////////////////////////_\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ *---------------------------------------------------------* Miyako Software is dedicated to creating freeware to help make computers tools of personal liberation and expression. for product info and PGP key, finger <tjbryce(a)amherst.edu> email: <tjb(a)acpub.duke.edu> *---------------------------------------------------------* \\\\\\\\\\\\\\\\\\\\\\\\\\\\\_///////////////////////////// -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLxN4F08YjrUhOUC5AQGueAQAkJNvwUO5QVZd9FQnfwm2HnKiFH/DvAUQ 2TWkrqhRJ2R06Ht98Vrw/ixacQLP9GEobKlK1WDdQE/lNZGre2IgLS0lXm39F1ll A0wSIpRrJ5wK2KlWEbq1e5cuaooA/+Y2C6U7RAQbj+/wF9/9FqKvzmLAzYgx2pqD VxDCzkn2A4s= =d0DX -----END PGP SIGNATURE----- ------------------------------------------------------------------------ /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/~~\ | Tom Bryce |____| ___ | Duke Med | ___ {~._.~} | tjb(a)acpub.duke.edu | {~._.~) ( Y ) | PGP keys: finger tjbryce(a)amherst.edu | ( Y ) ()~*~() |personal:9B6088464ED86413 0F5E55E45CF1C961| ()~*~() (_)-(_) |miyako | (_)-(_) |software:02646F0B06DCFE03 E6DD367DB4E1010F| /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ | \_________________________________________\__/

1 0

Re: How do I know if its encrypted?
by Ben.Goren＠asu.edu 17 Dec '03

17 Dec '03

Here's a solution: Alice sends a file to Dave's DataHaven. When Alice wants her file back, she sends to Dave a secure hash of the file, a key with which to decrypt it, and a handful of plaintext at the beginning of the file. Dave decrypts the file that matches the hash with the key Alice gave him; if the file begins as Alice says it should, Dave returns the file to Alice. This way, only those people who have an intimate knowledge of the files can recover them. The hash isn't vital; Dave could try to decrypt each file on the server with the key Alice gives him until he matches the plaintext--but that's neither elegant nor friendly to the CPU. People can send Dave whatever kind of file they like, but they'll only get it back if it's been encrypted properly. If Dave charges to store a file, he'll gladly welcome as much spammage as people want to send him. If he likewise charges to return a file, he'll just as glady send a file to whoever gives him the cash and can identify it. Dave can have a policy whereby he deletes a file after returning it, unless Alice pays more to keep it there. Thus, Bad Bobby can send his naughty pictures to Dave, tell the 'net how to get them--but the first person who neglects to include the fee to leave the pictures there winds up blocking out everybody else. Similarly, Samaritan Sam could get into a spending war with Bobby. Each time Bobby sends Dave his smut, Sam retrieves the file without paying for its continued storage--and takes a sneak peak at the pictures before deleting them himself. Dave has no way of knowing what people are storing on his machine until the owner asks for the file back, and so cannot be held liable for the storage of "undesirable" files. Mallet could seize the entire archive and have nothing useful. Eve could recover information leaving the haven, but presumably Alice will further encrypt her files however she chooses. Or, as a service, Dave could agree to encrypt the file with an assymetric cipher before returning it. b& -- Ben.Goren(a)asu.edu, Arizona State University School of Music Finger ben(a)tux.music.asu.edu for PGP public key ID 0xCFF23BD5.

2 1

/n@Nd0/ LPF Statement on the GIF controversy
by Dean Anderson 17 Dec '03

17 Dec '03

[ Please repost this wherever you think is appropriate! ] Until now, most computer professionals and companies have ignored the problem of software patents. The GIF format for graphical images was adopted widely on the net, despite the Unisys patent covering the LZW data compression algorithm. The patent dates to 1985, but its enforcement has been carried out with private threats; most victims are afraid to talk about it. Now the patent has shown its teeth. For a few days, the Internet community was shaking with anger at the surprise demand to pay license fees for the use of GIF format. It turns out that the license being offered today is only for Compuserve users. Compuserve accepted an offer from Unisys that they couldn't refuse. Compuserve users can accept this offer now, or face Unisys later on their own. The rest of us don't have a choice--we get to face Unisys when they decide it's our turn. So much trouble from just one software patent. There are now over ten thousand software patents in the US, and several thousand more are issued each year. Each one may be owned by, or could be bought by, a grasping company whose lawyers carefully plan to attack people at their most vulnerable moments. Of course, they couch the threat as a "reasonable offer" to save you miserable years in court. "Divide and conquer" is the watchword: pursue one group at a time, while advising the rest of us to relax because we are in no danger today. Software patents may not seem like an urgent problem until you find one aimed at you. We all have other fires to fight, and most developers have hoped that the patents would never blaze up. In an ironic way, Unisys has done us a favor--by showing that the problem is too serious to ignore. What people first feared, could just as well have happened. Each of the thousands of software patents has the potential to devastate a segment of the community, both software developers and users. There will be more nasty surprises. They are part of a system. Unisys has given us a chance to work together to change the system--rather than waiting to be sued one by one for this patent or that. We can win the fight against software patents, if we speak loud and clear against them. What can people do? * Express your disapproval to Unisys by writing a letter to its CEO. Tell him what you think of his company's actions: James Unruh CEO UNISYS Corp. PO Box 500 Blue Bell, PA 19424 fax: 215-986-6850 Please use snail mail--a physical pile of letters is more impressive, psychologically, than a big file of email. Keep it short--ten lines is enough. Don't spend hours composing your letter; there's no need. But do write it in your own words, because sending a form letter written by someone else is not impressive. Make it clear that the usual excuses--"We're just exercising our property rights; look how reasonable we are being (compared to what we _could_ have done)"--won't wash with you. Avoid saying anything nasty that would give Unisys a chance to paint itself as the victim. Cold condemnation is more powerful than flames. Please email a copy of your letter to the League for Programming Freedom at gif-letters(a)lpf.org. We might ask you for permission to publish your letter. * Don't sign a license--stop using GIF. The World Wide Web consortium at MIT will probably be coordinating the move away from GIF, and offering advice and assistance. See `http://www.w3.org/'. * Join the League for Programming Freedom. The League is a membership-based organization whose aim is to bring back the freedom to write software. The League says that no one should be able to dictate what kinds of programs you can write. You can contact the LPF by email to lpf(a)uunet.uu.net, or look at its Web pages at `http://www.lpf.org/'. ** Note: the recent license demand came in the name of Compuserve; but the impetus for it came from Unisys. Compuserve developed the GIF format many years ago, not knowing there was a patent on LZW. (Most programmers have no idea what patents their programs are vulnerable to--there are too many patents to keep track of.) When Unisys threatened to sue them, Compuserve had to give in to Unisys's demands. Compuserve arranged to be allowed to offer Compuserve users a sublicense, but the "offer" was formulated in a way that was tantamount to an ultimatum. Compuserve may bear responsibility for some of the details of how this was handled, but the main responsibility falls on Unisys. It is Unisys that claims the power to dictate what kinds of software you can write. Unisys decided to use the power for aggression; Unisys forced Compuserve to participate. =++=+=+=+++==++=+=+=+++==++=+=+=+++==++=+=+=+++==++=+=+=+++==++=+=+=+++= Dean Anderson Dean(a)hi.com President League for Programming Freedom

1 0

Re: RELEASE: Secure Edit beta 0.5
by Ben.Goren＠asu.edu 17 Dec '03

17 Dec '03

At 5:18 PM 1/12/95, Tom Bryce wrote: >[. . .] >* the salt is concatenated with MD5[passphrase] many times and this >concatenated string hashed to generate the 'session key' for the file >from your pass phrase. The number of times it is concatenated is >calibrated to make it take about half a second - not a big performance >loss, but it makes brute force attack of weak passphrases up to >thousands of times more costly. >[. . . .] This is only going to work if MD5 is not a "group"--that is, if there is no simple algorithm which is equivialent to md5(md5(x)). I doubt that's been proven. Rather, you'd be better off using DES in any of the ways that Schneir describes (page 338 and following) and reiterate that many times. b& -- Ben.Goren(a)asu.edu, Arizona State University School of Music Finger ben(a)tux.music.asu.edu for PGP public key ID 0xCFF23BD5.

1 0

Re: How do I know if its encrypted?
by pstemari＠erinet.com 17 Dec '03

17 Dec '03

At 10:08 PM 1/11/95 -0800, Eric Hughes wrote: > ... Seems to me that a quite reasonable condition of use of a remailer is >that what is passed isn't human readable. Perhaps I missed this, but why? If someone is going to plant kiddie porn or whatever on you, does it really matter if they encrypt it first or not? If the purpose is simply to generate additional encrypted traffic to obscure stuff that needs encryption, that goal might be better served by simply encrypting files for their recipient as they pass through, in those cases where a public key is available and the msg isn't already encrypted. I forget the name of the cypher (Vigere, perhaps--the one that uses a series of Caesar-like cyphers keyed by a password), but you could just run it through that with a password of abcdefghijklmnopqrstuvwxyz and you'd flatten out the distribution enough to get it by casual inspection. --Paul J. Ste. Marie pstemari(a)well.sf.ca.us, pstemari(a)erinet.com

3 3

essential characteristics of a Data Haven
by Adam Feuer 17 Dec '03

17 Dec '03

folks, looking thru the cyphernomicon, this is about all i could come up with for characteristics of a data haven: |16.22. Data Havens | 16.22.1. "What are data havens?" | + Places where data can be hidden or protected against legal | action. | - Sterling, "Islands in the Net," 1988 anyone have a list of the essential characteristics of a data haven? what differentiates a "data haven" from "reasonably secure offsite storage"? here's my attempt at a working definition: a "data haven"... 1. "securely" stores data files for remote users. 2. will only allow "authorized" entities to store files in the data haven. 3. will only allow "owners" of the files to withdraw their files from the data haven. 4. differentiates "authorized" entities from "non-authorized ones, and "owners" from "non-owners", only by means of cryptographic keys. terms i left undefined are "securely," authorized," and "owner." by "secure" i imagine a DH will attempt to prevent its data from being destroyed, or read by anyone other than the data's "owner." by "authorized" i imagine that a DH will not want to accept data from just anyone. (for instance, people who don't pay.) by "owner" i mean the specific "authorized" entity that stored the data in the DH. i imagine that most DH's will need to accept digital cash to be able to operate. is this an essential characteristic of a cp data haven? what did i leave out? adam adamfast(a)seanet.com

2 1

How "good" is MDC?
by Robert Rothenberg 17 Dec '03

17 Dec '03

I've been toying with a homegrown implementation of the MDC algorithm, similar to the one used in HPack, written mostly in 386 assembler though. My version also scrambles the constants by multiple cycles over the key, so it should be better the vanilla MD5... I'm wondering how "secure" MDC is, though... are there better hashing algorithms or possible modifications that could be made? (A silly question considering I haven't yet released the sources. When they are ready I'll post an announcement or something.) Rob

1 0

Keyboard sniffer source code
by m00012＠KANGA.STCLOUD.MSUS.EDU 17 Dec '03

17 Dec '03

Not to be paranoid, but did anybody receive that program? Does cypherpunkcs(a)toad.com have a pgp key? I think it was intercepted. mike

2 1