December 2003 - cypherpunks-legacy

HTTP 1.1 and Mosaic 2.2 support PEM/PGP authentication
by remailer＠merde.dis.org 17 Dec '03

17 Dec '03

FLASH: HTTP 1.1 and Mosaic 2.2 support PEM/PGP Authentication Mosaic Pages for http 1.1 for PEM/PGP auth http://hoohoo.ncsa.uiuc.edu/docs/ Using PGP/PEM encryption This document is formatted roughly like a FAQ. Here are the section headings: What is PGP/PEM encryption? How are they used in HTTP? What do I need to use it? How do the keys get distributed? How bulletproof is it? Installation: server side. Installation: client side. What does the protocol look like? What is PGP/PEM encryption? PGP and PEM are programs to allow you and a second party to communicate in a way which does not allow third parties to read them, and which certify that the person who sent the message is really who they claim they are. PGP and PEM both use RSA encryption. The U.S. government has strict export controls over foreign use of this technology, so people outside the U.S. may have a difficult time finding programs which perform the encryption. How are they used in HTTP? We have implemented a system by which NCSA Mosaic and NCSA httpd call external programs which encrypt and decrypt their communications and thus provide secure communications between the server and the client and ensure that a user is who he/she says they are. This system currently has hooks for PEM encryption as well as PGP encryption. As interest in this area grows, more will most likely be added. What do I need to use it? You will need a working copy of either Pretty Good Privacy or RIPEM to begin with. You should be familiar with the program and have generated your own public/private key pair. You should be able to use the TIS/PEM program with the PEM authorization type. I haven't tried it. This tutorial is written assuming that you are using RIPEM. How do the keys get distributed? Currently, we have implemented this protocol with PEM and PGP using local key files on the server side, and on the client side with PEM using finger to retrieve the server's public key. As you can tell, parties who wish to use Mosaic and httpd with PEM or PGP encryption will need to communicate beforehand and find a tamper-proof way to exchange their public keys. How bulletproof is it? Pioneers get shot full of arrows. This work is currently in the experimental stages and thus may have some problems that I have overlooked. There aren't any that I can see but I've been looking at it for a long time. There may be some quirks in the additions to Mosaic and httpd as well. In particular, error recovery is not always as helpful as it could be. The only known problem that I know about is that the messages are currently not timestamped. This means that a malicious user could record your encrypted message with a packet sniffer and repeat it back to the server ad nauseum. Although they would not be able to read the reply, if the request was something you were being charged for, you may have a large bill to pay by the time they're through. Installation: The Server Side First, you must compile httpd with CFLAGS set to -DPEM_AUTH. This will enable the PEM and PGP authentication directives. Next, look in the support/auth directory. This directory contains your encryption and decryption scripts, as well as bins for your remote users' public keys. Edit ripem-dec, ripem-enc, pgp-enc, and pgp-dec and follow the instructions therein. You need not set up PGP if you don't plan to use it, and same with RIPEM. Now, edit your server configuration file, usually conf/httpd.conf. You will want to add three new directives for PGP and three new directives for PEM depending on which you plan to use (or both). PEMEncryptCmd /usr/local/etc/httpd/auth/ripem-enc PGPEncryptCmd /usr/local/etc/httpd/auth/pgp-enc These directives change what executables httpd will look for when it is trying to encrypt its reply to a client. Edit the pathnames to taste. PEMDecryptCmd /usr/local/etc/httpd/auth/ripem-dec PGPDecryptCmd /usr/local/etc/httpd/auth/pgp-dec These directives change what executables httpd will look for when it is trying to decrypt the client's request. PEMServerEntity webmaster(a)foobar.org PGPServerEntity webmaster(a)foobar.org These directives set your entity name. This should be the same as the name you place on the public/private keys you generate for your server. If you make these directives different than the key names, your server and its client will become hopelessly confused. You are now ready to protect directories of your server with this authorization scheme. For a directory you want to protect, you should first set its AuthType. Use AuthType PGP for a directory you are protecting with PGP and AuthType PEM for a directory you are protecting with PEM. The require directive accepts key names as its arguments. The AuthGroupFile directive is valid as well, to create groups of keys. A full example: AuthType PEM AuthGroupFile /httpd/.htgroup-pem Options None <Limit GET> require user robm(a)ncsa.uiuc.edu require group pemusers Let's say /httpd/.htgroup-pem reads: pemusers: pls(a)ncsa.uiuc.edu In this case, this directory will be protected with PEM encryption and will require that only users robm(a)ncsa.uiuc.edu and pls(a)ncsa.uiuc.edu be allowed to access that directory. Installation: the Client Side First, get a copy of Mosaic/X 2.2. If it hasn't been released yet, be patient. Compile it with -DPEM_AUTH to enable PEM/PGP authentication. Follow the instructions in each of the scripts in the auth subdirectory to customize them to your setup. There are six new X resources which have been defined for PEM/PGP authentication. They are: Mosaic*pemEncrypt: /X11/robm/Mosaic/auth/ripem-enc Mosaic*pemDecrypt: /X11/robm/Mosaic/auth/ripem-dec Mosaic*pemEntity: robm(a)ncsa.uiuc.edu Mosaic*pgpEncrypt: /X11/robm/Mosaic/auth/pgp-enc Mosaic*pgpDecrypt: /X11/robm/Mosaic/auth/pgp-dec Mosaic*pgpEntity: robm(a)ncsa.uiuc.edu You should change the Encrypt and Decrypt entries to reflect where you are going to install your encryption and decryption crypts. You should change the Entity lines to the key name you have given the server maintainers for yourself. If you don't, bad things will happen. What does the protocol look like? This protocol is almost word-for-word a copy of Tony Sander's RIPEM based scheme, generalized a little. Below, wherever you see PEM you can replace it with PGP and get the same thing. Client: GET /docs/protected.html HTTP/1.0 UserAgent: Mosaic/X 2.2 Server: HTTP/1.0 401 Unauthorized WWW-Authenticate: PEM entity="webmaster(a)hoohoo.ncsa.uiuc.edu" Server: NCSA/1.1 Client: GET / HTTP/1.0 Authorized: PEM entity="robm(a)ncsa.uiuc.edu" Content-type: application/x-www-pem-request --- BEGIN PRIVACY-ENHANCED MESSAGE --- this is the real request, encrypted --- END PRIVACY-ENHANCED MESSAGE --- Server: HTTP/1.0 200 OK Content-type: application/x-www-pem-reply --- BEGIN PRIVACY-ENHANCED MESSAGE --- this is the real reply, encrypted --- END PRIVACY-ENHANCED MESSAGE --- That's it. Almost all of this stuff is my fault (including the implementations), so direct comments about it to me. Rob McCool, robm(a)ncsa.uiuc.edu

