December 2003 - cypherpunks-legacy

MY FAUX PAS
by Sandy Sandfort 17 Dec '03

17 Dec '03

C'punks, It's great to see that Cypherpunks not only write code; they write jokes too (unfortunately at my expense). Thanks for all the humorous responses to my "who cypherpunks" message. God, I love this group. S a n d y

1 0

Re: e$: Geodesic Securities Markets
by f_griffith＠ccsvax.sfasu.edu 17 Dec '03

17 Dec '03

> >> Perry Metzger says, >> >Yup. The certificate is held in street name -- the name such >certificates are held in is "Ceed & Co." for obscure reasons I've >never been able to fathom. I think it's Cede & Co. The original reason, which may not still hold, was that it was rather cumbersome to transfer securities held in the name of a corporation, much easier to transfer those in a partnership's name. Thyus, the clearing corp formed a partnership to hold the securities.

1 0

PGP is Product of the Week
by Claborne, Chris at SanDiegoCA 17 Dec '03

17 Dec '03

PGP is Product of the Week in last weeks PCMag. I will bang my drum one more time... How to beat the three letter agencies: 1. Power of the press is just one of the weapons at our disposal. Public education and continued press on privacy alternatives is important. One of the things that would help a concerted offensive against the three letter agencies that want to remove our privacy would be to send more articles to the industry rags. Hopefully better than the one published in Byte. The more exposure the better. You there! Start writing! 2. Improve the ease-of-use factor for PGP... That is, write more front ends (windowing since most of the general public uses it). Example: ViaCryptPGP for Compuserve's WINCIM and navigator. I believe in the critical mass theory... "A product becomes a defacto standard not that it is always the best product but because of sheer number of users". In this case I am pushing PGP but I think it would go for crypto products in general. 3. Drive for an independent "renegade" standard like PGP. The term renegade here meaning "having rejected tradition". Flood the net with it and the genie is truly out of the bottle. Now that PGP is "legal" in the US, and people outside the U.S. have the product spec no-one gets left out in the cold. 4. Mentioned earlier... "Attack the NSA budget". This can be a win and a loose since a smaller budget could lower our countries defenses. It is possible that an attack on the budget would get them to lay off without any real action needing to be taken. ... __o .. -\<, chris.claborne(a)sandiegoca.ncr.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.

3 2

New at EFF - Intell. Cmte. HR3937 crypto report, Inouye NII bill
by Stanton McCandlish 17 Dec '03

17 Dec '03

Electronic Frontier Foundation ftp site: ftp.eff.org 06/23/94 - added House Intelligence Committee's enraging report on its so-called reasons for butchering the crypto export provisions of the Export Admin. legislation (HR3937/3627): /pub/EFF/Policy/ Crypto/ITAR_export/hr3937_intell_cmte.report - added Sen. Inouye's bill for "public spaces" on the NII: /pub/EFF/Policy/OP/inouye_nii_s2195.bill -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O

1 0

Hardware RNG's
by John A. Thomas 17 Dec '03

17 Dec '03

Roger, I would like some details about your hardware RNG, if you could, including how you were reading the random value. I had the impression you were taking one bit at a time. What did you mean when you said: "I just got a 3 standard deviation at a 1000000 sample..."? What statistical testing did you do? I used the chi-square test on 8-bit values (255 degrees of freedom), and also computed the probablility for the chi-square statistic. I programmed the runs-up and runs-down tests as suggested by Knuth, and computed the chi-square for those as well. Finally, I counted the numbers of 1 and 0 bits, and the number of times 1 followed 0, 0 followed 1, etc. I didn't do the autocorrelation test. If you have any code for that, I would appreciate having it. I'm not sure what you mean by "...the derevitives of the sequence..." What is that? I suppose these gadgets could be useful for those who want the absolute security of the one-time pad, and can exchange disks securely. With disks holding 1.44 meg now, it could be practical. John A. Thomas b858jt(a)utarlvm1.uta.edu 75236.3536(a)compuserve.com PGP public key available.

1 0

Get U.S. Representatives to use PGP?
by Jonathan Rochkind 17 Dec '03

17 Dec '03

