December 2003 - cypherpunks-legacy

Re: Reefer madness
by Blanc Weber 17 Dec '03

17 Dec '03

From: Sandy Sandfort Ever seen a Turkish prison film, Reuben? ......................................................... I don't get it. (I haven't seen one) Blanc

3 2

Re: Multiple symetric cyphers
by pdlamb＠iquest.com 17 Dec '03

17 Dec '03

>In article <199501120502.VAA29808(a)largo.remailer.net>, >Eric Hughes <eric(a)remailer.net> wrote: >> From: cactus(a)seabsd.hks.net (L. Todd Masco) (bunch of stuff deleted) >> I guess this reduces to: do strong cyphers have "signatures" of some sort, >> by which the type of encryption can be derived? >> >>If they do, they're likely not _strong_ ciphers. > >Great... that's the answer I was looking for, and what my gut feeling >was. I'm trying to determine how much rope is too much for a first pass. > >Related: is there, in general or in any known specific cases, any loss of >security in using sym. cipher A on ciphertext B (of another sym. cipher) with >the same key? With different keys (I would think not, but I vaguely >remember mention of something here long ago)? Is this asking the question, "Does DES form a group with IDEA?" (Substitute your favorite cipher.) Since it took about 15 years to figure out DES is _not_ a group, I suspect it will take a long time to figure out the answer to that question for each pair of ciphers you're going to substitute. Seems to me it's a good basic idea. If it costs, for example, a million bucks to crack a cipher; you have three ciphers that can be used; then the best-case cost to crack a message just tripled! Of course, if you choose two ciphers stronger than DES, it probably went up a little more (g). If the ciphers don't form a group, you just made your system unbreakable. Just use two ciphers. Then a brute-force attacker has to check each key for each cipher once when it is applied first, and once for each of the possible keys for the other cipher when it is applied second! Sounds too good to be true. Am I missing something? Pat

1 0

Re: How do I know if its encrypted?
by daleh＠ix.netcom.com 17 Dec '03

17 Dec '03

You wrote: >You don't always need the correct answer. You just need the correct >answer most of the time. You're trying to create a presumption about >behavior. Ensuring that you can't read almost all of the traffic is a >pretty good way to assure people that you don't try to make sense of >any of it. I'm still not making my point. Encryption is not a data 'state' that can be tested for in the way that liquid/solid/vapour are states of matter. Encryption is a data 'interpretation' for which there are an arbitrairly large number of interpretations available for any given dataset. There is no algorithmic test that can applied to a dataset that will be able to establish the existance or non-existance of a given interpretation. If you're given an unkown dataset and are asked the question, 'Is this an image file' or 'Is this an encrypted file' or 'Is this an audio clip', there is no algorithmic test that can answer any of these questions in either the affermative or the negative. This is just an alternate phrasing of Goedel's Undecidability Theorem. This problem lies permanantly outside the outer boundary of algorithmic capability. Let me now spin a little tale as to how this affects an operator of a re-mailer or datahaven. This tale has two characters, Paco the child pornogropher and Eric the honest RM/DH operater. Paco begins by inventing the new 'Foolproof Barometric Graphic Image Format' (aka FooBar GIF) of which only Paco knows the internals. A FooBar GIF has a statistical profile that looks remarkably like a PGP file, in fact it even comes with a PGP header! Nothing illegal here. Now Paco writes a FooBar GIF Viewer which he sales to child-porn types. Again, there's nothing illegal about the sale of such a piece of software. Paco now anonymously loads Eric's DH with lots of child-porn FooBar GIF's via Eric's anon-RM. These files of course sail right through Eric's filters with nary a scratch. As far as Eric knows he's holding PGP encrypt files. Now Paco advertises the availability of lots of 'good' picture on Eric's DH that can be used with the newly purchased FooBar GIF Viewers. Then the cops get ahold of one of Paco's FooBar GIF Viewers and downloads some FooBar GIFs from Eric's DH and the last words we ever hear from Eric are "I swear I thought they were PGP files, I swear to God I thought they were....." as the authorities drag his carcass off to jail. Whose going to believe Eric's protests of innocence? "After all", says the prosecutor to the jury, "wasn't Eric explicitly filtering out what he didn't want in. If fact", says the prosecutor, "his filter seems to have been designed specifically to allow these kiddie-porn files in and to reject all others." A sad end indeed! Dale H.

2 1

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

Re: Microsoft TrueName (tm) (fwd)
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 11:23 AM 1/12/95, NetSurfer wrote: >I wondered why one of the few registered hosts for Microsoft were called >"Bob" - now it makes sense. (But they've got a good sized chunk of >netblks registered...) Funny thing happened to me last night. I was talking to a guy who had seen Fidelity's new WWW server (shhh! don't tell!) and it turns out he was the guy who actually *had* bob.com. A third party approached him and asked him if he wanted to sell the domain name. He did. He picked another domain name, and last week someone called him if he wanted to sell his *new* domain name. He said no, and they asked him if he would *rent* it to them... Go figure. Cheers, Bob Hettinga Eric, what'll you take for "remailer.net"? ;-). ----------------- 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

2 1

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

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