1 0

Digital Cash....
by Jim choate 17 Dec '03

17 Dec '03

Has anyone looked at basing digi-cash on the processing power required to handle it? In other words, instead of basing it on real cash directly or simply setting up a 'flat' standard (is there an accepted technical term for this?) base it on the MIPS that are required to process it in a given time (say 1mS)? Seems to me that this would provide a standard that was universal and verifiable by any organization that chose to spend the effort to do it. It would also add another layer of isolation (since the only person (sic) involved w/ real cash is going to the be processing sight paying their electric bill).

1 0

Re: REMAIL: Cover traffic
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hal <hfinney(a)shell.portal.com> writes: (lots of neato diagrams...) Your diagrams do ignore the idea that the noise sources and bit-buckets can be the same addresses, so that real traffic between the noise sources is completely masked. The value of this depends on the number of noise sources. >So, since the eavesdropper must monitor the whole network in order to >follow messages even without cover traffic, I think it is fair to >point out that adding cover traffic doesn't help much against an >eavesdropper who can monitor the whole network. Not to put too fine a point on it, but what about the possibility of unscrupulous remailer operators with incomplete knowledge? You want to be protected on that all-important first hop. My guess is that most messages sent thru remailers end up *posted* someplace, like here or Usenet (or every mailing list in the country :). With low traffic volumes, a mailer operator can see a rant show up on CPs, check his mail logs, and say "hmm, <screwball(a)undergrad.frat> just used me for his first hop", and actually have a reasonable probability that the two are connected. However, a bunch of people with gongs and whistles making noise in the operator's ear will make this nearly impossible. >The real solution, as suggested by the diagrams, is to have a large >volume of true remailed messages in the network - messages which go to >a wide variety of people. Individual users can protect themselves to >some extent by serving as cover-traffic generators and bit-bucket >receivers; but this does not protect other users who are not able to >perform these functions. Right! People who want more security will generate lots of noise. People who don't use remailers at all can generate lots of noise. The bottom line being that generating noise increases your security as an individual a great deal and helps everybody else to boot. In theory you're completely right Hal, but in practice I think there's more to it. faust's dog -----BEGIN PGP SIGNATURE----- Version: 2.3a iQBpAgUBLUkzRop26HwU0zr9AQG0qQKaAqyH8v1j5g9wEbkBA8zNHThwtjAeQz57 VmnwC0+8cgB8K6Uol7FmkcFIU+lEwtXHb9FXXWOaxpNA2BTYKfzvDHxCt+fEFoCl T5aQ3oyvltuSqAL8 =dZTy -----END PGP SIGNATURE-----