I just saw a press release somewhere or other on the net which stated that a number of U.S. Representatives now have email addresses @hr.house.gov. Among other things, the release stated: > In addition, constituents who communicate with their > Representative by electronic mail should be aware that Members will > sometimes respond to their messages by way of the U.S. Postal Service. > This method of reply will help to ensure confidentiality, a concern > that is of upmost importance to the House of Representatives. What if we could get the Reps to use PGP to solve this problem? Sure, they _should_ be using clipper chip, to respect the Administration and all. But the fact is, they couldn't realistically use clipper now, even if they wanted to. No one else uses it. On the other hand, lots of people use PGP. PGP is fully legal now, so the Reps can use it if they want to. Maybe we should write up some form letter proseletyzing PGP and send it to all online Representatives? If we could get even one or two to use it, it would be major major pro-PGP publicity. It would also be a major embaressment to Clipper-supporters (ie. the Administration), but we definitely don't want to mention this in our form letter, as I doubt few Reps want to blatantly embaress the administration like that. But the fact is, PGP really _is_ a de facto standard, which is why teh Reps would use it instead of clipper, and furthermore if we can "trick" (maybe too harsh a word) a Rep or two into using it, it will just prove the standardness of PGP. What do you think? It looks like we'd have to snailmail the form letter to them all if we did it, as their email will only accept stuff from constituents who have pre-registered their email address by snailmail so as to prove their constituency.

1 0

Re: PGP is the product of the week!
by Jeff Gostin 17 Dec '03

17 Dec '03

"Claborne, Chris at SanDiegoCA" <claborne(a)microcosm.sandiegoca.NCR.COM> writes: > PGP is Product of the Week in last weeks PCMag. Good to hear it. Does this mean that PGP has become part of the Establishment? > 4. Mentioned earlier... "Attack the NSA budget". This can be a win and a > loose since a smaller budget could lower our countries defenses. It is > possible that an attack on the budget would get them to lay off without any > real action needing to be taken. This isn't truly an issue. The NSA had it's hey-day during the Cold War. Now that that's over, and the same level of effort can be attuned to fewer enemies, one would think that they don't NEED a bigger budget. --Jeff -- ====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ == == | The new, improved, environmentally safe, bigger, better,| == == -= | faster, hypo-allergenic, AND politically correct .sig. | ==== ====== | Now with a new fresh lemon scent! | PGP Key Available +---------------------------------------------------------+

1 0

WARNING!
by dcosenza＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I spoke with Phil Zimmermann today at some length, and he has informed me that users who decide to use the jumo keys generated by the hack of 2.6ui will be running a risk of incompatibility on down the line with future releases he has planned. You have been warned! Ever forward, David - -- - --------------------------------------------------------------------------- David Cosenza dcosenza(a)netcom.com PGP 2.3a Public Key available by finger _or_ ftp.netcom.com:/pub/dcosenza PGP 2.3a Key fingerprint = BF 6C AA 44 C6 CA 13 3F 4A EC 0A 90 AE F3 74 6D "When encryption is outlawed, only outlaws will have encryption." -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCzAgUBLgoyQCjdpAfJZzihAQGXhwTuO79ehD2s5q4c877Uc/+gt5ygytj2cmDD eUGhKGwqhGco9p/SC3FmtFltSvaTRuMP8GKBbQfXPnSQ4l1i2k11qvQObioKjq7p gGsb5CwyK47sVzPm/0WvAYcPc0wv1FHmZQOWLjiQEgjR9q3JHMSD0bDnV0zeoV3Q 6G02xeigDGCuGHQMBm4zT2n5ffldDTS0b2vn4AJZxNYPGoAH5nI= =G/aQ -----END PGP SIGNATURE-----

1 0

Digital Sigs?
by Cypher1＠aol.com 17 Dec '03

17 Dec '03

I read in yesterday's L.A. Times about something called CommerceNet, where sellers and buyers of workstation level equipment can meet and conduct busniess. Near the end of the article, they talked about a proposed method for exchanging "digital signatures" via Moasic (so that buyers and sellers could _know_ that they were who they said they were) and that they were going to "submit it to the Internet Standards body" Is this something new, or am I way gone on this one? Cyph1(a)aol.com

2 1

RE: Unofficial release
by nobody＠ds1.wu-wien.ac.at 17 Dec '03

