December 2003 - cypherpunks-legacy

Re: Multiple symetric cyphers
by grmorgan＠freenet.vcu.edu 17 Dec '03

17 Dec '03

> >> But selecting a single cipher is just as much a fixed policy as a >> randomly selected one is. Far better to let the user pick a policy, >> both about sent and accepted ciphers. > >If you do give the user control, what is an acceptable mechanical >implementation? Let's say I have a file encryptor which allows the >user to choose between DES, 3DES, IDEA, Diamond, and RC5. Must I >require the user to tell that program what cypher was used to encrypt >the file she wishes to decrypt? > >Is storing the cypher type as part of the encrypted file a weakness? Perhaps an MD5 of the password could be encrypted along with the plaintext using the method(s) of choice. At the decryption phase, the password would be MD5 hashed again and the block of bytes the size of an MD5 hash would be "decrypted" with each of the methods... which ever one matches the original MD5 hash would be used to decrypt the rest of the cyphertext. This method wouldn't leave a known plaintext in the file to attack. -- ----------------------------------------------------------------------------- Greg Morgan <grmorgan(a)freenet.vcu.edu> | "I dunno Brain, me and Pipi

1 0

Available: Cash paper by anonymous FTP
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>From: brands(a)cwi.nl >Original-From: Stefan.Brands(a)cwi.nl >Subject: Available: Cash paper by anonymous FTP >To: www-buyinfo(a)allegra.att.com >Date: Thu, 12 Jan 1995 18:57:39 +0100 (MET) >Mime-Version: 1.0 >Status: U > > > I have made available for ftp-retrieval my paper > > "Off-Line Electronic Cash Based on Secret-Key certificates." > > This paper will be presented at the Second International Symposium of > Latin American Theoretical Informatics (LATIN '95), April 3-7, 1995. > > If you are interested in downloading a copy, login by anonymous ftp at > > ftp.cwi.nl > > The paper is in the directory pub/brands, under the name > "latin95.<ext>." The extension <ext> refers to dvi and PostScript > formats. > > Greetings > > Stefan Brands, > ------------------------------------------------------ > CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands > Tel: +31 20 5924103, e-mail: brands(a)cwi.nl > > ----------------- 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

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

/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

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

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

17 Dec '03

Ben Goren wrote: >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. This is not exactly what secure edit does. It hashes in the following manner to generate a session key: MD5 [ (128-bit salt) MD5[passphrase] 0 MD5[passphrase] 1 MD5[passphrase] 2 ... ] to get the session key. The 0, 1, 2 is a single byte. So there is only one level of nesting of the hashes. This is actually a common and well-regarded technique for increasing the security of weak passphrases. Tom ------------------------------------------------------------------------ /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/~~\ | 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

RELEASE: secure edit, resend (was bad pgp signature)
by tjb＠acpub.duke.edu 17 Dec '03

17 Dec '03

It's been brought to my attention that I messed up and the pgp signature did not validate my post about secure edit. I'm not sure where exactly I messed up, but here goes again... sorry for sending it twice. :( -----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 iQCVAwUBLxX0v08YjrUhOUC5AQE/UwP/eLKniLvJhYm1b1RZf0/0qY3mBUfhIMeT R/ozIURiOD/qnfmn6Un9BAVvEBiVxivj8z6J2ByOREGO1ZYgpO1kZcEu0tZoP0eo 4fGeg652BYRqk4+Ltw3XcV1nDfudukAOoT9waiub1JsPeNDP/DuM+yt05gPNplNV UMToRWfMgaM= =T/QC -----END PGP SIGNATURE-----

1 0