1 0

Re: Quantum cryptography
by Duncan Frissell 17 Dec '03

17 Dec '03

To: cypherpunks(a)toad.com W>Joi, NO. :-) I know there's been a Scientific American article on it W>within the past few years that might have more technically-detailed W>references. That would be: Citation: Scientific American, Oct 1992 v267 n4 p50(8) -------------------------------------------------------------------------- Title: Quantum cryptography. (unbreakable message transmission system) (includes related articles) Authors: Bennett, Charles H.; Brassard, Gilles; Ekert, Artur K. -------------------------------------------------------------------------- Subjects: Quantum theory_Usage Cryptography_Innovations Reference #: A12677141 ========================================================================== Abstract: Quantum techniques have been used to develop a system that allows two parties to exchange information in absolute secrecy. Quantum cryptographic devices use individual photons of light and Heisenberg's uncertainty principle. Eavesdropping causes a disturbance that alerts the legitimate parties. ========================================================================== Full Text COPYRIGHT Scientific American Inc. 1992 DCF Who has an ASCII copy if ayone wants one. --- WinQwk 2.0b#1165

2 1

Re: Quantum cryptography
by walter kehowski 17 Dec '03

17 Dec '03

> jito(a)netcom.com > Does anyone know how quantum cryptography works? > > - Joi Joi, NO. :-) I know there's been a Scientific American article on it within the past few years that might have more technically-detailed references. Naively, the idea is that any interference with the message can be detected because of the subtleties of QM measurement theory. It's theoretically possible but it's not something anybody'll be implementing anytime soon. Stick with PGP for now. See ya, Walter A. Kehowski <wak(a)next0.math.pitt.edu>

2 1

hh@cicada.berkeley.edu is back.
by nobody＠soda.berkeley.edu 17 Dec '03

17 Dec '03

Well... Still no answer about which remailers to use, so I'm inadvertantly testing them myself. I'm not sure if I had anything to do with it but hh(a)cicada.berkeley.edu stopped responding last night but is back this morning. I finally got back the mail at least (a good thing). Here is the error. So I'd rate hh(a)cicada.berkeley.edu to be a MacPlus after all? Tread lightly on this remailer? >From MAILER-DAEMON(a)cicada.berkeley.edu [date] Received: from cicada.Berkeley.EDU by [mysite] Received: from [mysite] by cicada.berkeley.edu From: MAILER-DAEMON(a)cicada.berkeley.edu (Mail Delivery Subsystem) Subject: Returned mail: Unknown mailer error -1 Message-Id: <[number](a)cicada.berkeley.edu> To: <[Myaddress> Status: R --- The transcript of the session follows --- 451 sendmail: 0832-054 Cannot create a process: There is not enough memory available now. 554 "|//home/hh/remail/slocal.pl"... Unknown mailer error -1 --- The unsent message follows --- From: [me] Message-Id: <[number]@[mysite]> To: hh(a)cicada.berkeley.edu Subject: Test hh@cicada :: Request-Remailing-To:[myaddress] Ping! -----Begin Test----- Test -----End Test----- -Xenon

1 0

Re: Quantum cryptography
by jito＠netcom.com 17 Dec '03

17 Dec '03