17 Dec '03

++++++++++++++++++++++++++++++++++++ > Rumor has it that certain government applications do Diffie Hellman > with 2K-bit moduli. Given the apparent connections between factoring > and discrete logarithm (the complexity formulas seem to look very much > alike), it appears that at least one user feels that keys longer than > 1K bits provide a desirable safety margin. I'm still not sure that I understand the original argument against using keys that are "too long" by someone's standards. Nor am I sure the analogy holds up. It would be the security equivalent of saying that it's "paranoid" to put strong locks on your front door because your windows are made of glass, and are thus easier to break than the door. The fact is, most burglars would rather not break a window, if possible, because it's a glaring sign of forced entry visible even while they're in the process of burgling, it's noisy, and they could get cut, leaving blood samples behind and causing themselves pain. Sure, hypothetically, it might be "easier", in a given case, to monitor RF (Tempest) leakage vs. breaking a 1K+ key. OTOH, it would also require putting monitoring equipment at every Internet user's site vs. collecting and cracking keys at a centralized location. Of course, if someone wants to leave his front door unlocked for fear of being labelled "paranoid", that's his prerogative, I suppose. Just don't ridicule others who are more security conscious! +++++++++++++++++++++

2 1

Re: PGP is Product of the
by Duncan Frissell 17 Dec '03

17 Dec '03

To: cypherpunks(a)toad.com J >A person in the group to which I refer is ``in the US'' by the J >commonly understood geographical definition of that phrase, but has as J >a matter of conscience renounced any citizenship he may have had. He J >refuses on principle to affirm that he is a national person, and J >therefore cannot use PGP 2.6 because such affirmation is supposed to be J >required in order to obtain PGP 2.6, and may therefore be implicit in J >each use of PGP 2.6. On the other hand, if he uses PGP 2.6ui, he risks J >being accused of violating RSADSI's patent rights, because they will J >take him to be "in the US", even though he has disaffiliated himself. J >What version of PGP can such a person use? Even though your friend is no longer a U.S. Citizen he is a "legal resident of the U.S." in that he could not be deported. Residence is defined at law as equal to "domicile" and is under the legal control of the individual rather than the State. "Domicile" is defined as "Actual physical presence plus intent to make the place one's home." Once domicile is gained, it persists even if you are away until one acquires a new domicile by one's own action. So he could use the MIT version of PGP. When their lawyers came up with their spastic language about users having to be U.S. Citizens or Green Card holders they weren't trying to be exhaustive. They were clearly trying to mirror the ITAR crypto regs. Since your friend, while not a citizen, is not an alien he can possess crypto technology under ITAR and thus under the MIT license. DCF "If Nicole had had a Colt Mk IV Govt. Model, she'd be alive today." --- WinQwk 2.0b#1165

1 0

Re: RE: WARNING!
by usura＠vox.hacktic.nl 17 Dec '03

17 Dec '03

nobody(a)ds1.wu-wien.ac.at writes: >Just as an aside, can some of the PGP-aware-anon-remailer operators comment >on what they plan to do with respect to the various PGP versions? The remailers at vox.hacktic.nl are running PGP 2.6 ui. Regz, -- Exit! Stage Left. Alex de Joode <usura(a)vox.hacktic.nl>

1 0

Re: Cellular Telephone Experimenter's Kit (2600 article)
by pcw＠access.digex.net 17 Dec '03

17 Dec '03

>>This CTEK sounds like a fun toy and I guess I'm glad that it can't be >>used for cellular phone fraud. That would be an illegitimate use. But, >>monitoring cell phone traffic is a crime now, right? Is there a legitimate >>use for the device? Can anyone think of one? > >Several companies make cellular test sets (or optional modules for >more general purpose RF test sets) that perform functions very much >like those of the CTEK package. Since we manufacture cell phones, we >have a perfectly legitimate reason to have a few of those test sets >around here. And I know of no special licensing requirements to buy >them (other than having $20,000 or so in cash). Sure, I know that Qualcomm could easily justify having the toys around the place. But what would I say to the cops/FCC when they came knocking? I was just waiting to get the capital together to set up a phone manufacturing program? Is there any legitimate use for someone not in the business? The best I can come up with is: a wife who wants to track her husbands progress home so she knows when to throw the steaks on the grill. ("He always arrives 12 minutes after the he moves into our cell.") > >Phil

