December 2003 - cypherpunks-legacy

Re: sniff passwords on PC (DOS)
by pstemari＠erinet.com 17 Dec '03

17 Dec '03

At 01:00 AM 1/6/95 CST, m00012(a)KANGA.STCLOUD.MSUS.EDU wrote: > ... It does not work after starting windows. Not sure, but it seems obvious >that MS windows installs it's own keyboard interrupt. ... True, but it's fairly simple to write a program that loads itselfs in win.ini and also hooks the keyboard messages from Windows. --Paul J. Ste. Marie pstemari(a)well.sf.ca.us, pstemari(a)erinet.com

3 2

Re: public vs. private replies
by cactus＠seabsd.hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- In article <199501060807.DAA22166(a)bb.hks.net>, L. McCarthy <lmccarth(a)ducie.cs.umass.edu> wrote: >Tim May writes: >> In my opinion, having personal access >> to past posts is several orders of magnitude more important than >> having MIDI-MIME JPEG-II TeX players [...] > >It takes more disk space from one's personal quota, though (for those who >suffer under such restrictions). :[ All posts to cypherpunks since June '94 are available by ftp from ftp.hks.net:/cypherpunks/nntp/cypherpunks. They are also available via nntp from nntp.hks.net:hks.lists.cypherpunks. I'd be glad to put a search engine of some sort on them, either by Web or by mailserver, if someone can suggest a reasonable way to index the whole lot. - - -- Todd Masco | "life without caution/ the only worth living / love for a man/ cactus(a)hks.net | love for a woman/ love for the facts/ protectless" - A Rich Cactus' Homepage - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLw2LTRNhgovrPB7dAQEDNwP/QTydu0Tp68ytNupes18WU+uv159GJJfE Wy+3iLxj+9rbPJwEKBZlXqhkfV7pf4nK9wNwiwNR4ZF13zpCAljWPhw3BEgNM4Xj Ity2GWLb8s7PBMplc+ggTQ4LowMYGqoO/e1pBWH3joFCuv11owkf+ZmbvTSZgU7h l07wq41l2L0= =Ao+S - -----END PGP SIGNATURE----- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLw3GJCoZzwIn1bdtAQFdVAF8DB7xxjzPgHNj2Eil0zEuLKj8SofCLFAs HBdXBN2fFjT5mNwnKh5a4T1R1Dv0Zp/c =6bFr -----END PGP SIGNATURE-----

4 3

Remailer postage
by jpb＠gate.net 17 Dec '03

17 Dec '03

Russ, Where can I get the Magic Money software? I'm also interested in a combination FV/MM approach to anonymous postage. I'm still waiting to get my linux box set up (hassle with client paying the bill and all that fun stuff) but am considering starting a remailer once I get the site set up. I am concerned about the ethics of having a paymailer feed into the free remailer soup - how would their operators react if I'm effectively making money (no matter how little) off of them? In the interest of preserving anonymity, perhaps their should be a set postage rate - that way someone could use a digital stamp anywhere, helping to confuse the audit trail. I'm not sure if I want to get involved in the hassles of redemption though. It would probably become a major hassle for all the operators to have to do that much accounting on a regular basis. jpb(a)gate.net finger for pgp and ripem keys

5 6

Re: for-pay remailers and FV (Was Re: Remailer Abuse)
by Nathaniel Borenstein 17 Dec '03

17 Dec '03