I'm taking the liberty of forwarding this note here because email to jdblair(a)rogue.cas.muohio.EDU bounces so I couldn't thank John or ask for permission. It was the only reply I got, but I think it is really interesting so... - Joi >From: jdblair(a)rogue.cas.muohio.EDU (John Blair) >Message-Id: <9401280824.AA08537@ rogue > >Subject: Re: Quantum cryptography >To: jito(a)netcom.com (Joichi Ito) >Date: Fri, 28 Jan 1994 03:24:41 -0500 (EST) >In-Reply-To: <9401280501.AA02095(a)iikk.inter.net> from "Joichi Ito" at Jan 28, >94 02:00:22 pm >X-Comment: The enlightened man is one with the subject. -Mumon >X-Mailer: ELM [version 2.4 PL21] >Mime-Version: 1.0 >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit >Content-Length: 3259 > >> >> Does anyone know how quantum cryptography works? >> >> - Joi >> >> >> -- >> true name: <Joichi Ito> >> closest email address: <jito(a)netcom.com> >> closest fax number: <+81-3-5454-7218> >> current physical location: <Tokyo> >> travel path: <.> >> mosaic home page: http://iikk.inter.net/ >> -- >> finger jito(a)netcom.com for PGP Public Key, RIPEM Public Key >> -- >> > >Joi, > >Chances are you're recieving a lot of answers to this, but here's one anyways. > >This comes from: Schneier, Bruce, _Applied Cryptography_, pp 408-410, >John Wiley & Sons, Inc, New York. pp 408-410 > >Quantum cryptography relies on the property that one cannot know the >position and the velocity of a particle at the same time to prevent >evesdropping. Any evesdropper will neccessarily disturb the message in a >detectable way. Experimental quatum cryptography relies on polarized light. > >If a pulse of horizontally polarized photons is sent through a >horizontally polarized filter, 100% of the light gets through. Pass it >through a filter 45 degrees off, and each partical has a 50% chance of >making it through, and no chance of making it through a filter 90 degrees off. > >1) Alice sends Bob a string of photon pulses. Each of the pulses is >randomly polarized in one of four directions: horizontal, vertical, >left-diagonal, and right-diagonal. > >For example, Alice sends Bob: ||/--\-|-/ > >2) Bob has a polarization detector. He can set his detector to measure >horizontal and vertical polarization, or he can set his detector to >measure diagonal polarization. He can't do both; quantum mechanics won't >let him. Measuring one destroys any possibility of measuring the other. >So, he sets his detectosr at random, for example: x++xxx+x++ > >When Bob sets the detector correctly, he records the correct answer. The >rest of the time, he gets a random result. Say he gets: ||/--\-|-/ > >3) Bob, over an insecure channel, tells Alice what settings he used. > >4) Alice tells Bob which settings were correct. In this example, 2,6,7,9. > >5) Alice and Bob keep only those settings that were correct. In this >example, they keep: *|***\-*-* > >According to a pre-arranged code, such as 1 = horizontal and >left-diagonal, and 0 = vertical and right-diagonal, they have sent the >bits: 0011 > >Alice will need to send 2n pulses for every bit transmitted, since Bob >will be correct 50% of the time, on the average. These bits can be taken >as the key to a conventional algorithm, or enough can be sent to generate >a one-time pad. > >6) Alice and Bob compare a few bits in their strings. If there are >discrepancies, they know they are being bugged. If there are none, they >discard the bits they used for comparison and use the rest. > > >For a good overview (according to Schneier) see: > >C. H. Bennet, G. Brassard, and N. D. Mermin, "Quantum Cryptography," >Scientific American, v. 68, n. 5, 3 Feb 1992, pp. 557-559 > >C. Zimmer, "Perfect Gibberish," Discover, v. 13, n. 12, Dec 1992, pp. 92-99. > > >Schneier says British Telecom has used this system to send bits over a 10km >fiber-optic link. > >see: >W. Brown, "A Quantum Leap in Secret Communications," New Scientist, n. >1585, 30 Jan 1993, p. 21. > > >Hope this made sense. Its really quite amazing to think about. >-john. > > -- true name: <Joichi Ito> closest email address: <jito(a)netcom.com> closest fax number: <+81-3-5454-7218> current physical location: <Tokyo> travel path: <.> mosaic home page: http://iikk.inter.net/ -- finger jito(a)netcom.com for PGP Public Key, RIPEM Public Key --