1 0

Re: PGP is the product of the week!
by pcw＠access.digex.net 17 Dec '03

17 Dec '03

>> 4. Mentioned earlier... "Attack the NSA budget". This can be a win and a >> loose since a smaller budget could lower our countries defenses. It is >> possible that an attack on the budget would get them to lay off without any >> real action needing to be taken. > This isn't truly an issue. The NSA had it's hey-day during the Cold >War. Now that that's over, and the same level of effort can be attuned to >fewer enemies, one would think that they don't NEED a bigger budget. "Fewer" enemies? Yugoslavia is now split into at least 5 pieces. Before we only needed to monitor the line from Moscow to Tito. All the orders came down this line and Yugoslavia did what they were told, more or less. No one in the US had to seriously wonder about the differences between Bosnia, Serbia, Croatia etc... We didn't need to monitor the different governments in the different regions. The ex-SU is now split into too many pieces for me to count. Some of them have nuclear weapons that they don't want to turn over. Others have military ships. Before, it was enought to have a good presence in Moscow. Now you need to be in Kiev, Lvov, Talinn, etc... North Korea, the Mid East and Cuba are the only places that still need the same amount of attention that they needed during the Cold War. This is because they're already maxed out. > > --Jeff >-- >====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ > == == | The new, improved, environmentally safe, bigger, better,| > == == -= | faster, hypo-allergenic, AND politically correct .sig. | >==== ====== | Now with a new fresh lemon scent! | >PGP Key Available +---------------------------------------------------------+

1 0

(None)
by Jeff Gostin 17 Dec '03

17 Dec '03

pcw(a)access.digex.net (Peter Wayner) writes: > "Fewer" enemies? I am of the opinion that most of the Post SU countries will amount to no serious threat. Remember, most of our problem was with Moscow. Most of the SU didn't especially care about us -- they were more concerned with eating dinner that night. As a result, yes, there are a few emerging hot spots, but they aren't _our_ enemies. The Bosnia deal is a local political problem. It is _not_ a threat to US security, much as Clinton would like us to think it is... ;-) > Croatia etc... We didn't need to monitor the different governments in the > different regions. True, but, most of that died. Yugoslavia, for example, is hardly a threat to us. Our problems in the past were mostly with Moscow. Most of the rest of the SU was not an issue. So yes, we have more governments to watch, but fewer enemies. > The ex-SU is now split into too many pieces for me to count. Some of them > have nuclear weapons that they don't want to turn over. Others have military > ships. Yes, they have Nukes. If I did, in their shoes, you're damn right I wouldn't want to give them up! Yes, they bear watching. Hell, even Israel, our military ally, bears watching. That doesn't mean they require the same level of surveillance. > North Korea, the Mid East and Cuba are the only places that still need the > same amount of attention that they needed during the Cold War. This is > because they're already maxed out. NK is a hot spot at the moment. Even if the C/W was still in effect and the SU still in force, NK would probably still be a problem now. The Middle Eastern area still requires a mind-boggling amount of watching. That situation is just too volatile not to watch it. However, I find it hard to buy into the fact that we're going to give 100% to Middle East, and the same 100% to Russia, who not only still can't feed it's people, but has SERIOUS financial problems. --Jeff -- ====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ == == | The new, improved, environmentally safe, bigger, better,| == == -= | faster, hypo-allergenic, AND politically correct .sig. | ==== ====== | Now with a new fresh lemon scent! | PGP Key Available +---------------------------------------------------------+ -- ====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ == == | The new, improved, environmentally safe, bigger, better,| == == -= | faster, hypo-allergenic, AND politically correct .sig. | ==== ====== | Now with a new fresh lemon scent! | PGP Key Available +---------------------------------------------------------+

1 0

remail@c2.org supports X-Anon-To and Request-Remailing-To
by sameer 17 Dec '03

17 Dec '03

