December 2003 - cypherpunks-legacy

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

RELEASE: Secure Edit beta 0.5 (again!)
by tjb＠callisto.acpub.duke.edu 17 Dec '03

17 Dec '03

I again apologize for sending this a THIRD time, but we all agree it's important for PGP signatures to verify properly or people will get sloppy about verifying them and expecting them to be valid. I strongly suspect Eudora is doing some formatting of the email when I send it with Eudora, so I'm sending this post through internews instead. This really should work - I always paste it first in here, then check the signature on the clipboard with macpgp. It checks out fine, but when I send it to the list, the signature doesn't verify again. Tom -----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

signature business for secure edit release announce
by tjb＠acpub.duke.edu 17 Dec '03

17 Dec '03

I'm not going to waste any more bandwidth sending the announcement (sorry), but here's how you can validate the signature if you'd like to. If you'd like to verify the signature on the announcement for secure edit, please finger me at tjbryce(a)amherst.edu. In my plan is contained the announcement with a valid signature from Miyako Software's public key. Even though I had "treat source file as text" selected, I think there must have been left over some weird character in there that is not transmitted through email properly. What I did to get the signature to validate was place the announcement in my plan at amherst.edu, finger myself, copy the signed announcement, detach the invalid signature with mac pgp, sign the leftover text and copy just the resulting signature, log back onto amherst, and I edited the plan.txt file, pasting the new signature onto where the old signature used to be. FINALLY WORKED! Sincere apologies for using THREE TIMES the bandwidth the message actually needed, and not even getting it to work at that. Thanks to Bill Evans for checking out the signature and noticing it was invalid. Tom

1 0

Some PGP problems
by John Draper 17 Dec '03

17 Dec '03

Hi, I'm trying to decode a PGP file that was created with Ver 2.6. At this time, I thought that my older ver 2.1c (Running on a Mac) would at least be able to decrypt something made from a higher version, running on a PC. Apparently that is not so. So, the next thing I did, or what any self respecting Cypherpunk might so, is to go out on the net and look for a later version to FTP> Well, after discovering that soda.berkeley.edu don't exist anymore, I eventually found the ftp site where it lives. ftp.csua.berkeley.edu. I learn that Mac PGP2.3 exists, but NO version 2.6 exists for the Mac. Is that true? If not, then where can I get a copy, so I can decode a message created with 2.6? If ver 2.3 will decode a message encoded with 2.6, then I'm faced with how I can extract this Mac file which has a .gz extension. Binhex don't seem to decode it. So, I now got this file named "macpgp2.3.cpt.hqx.gz" on my Mac. Was I supposed to have used some special UNIX itility to convert the .gz thingie first? Please emlighten this confused cypherpunker!!! :-) Or will I even have to do all of this because 2.3 is incompatable with 2.6. C. Crunch

2 1

Re: for-pay remailers and FV
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Pierre Uszynski writes: >Doug Barnes said: <SNIP> >Same here, but from the other tack: "Remailer Guild??? Give me a >break :-)" My problem with the idea of "Guild" (or any quasi >general agreement) of remailer operators is that: > >On the one side: >- The whole idea of a using a remailer chain comes from distrust of >the operators. The operators should be the ones to distrust each other >the most. I agree. There should be minimal cooperation between remailer operators. They should work together on standards and policies to ensure the free flow of messages. They should not be afforded an oportunity to conspire. <SNIP> >Pierre. >pierre(a)shell.portal.com Observation: Most complaints to remailers come from news posts. Only a small fraction from direct mail. (Is this the experience of the other operators?) Suggestion: Pay the first and last remailers in the chain. The first remailer knows who you are. You simply purchase an account from him. He provides support and user friendly utilities... Block all posts from normal remailers. News posts only allowed from pseudonym servers like omega.c2.org. The user uses e-cash, or greenbacks in an envelope, to buy an account on the nym server. All email from other remailers, and to any address is free. Thoughts? -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLxOHzVVkk3dax7hlAQGnfQP9HJG+O/L/+L9hGqZ6xYqfmJh30Kwli7r6 BTEck7NwJ1W3gk6IpLy+NG4l/v8HCEyWvQGHYsGcBJkl+y6i2otb8Y6Bec25xntZ KlfwNi6UON5rpnP8+EFolcolfb9OpEIMhfirzu07jVkM72mUBp7IAzFZjZ2NTUY+ oLDCa0V2EWg= =0TTW -----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/ Home of "chain" the remailer chaining script. 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

1 0

Re: Remailer postage
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >jpb(a)gate.net wrote: >> Where can I get the Magic Money software? > >I'm a bit behind, so sorry if others have already suggested this, but >you should need any digicash for this... stamps can be just big random >numbers. Someone buys a books of stamps, you make 10 big random >numbers send them a copy and keep a copy on file. After a message >comes through with a particular number you throw that number out. > >Just like real stamps, and unlike money, they can be used only once. However I now can recognize which messages are yours. If I work with another operator, I can eliminate all the remailers between us for purposes of traffic analysis. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLxOPhFVkk3dax7hlAQEy7AP+NZOV8cZ94VfInTy5RHKasPOxrmBzcy9k Bc1nqyK95ae4mr+XWNBBpqjL4FQBwTpnSVI+eVAnTd9QWK9XND3YN8M9PdzzM8zF qdrB4I7aB29AJsenQWD1zujZDNLwMaaRxDYe47xR5vD+o7LIUMHxBvveLllp0pAM Ek2wjwQhezI= =PsFM -----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/ Home of "chain" the remailer chaining script. 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

1 0

Re: Remailer source
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

>Octavian Ureche <tavi(a)info.polymtl.ca> wrote: > >> Does anybody know where could I find UNIX sources >> for a remailer ? > Try mixmaster. I can not post the path for export reasons. Mail me if you want it. It runs on Sparc. Does not run on Linux and FreeBSD. All others unknown. -------------------------------------------------- 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/ Home of "chain" the remailer chaining script. 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

1 0