1 0

META: request
by Karl Lui Barrus 17 Dec '03

17 Dec '03

Hm... I have a request: (There was a security incident here at Rice; owlnet has been disconnected from internet for about 2 weeks and I think quite of bit of mail has spilled. Email has supposedly been restored, but that's it so far, and given the number of "fork: no more processes" errors I'm getting I think it'll be a bit longer...) Can anybody send me the original "Remailer Noise Traffic" or "REMAIL: Noise Cover" messages? I'd like to read them and include them at the gopher site (when I can actually telnet/ftp over there :-). I only have 20 messages from the list since the 23rd. Thanks! -- Karl L. Barrus: klbarrus(a)owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories

1 0

No Subject
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

Newsgroups: talk.politics.crypto,comp.org.eff.talk Subject: Re: NSA'S TESSERA PLAN (NYT/MARKOFF) Summary: Expires: References: <145309Z26011994(a)anon.penet.fi> <2i6g3n$ct4(a)crchh327.bnr.ca> <nagleCKBv5y.34s(a)netcom.com> Sender: Followup-To: Distribution: Organization: Loral Rolm Computer Systems Keywords: >From: nagle(a)netcom.com (John Nagle) > I'm not too worried. Clipper has been a total bomb in the marketplace. >Communications Week reports that no real Clipper products have actually been >announced. AT&T has announced non-Clipper crypto products since the >Clipper announcement. Supposedly, AT&T is going to have a Clipper product, >because NSA/DOJ ordered some, but that's just a Government procurement. 28 Jan 94, 11:55 PST I just talked to someone at AT&T Surety Systems. The TSD-3600c (the one with the clipper chip) will be available next week. The person I talked to would not elaborate as to the present backlog, but said it "wasn't just one or two". I asked if the backlog was related to orders for the Department of Justice (DOJ), and was told that availability next week was in addition to those "set aside" for delivery to DOJ. (I didn't think to ask about a DOJ delivery schedule.) If I hadn't just spent the money on fencing for corrals and paddocks, I'd order a couple to play with. Maybe I have room on a credit card...

1 0

Random remailing script had. Help.
by nobody＠soda.berkeley.edu 17 Dec '03

17 Dec '03

Thanks to Alan Barrett who sent me a script to get me started with. I have two questions still. 1) Why not just $second = rand ($#remailers+1), instead of the two line $second routine? (And why did I have to add the +1...). 2) How do I output the variables as csh environmental variables that stick around after the perl script has executed? I usually use 'setenv' but perl didn't like that. Here is Alan's script, edited a bit by me: #!/usr/bin/perl # given a set of remailers, choose two of them at random. # repeat this operation five times. # output the resulting list of 10 remailers. # # here's the list of remailers to be considered. # make it as long or as short as you like. (but no shorter than 2 entries!) # @remailers = ("One", "Two", "Three", "Four" , "Five", "Six"); # # seed the random number generator. # this is not a strong PRNG! # srand(time); foreach $cycle (1..5) { # choose random remailers $first = rand($#remailers+1); $second = rand($#remailers); $second++ if $second >= $first; # output the choices print $remailers[$first],"->",$remailers[$second],"\n"; } And a few outputs: Four->One One->Six One->Six Five->Three Four->Two One->Four One->Five Six->Four Five->Two One->Six Five->Two Two->Five Five->Three Five->Four Five->Five I may have screwed it up, as Alan originally had no +1 in the $first line, and had -1 in the next line, but it never outputed "Six" then. Background: One-Six will be addresses of Cypherpunk remailers and I am sending packages of five e-mails (~40K each) to many people a day. I figured why not appease you guys by helping with the traffic, but do it randomly and chain off two remailers per e-mail. I want csh variables though, as output. How do I get these, or how to I fetch the perl variables for a Unix command line (I am currently using 'setenv name value' then putting $name into a Unix command)? -Xenon P.S. If you wish to e-mail answers (slow!) use na38138(a)anon.penet.fi.

2 1