I forgot when I moved the code over from remailer@soda over here to accept X-Anon-To: and Request-Remailing-To: I prefer Anon-Send-To: because it differentiates between Send and Post, such as with Anon-Post-To: Well here's a list of the commands remail(a)c2.org supports: Subject "remailer-info" pipe A instructions.pl X-Ping "--PING--" pipe A pinger.pl # anon block response header Response-Key "" pipe A reply.pl # remailing headers - non-anon Send-To "" pipe A send.pl # remailing headers - anon Anon-To "" pipe A anon-send.pl Request-Remailing-To "" pipe A anon-send.pl X-Anon-To "" pipe A anon-send.pl Anon-Send-To "" pipe A anon-send.pl # posting headers - not anon Post-To "" pipe A post.pl # posting headers - anon Anon-Post-To "" pipe A anon-post.pl Resp-To "" pipe A resp-send.pl Resp-Send-To "" pipe A resp-send.pl Resp-Post-To "" pipe A resp-post.pl Encrypted PGP pipe A pgpmail.pl # * "" pipe ? recurse.pl -- sameer Voice: 510-841-2014 Network Administrator Pager: 510-321-1014 Community ConneXion: The NEXUS-Berkeley Dialin: 510-841-0909 http://www.c2.org (or login as "guest") sameer(a)c2.org

1 0

Differences in key generation
by Matt Thomlinson 17 Dec '03

17 Dec '03