Excerpts from fv: 6-Jan-95 for-pay remailers and FV (W.. jrochkin(a)cs.oberlin.edu (4416*) > Hmm. Maybe I don't completely understand how this is going to work, but > won't _every_ remailer in the chain need to know your FV billing account? > How would the rest of them charge via FV without knowing your billing > account? What Russell was suggesting (I think), was that only the first > would bill via FV directly, so only the first would need to know your > billing account, and then he'd settle up with the others at the end of the > month. (A particular variation of that scheme is what you mentioned later > in your message, and I'll get to that). The latter is what I was proposing. Only the first one would charge via FV, but the other ones would form a "closed system" that you could only get into by going through one that charged. > But assuming that every remailer along the chain _was_ charging via FV, I > fail to see how only the last one would need your billing account; seems to > me they all would, and thus any one could collude with FV to violate your > anonimity. That's not my assumption. I think you may have misread my mail -- I *agree* with you on this point. Sorry if I was unclear! > The > remailer operators still have to have an organization and remain in close > contact, which I am uncomfortable with because it seems to make collusion > more likely. As I said, it all depends on your level of paranoia.... I tend to think that in such an organization, where the primary "product" is privacy, each member would tend to watch all the other members like hawks, eager to publicize any instance of the other guy not being sufficiently zealous in protecting privacy. (Of course, I'm assuming that people like *you* will be running these services, i.e. people even more paranoid about privacy than me.) > And it's still dificult to intermix for-pay and free remailers > within your chain, or even just for-pay remailers from several different > consortiums. I think this is wrong. In my model, each consortium model has two, a for-pay and a for-free. Anyone can send to a for-pay, but only a consortium remailer can send to a for-free. Not that complicated, really. > [The > consortium, as far as I can tell, would also find it rather dificult to > charge more for a longer chain, I can't think of any way for them to charge > anything excpet a uniform amount regardless of length of chain, unless you > give the first remailer a way to tell the length of your chain, which is > undesirable. I'm not sure if this is a problem.] To my mind, that's not a bug, it's a feature. The consortium is charging you a set fee for privacy, and you get to decide how many hops are required to have a level of privacy you trust. > And this level of paranoia would be perfectly well surved by a Julf/penet > style remailer, which _would_ work well with an FV-payment system, as I > agreed before. The cypherpunks chained remailernet system as a whole is > overkill for your paranoia needs, but appearantly not for the needs of > those who use it over Julf's. It appears to me, that an FV-style payment > scheme can't be added to the cypherpunks chained remailer system without > dropping it's security to the level of Julf's. Which might be good enough > for you, but not good enough for me, or presumably for anyone else that > uses cypherpunks remailers. This is true of the scheme that I said I would be satisfied with (one remailer + FV), but not true, I think, of the "overkill" scheme, which was the consortium. > [Do you understand how cypherpunks remailers work, and the difference > between them and a julf/penet style remailer? Do you understand how > encryption is used in a cypherpunks-style remailer chain to make it so each > individual remailer only knows the next remailer along the chain, and not > the entire rest of the chain?] Well, I *think* I do, though I may be suffering from a bit of dilletantism here -- I'm certainly no expert in cryptography, but I think I understand the concepts involved. We haven't even gotten into the effect of encryption yet -- so far, we've just been talking, I thought, about untraceability. But as far as I can see, there's no reason that the consortium pay-only-at-entry scheme couldn't work with encrypted remailers. Am I confused? Couldn't you use the same cryptographic chain as is currently used, where all the inner entries in the chain are free crypto-remailers open only to other consortium remailers, but in which the outer encrypted message had the FV payment attached, which gained it entry to the remailer pool? > Try to bring up objections to a digicash-style system that are applicable > to remailers. I agree that they are different technologies that fill > different requirements, but it seems to me that the particular requirements > of a remailer system are only met by a digicash/magic money style > technology. Again, I think you mis-read me. I haven't (nor do I care to) spent a lot of time thinking about how to do remailers at all, let alone with digicash. What I was referring to was the basic objections that come from using a digital cash scheme in the first place. > I think an electronic cash system that will work with remailers, must > satisfy these things: > 1) You need to be able to enclose the "signifyer" of the transaction inside > encryption. Whether the "signifyer" is the cash itself, or an agreement to > make a transaction together with a billing number, or whatever, you need to > be able to enclose it in a PGP (or other arbitrary PKE protocol) encrypted > block. > 2) The "signifyer" of the transaction (which again might theoretically be > the cash itself, or some kind of billing number) alone shouldn't be enough > to reveal the identity of the anonymous user. I agree that FV doesn't meet the above requirements, but I don't see why they're necessary for remailers. In the consortium scheme I'd proposed, the only thing that could ever be proven about you would be that you had used a remailer. Now, if the message was not encrypted, your anonymity could be broken by collusion of FV and the "entry" remailer. But if the cypherpunks style cryptographic chain was used, i.e. if the contents (including an inner envelope that said who you really sent it to) were encrypted, nothing more would ever be derivable without the collusion of everyone in the chain, and even then it would only be derivable if certain records were kept. All I'm claiming is that it's do-able using the FV payment system. I'm not going to do it myself because I don't personally feel that this level of untraceability is EVER legitimately necessary..... -- Nathaniel

6 6

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: 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