I've recently been asked if there are any differences in key generation techniques between US and non-US encryption programs. For that matter, are there any *basic* differences between foreign and domestic encryption algorithms? (IDEA, LUC, etc..?) I know the question is worded poorly; I'm wondering if there *is* a difference (I haven't ever assumed there was). This is very important and I need a response by midafternoon. :l matt (formerly phantom(a)u.washington.edu)

1 0

Re: WARNING!
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

mgream(a)acacia.itd.uts.edu.au (Matthew Gream) writes: >"ER CRAMER" wrote: >> But what are we talking about here. A 1024 bits >> key should be save for at least the next 10000 years so who cares if a 5000 >> bits key could be save for maybe a 1000000 years!!! After the RSA-129 factoring there was considerable discussion on sci.crypt about how much harder a 1024 bit key would be using current algorithms. There was some disagreement, but it did not seem that a 1024 bit key would be good for 10000 years; as I recall, the time scale was more like a few decades before it would fall to an attack as expensive as RSA-129. Larger keys with 2K bits, OTOH, were good for thousands or millions of years (of course it's hard to extrapolate computer power out that far). Does anyone have more precise numbers? >And if a near polynomial time method is developed for factoring or >breaking RSA (or any other PKCS you care to mention), super large keys >aren't going to matter a hoot. People have been talking as though the only possible improvements to factoring algorithms would be to jump to polynomial or near-polynomial time. Obviously it is equally possible that improvements will occur as they have in the past, reductions to the exponents or constant factors but still an exponential algorithm. In such a scenario it is very plausible that 1K bit keys would be unsafe while keys of a few K would be fine. Hal

1 0

Windows source for PGP
by peace＠BIX.com 17 Dec '03

17 Dec '03

Folks: I am looking for the source for a Windows front end for PGP. I know that WINFRONT is available (on special application) in source, but it's written in Visual Basic. I guess that I could get VB and learn it, but I was hoping that someone knew of a C version. It doesn't need to be particularly polished, since I will be making some changes to suit my own format. I know its a lot to ask, but I can hope, can't I. (The path name would help too.) Peace

1 0

difficulty of factoring / commerce net / etc
by Vincent.Cate＠FURMINT.NECTAR.CS.CMU.EDU 17 Dec '03

17 Dec '03

My mosaic page has pointers for these topics an many others: ftp://furmint.nectar.cs.cmu.edu/security/README.html For these two topics, there is a section on factoring and a pointer to http://www.commerce.net. I have added a lot since it first came out. It can really be used like a FAQ at this point. If you are looking for cypherpunks things, this is a good place to start. Please let me know if you know of any cypherpunk pages I am not yet pointing to. -- Vince

1 0

Secure Mosaic / Net surfing
by Vincent.Cate＠FURMINT.NECTAR.CS.CMU.EDU 17 Dec '03

17 Dec '03

I was surfing off the edges of my page and came across a page about secure http/mosaic. The page is: http://hoohoo.ncsa.uiuc.edu/docs/PEMPGP.html I include ASCII of this below. -- Vince 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 Authorization: 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

2 1

NIST responds to LEAF-blower
by paul＠hawksbill.sprintmrn.com 17 Dec '03

17 Dec '03

FYI - extracted from: RISKS-LIST: RISKS-FORUM Digest Friday 17 June 1994 Volume 16 : Issue 17 ------------------------------ Date: Thu, 16 Jun 1994 17:29:40 -0400 (EDT) From: ROBACK(a)ENH.NIST.GOV Subject: NIST Response to Blaze Attack on Clipper Note: The following material was released by NIST in response to recent articles regarding AT&T/Matt Blaze and the key escrow chip. A second more technical response follows. ------------------------- June 2, 1994 Contact: Anne Enright Shepherd (301) 975-4858 The draft paper by Matt Blaze* describes several techniques aimed at circumventing law enforcement access to key escrowed encryption products based on government-developed technologies. As Blaze himself points out, these techniques deal only with the law-enforcement feature, and in no way reduce the key escrow chips' inherent security and data privacy. -- "None of the methods given here permit an attacker to discover the contents of encrypted traffic or compromise the integrity of signed messages. Nothing here affects the strength of the system from the point of view of the communicating parties...." p. 7. Furthermore, Blaze notes that the techniques he is suggesting are of limited use in real-world voice applications. -- "28 minutes obviously adds too much latency to the setup time for real-time applications such as secure telephone calls." p. 7. -- "The techniques used to implement them do carry enough of a performance penalty, however, to limit their usefulness in real-time voice telephony, which is perhaps the government's richest source of wiretap- based intelligence." p. 8. Anyone interested in circumventing law enforcement access would most likely choose simpler alternatives (e.g., use other nonescrowed devices, or super encryption by a second device). More difficult and time-consuming efforts, like those discussed in the Blaze paper, merit continued government review -- but they are very unlikely to be employed in actual communications. All sound cryptographic designs and products consider trade-offs among design complexity, costs, time and risks. Voluntary key escrow technology is no exception. Government researchers recognized and accepted that the law enforcement access feature could be nullified, but only if the user was willing to invest substantial time and trouble, as the Blaze report points out. Clearly, the government's basic design objective for key escrow technology was met: to provide users with very secure communications that will still enable law enforcement agencies to benefit from lawfully authorized wiretaps. It is still the only such technology available today. Today, most Americans using telephones, fax machines, and cellular phones have minimal privacy protection. The key escrow technology -- which is available on a strictly voluntary basis to the private sector -- will provide the security and privacy that Americans want and need. * Statements from "Protocol Failure in the Escrowed Encryption Standard," May 20 draft report by Matt Blaze, AT&T Bell Laboratories ----- Note: The following provides additional technical material in response to questions regarding a recent paper by Matt Blaze on key escrow encryption. -------------------------------------- Technical Fact Sheet on Blaze Report and Key Escrow Encryption Several recent newspaper articles have brought attention to a report prepared by Dr. Matthew Blaze, a researcher at AT&T's Bell Labs. These articles characterize a particular finding in Blaze's report as a ~flaw~ in the U.S. government's key escrow encryption technology. None of the findings in Dr. Blaze's paper in any way undermines the security and privacy provided by the escrow encryption devices. The finding which has received the most publicity could allow a non-compliant or ~rogue~ application to send messages to compliant or ~non-rogue~ users which will not be accessible by law enforcement officials through the escrowed encryption standard field called the Law Enforcement Access Field (LEAF). Dr. Blaze's approach uses the openly disclosed fact that the LEAF contains 16-bit checkword to prevent rogue users from modifying the law enforcement access mechanism. This 16-bit checkword is part of the 128-bit LEAF, which also includes the enciphered traffic key and the unique chip identifier. Dr. Blaze's method is to randomly generate different 128-bit LEAFs until he gets one that passes the checkword. It will take on average 216, or 65,536 tries. This is not a formidable task; it could be done in less than an hour. Dr. Blaze questions the adequacy of a 16-bit checkword and suggests using a larger one, to ensure that the exhaustion attack would be so time consuming as to be impractical. The chip designers recognized the strengths and limitations of a 16-bit checkword. Following are the reasons why they chose to use a checkword of only 16 bits: * There were four fundamental considerations that the designers considered in choosing the LEAF parameters. These were: (1) ease of access by authorized law enforcement agencies, (2) impact on communications, (3) a sufficiently large identifier field which would not constrain manufacturers, and (4) the difficulty required to invalidate the LEAF mechanism by techniques such as those described by Dr. Blaze. * The purpose of the LEAF is to preserve law enforcement's ability to access communications in real-time. The encrypted traffic key, which enables them to do this, is 80 bits long. In addition to this 80-bit field, the LEAF must contain the unique identification number of the key escrow encryption chip doing the encryption. * The size of the identifier field was the subject of considerable deliberation. In the earliest considerations it was only 25 bits long. The chip designers recognized that 25 bits did not offer enough flexibility to provide for multiple manufacturers of key escrow devices. Different chip manufacturers would need manufacturer identifiers as well as their own chip identifiers to ensure that identifiers are unique. Eventually, the designers agreed that 32 bits would adequately meet this requirement. * In many environments, error-free delivery of data is not guaranteed, and there is considerable concern by communication engineers that requiring error-free transmission of a fixed field (the LEAF) could make the encryption device difficult to use. In early discussions with industry, they were opposed to any checkword. In the end, they agreed it would be acceptable if the size of the LEAF was restricted to 128 bits. This left 16 bits for a checkword to inhibit bypassing the LEAF. While recognizing the possibility of exhausting these 16 bits, the designers concluded that 16 bits are adequate for the first intended application. Security enhancements are being made for other applications, such as the TESSERA card. Note that computations are required to search for a matching checkword, which then has to be properly substituted into the communications protocol. The performance and cost penalties of the search operation are significant for telephone, radio, and other such applications, thus providing adequate protection against this technique for bypassing the LEAF. In summary: * Although this technique would allow one to bypass the LEAF, the security provided by the escrow encryption devices would not be altered. Users' information would still be protected by the full strength of the encryption algorithm. * Dr. Blaze was accurate in noting that these attacks are of limited effectiveness in real-time telephony. * When designing the key escrow chip, NSA emphasized sound security and privacy, along with user friendliness. The attacks described by Dr. Blaze were fully understood at the time of initial chip design. The use of 16 bits for the checkword was an appropriate choice in view of the constraints of a 128-bit LEAF. It provides excellent security for real-time telephone applications with high assurance that law enforcement's interests are protected. * Dr. Blaze's research was done using prototype TESSERA cards. As part of the family of planned releases/upgrades, NSA already has incorporated additional security safeguards into the production TESSERA cards to protect against the kinds of attacks described by Dr. Blaze. -------- end of article ---------------------- _______________________________________________________________________________ Paul Ferguson US Sprint Managed Network Engineering tel: 703.904.2437 Herndon, Virginia USA internet: paul(a)hawk.sprintmrn.com

1 0

PGP public key for soda.berkeley remailer?
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

Does somebody have the correct PGP public key for the remailer(a)soda.berkeley.edu remailer? Nothing I've sent there for posting has ever shown up, and I suspect I've got a bad key on my ring for them!

1 0

MacPGP2.6
by Joseph R. Rach 17 Dec '03

17 Dec '03

Hello, Does anyone know how to get MacPGP to sign with a different secret key then it's orginal one? I have two different keys in secring.pgp, but MacPGP refuses to accept the new one. I even made two seperate secret rings (one for each) and when I try the ring with the newer key in it, it tells me that it can't find my other key. This is fustrating for me. 2.3 lets me pick my key, and 2.6 will only let me use one. Anybody have a solution??? Thanks in advance. ps - I wish MIT had come out with a MacPGP2.5 release. ________________________________________________________________________________ Joseph R. Rach <r6788(a)hopi.dtcc.edu> Delaware Technical and Community College

1 0

Re: MacPGP2.6
by Jeffrey I. Schiller 17 Dec '03

17 Dec '03

Hmmm. I just tried and was unable to reproduce your problem. I created a secret keyring which contained two keys. MacPGP2.6 happily let me select either one. How did you wind up with two keys? Did MacPGP generate them both or did you import one (or both) of them? What actually happens when you attempt to use the one that MacPGP doesn't want to use? -Jeff P.S. We might want to move this conversation to pgp-bugs(a)mit.edu

2 1