- cypherpunks-legacy - lists.cpunks.org

Re: Documentation
by Charlie Root 17 Dec '03

17 Dec '03

> >In the coming weekend, I'll be updating the newuser FAQ > >(for things like PPP and 2.2). I'm sure a post-install checklist would be > >a welcome addition. > > > >B U T . . . . > > > >Not everyone runs things like Kerberos or DNS. Keep in mind that many > >people use OpenBSD for many things and in many environs. The OpenBSD setup > >on my firewall at the office is much different than the Sparc, Alpha, and > >P5/133 I run it on at home. The setup on my router machine at home is also > >much different than the other machines in my house. There are ways people > >have setup OpenBSD on embeded systems to do things like manage the > >fuel/air mix ratio on their Corvettes (OK, one person I know of planned > >that, but couldn't get the financing for the car...) I hope that draws the > >picture. > > > >As for the verification after install, that is sort of "auto-manditory"-- > >if a filesystem isn't mounted right, /etc/fstab has to be checked out. If > >the network doesn't work, the network files must be examined to "make it > >go." As oopposed to attacking this as a checklist, how about it is > >attacked as "If networking doesn't work, check hostname.(interface)"-- but > >there is more to that then just files in /etc (boot -c in order to > >reconfigure hardware addresses) > > As a user of OpenBSD, and having tried to manage projects with it for > implementation of added features for customers...I could not agree with > the above position. > > You see, if you are ALREADY familiar with OpenBSD then you will most likely > know exactly what to do when installing and seting up a system. New User's > Notes / Installation Checklist's will most likely be ignored by you. > > However, if you are brand new to the system, then an Installation / Setup > Checklist (a good one) will prove to be essential. Wouldn't it be great if > just about every post to these groups from a new user was one like "..hey! > This OpenBSD thingy works great! The installation was a snap!.." or something > like that. We all know that hardly happens now...but, it could..... > > I, for one, believe strongly that a good 'Overview', 'Setup Notes' and 'Installation > Checklist' must somehow find it's way into the distribution. It is also clear > that the machine / arch specific differences will require unique versions > for each. I completly agree with you. Just anoze topic that i can add is installation procedure,especially disk partitoning. It's a very dungerous/important procedure but it's description ins INSTALL.i386 is a bit too short and need examples(espcially). Something like - "Imagine we have disk with such and such patitions and now we want to install OpenBSD here & there so we should... It would'be _very_ helpfull. BTW, does anybody work on installation software ? Something like in FreeBSD/RedHat ? Alexey Pialkin

1 0

finger
by Harry Hansen 17 Dec '03

17 Dec '03

______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Re: what can we do about PGP sell out and CMR?
by Anonymous 17 Dec '03

17 Dec '03

You've got a lot of nerve accusing PGP, Inc. of being "sellouts" when you're over on open-pgp pushing KEY ESCROW, of all things. I can see it now, the new product name, "PGP with Key Escrow". Motto: "Lose your key? Don't worry, we've got a copy." Do you really think cypherpunks are going to support key escrow? Fat chance.

2 1

Re: Security flaws introduced by "other readers" in CMR
by Anonymous 17 Dec '03

17 Dec '03

Let's look a little closer at the kinds of access and notice available in the PGP system compared to alternatives. As several people have pointed out, no encryption system can provide protection against what is done with the message after it is decrypted. The receiver could share it with whoever he wants to, or whoever he is forced to. Consider the following scenarios: - An encrypted message is sent to someone at his workplace using current systems like PGP 2.6. - An encrypted message is sent to someone at his workplace, who is using the message access features of PGP 5.5. The corporation key is marked as "optional", and the message is not encrypted to that extra key. - An encrypted message is sent as before, but this time the message is encrypted to the corporate key. - An encrypted message is sent to someone at his workplace, who is using a different form of corporate access which relies on key escrow or automatic acquisition of cleartext. We agree that none of these systems can provide complete protection against third party access. In any of them, the receiver could be forced to turn over the encrypted message. But there is still a difference. In the first two scenarios, the expectation of privacy is the same. You are encrypting to a personal key at a business address, but you expect that you would know about it if the data were being provided to a third party. There is no widespread installed base of software which provides secret access after the message is decrypted. In fact, the second scenario arguably provides slightly more privacy than the first, which is what we have now. The reason is that in the second scenario, the company provides an optional mechanism for business mail to be recoverable, but also provides an explicit, sender-controlled escape clause. The company is granting an explicit expectation of privacy by allowing the corporate key recipient to be removed. With usage of older versions of PGP, there was really no way for the company to even inform the sender about whether it was going to be reading the mail. In the third scenario, where you encrypt to the corporate key, there is no expectation of privacy. All parties, the sender, the receiver, and the company, know that the data is being made available to the business. There is not much privacy here; what you have is business security. This mode would be used for business documents and business communications. In the fourth scenario, which some people are offering as a superior approach, the expectation of privacy is much less clear. Unlike in the current PGP approach, where the design of the corporate access system is oriented around notifying the sender and receiver, a key escrow or plaintext recovery system inherently provides no such notice. This is different from the status quo. We are talking about a commercial product which provides automatic corporate access to communications. Widespread installation and use of this alternate version of PGP inherently changes the assumptions and expectations that you will have when you encrypt to someone at work. Given the company's desire for message access, this approach implies that you must conservatively assume that most encryption to a business address will be read. The PGP system is designed to avoid this. It provides another method for corporate access, a visible and explicit method. It is intended as an alternative to key escrow and other systems which recovery data after the recipient gets it. PGP's third party recipient feature is designed to prevent the creation of an installed base of escrowed keys and after the fact third party access software. Even if the encryption system provides a way for the user to mark his keys as being escrowed or otherwise providing third party access, the system is not self-correcting in the way the PGP system is. It would be much easier for a business owner to pervert a secretive access system than one like PGP. The company could install the access features but not tell its employees that their keys were being escrowed, or that their mail client was secretly storing a copy of all plaintexts. This kind of change would be easy to make with the after-the-fact access systems some people are proposing. Yes, theoretically this can be done with any encryption system (as all agree) but the point is to avoid the widespread distribution of software which invites this kind of abuse. The PGP system is designed to satisfy business needs without leading us into this dangerous situation. A world in which third party encryption by the sender is the normal and widespread method for corporate access is one with increased privacy and more visibility of access. The alternatives which have been proposed are prone to abuse and provide less visibility. They lead us towards a world in which there is no expectation of privacy even for encrypted messages, by providing an installed base of snooping software. The PGP approach is explicitly designed to keep us out of that world, by removing the need for that kind of software.

3 2

(fwd) Re: KRAP is at it in the IETF
by Adam Back 17 Dec '03

17 Dec '03

A GAKker breaks cover on dbs list as a result of William Geigers heads up on the issue... The GAK apologists are very thin on the ground in public discussion forums generally, so it is nice to see the odd one speak up. Seems like they are too busy taking government handouts to implement KRAP to actually own up to their misdeeds in public, generally. Adam ====================================================================== From: "Todd S. Glassey" <TSGman(a)earthlink.net> To: "William H. Geiger III" <whgiii(a)invweb.net>, <dbs(a)philodox.com> Cc: <tom_markham(a)securecomputing.com>, "JeffreySchiller" <jis(a)mit.edu>, "MarcusLeech" <mlecch(a)nortel.ca>, "Robert G. Moskowitz" <rgm(a)icsa.net>, <tytso(a)mit.edu> Subject: RE: KRAP is at it in the IETF Date: Mon, 7 Sep 1998 13:38:50 -0700 William, Let me start with the disclaimer since I am going to vehemently disagree with you - These are my own opinions and in no way reflect my companies or our clients Opinions, etc. etc. etc. - So William - IMHO, you are missing the point totally. The IETF is an A-Political Organization investing in the development of technical standards to accomplish various networking services. As to the issue of Politic vs. Technology, by its actions alone, KRAP's demonstrated agenda with the IETF is purely technical and whether it is in furtherance of its external political agenda is really irrelevant to the IETF as and its established process as a whole. >From my vantage point, the real issue herein is your personal/moral standing with the dissolving of anonymity through Key Recovery and Government's ability to look at data that flows over a network. Remember also that it was the Government that was the primary subsidizer of said same network and everything that evolved the old 56k ARPANET into what the Public Internet is today. As another side issue, the other potentially-viable argument is that ISAKMP/IKE is so far along in its process of becoming a standard, that adding a late draft impedes the value of the work already done - Essentially that these folks (KRAP) have essentially slipped a whammy onto the stack. Is it your view that this implies that because of this later posting that the material will be exempt from the general scrutiny that the previous components of ISAKMP/IKE have been through - I don't think so... This crowd loves to do the Pit-Bull thang and shred the submitted concepts to glean the technical truth therein. If this is the issue then the answer is to work within the existing framework and to submit a public motion to the WG to freeze the ISAKMP last call efforts so that they exclude the new draft until such time as it (the GAK extensions) can undergo further scrutiny. As to the issue of the addition itself being out of line because of its late entrance into the standards arena relative to the last call and all that- Again, I disagree as to what and how - There are numerous "standard processes" in place that allow for this as well and that here in the real world, use of this ability is a very common practice. Look for instance at what happened to the last TAX REFORM effort with the addition of Senator Moyniham's SS1706 Rider, or as another example look at what congress as a whole did with the HIPAA legislation (http://www.hcfa.gov/regs/hipaacer.htm) and its embedded "legal penalties" for unauthorized disclosure of health data. Since this case is specific to the bulk distribution of data, it really applies directly to IT Directors and their staff. heck, imagine that your insurance Co.'s or hospital's IT folks could actually go to jail by the statute set here. Again here we are at the bottom line and if this is the thing you are objecting too then you need to object to the process not the event itself. As to the perversion commentary specifically... perversion is a moral issue and is not addressed by the IETF rules (RFC2026 in particular). My suggestion is that if you feel this is a problem that you address it at the POISSON WG level rather than in IPSEC or PKIX since it is a process problem, and that under the currently in-place operating rules, this thing, the filing of a new proposed component of the ISAKMP protocol is OK to do. - --- Don't get me wrong, as it happens I too believe that Key Recovery is futile effort for the government, not because it doesn't have a need for this type of capability, but because they didn't act fast enough and the "cat is already out of the bag". So any efforts to pull this one off will most likely be futile and will definitely not be cost effective for normal ECommerce operations let alone personal communications. BTW - The reality in the Intelligence Community World is that for the surveillance of the big-league terrorists, dope dealers, and the like, key recovery is useless since because they are so well funded and their access to technologies is such that they (the bad guys) can and will employ advanced technologies to get around whatever the NSA/DSIA/DoC/DoJ put in place to thwart them. As an example of this the Leopard's (sort of the Bolivian Govt.'s DEA Field Agents, et al.) found that when they attacked the labs of the Median Cartel they were out gunned and technologically overpowered to the point that without the US Military intervention they would have no possibility of thwarting these activities. Draw your own conclusions. As a point of social commentary, I understand and hear your point, but if this kind of process "invasion" as you have put it was such an issue then how come there was so little push back was done against the "Communications Assistance for Law Enforcement Act" (CALEA). I think that as a whole the people against the KRAP initiatives are there because of the cost and overhead issues, not the personal freedom ones. Thus it becomes a business issue and not a human one. The world is changing into a global society and the rules about personal freedom are evolving with it... Not everyone is going to like them but the facts are what they are and IMHO - personally I wonder more how some local constituency would respond to the invasion of their personal privacy when some "pervert terrorist" parks a recently acquired nuke or Bio-toxic Weapon from the now defunct Russian Arsenal in their backyard and pushes the #$%^&* button. If losing absolute anonymity is the cost of better safeguarding oneself and family from threats like these, what the heck. Its a very small cost to pay. My personal feeling is that since I have made the decision to live in and work with modern society as a whole, that I must follow the edicts that evolving technologies and social values/morals put in place by and for us as a whole. Otherwise our choice is real simple - If you don't like the rules, then don't play the game. Move out to the backwoods and stay out of society as a whole. I don't mean to be a putz by this, but come on... "a perversion". This isn't the place for that kind of morality issue!. Todd > -----Original Message----- > From: dbs(a)philodox.com [mailto:dbs@philodox.com]On Behalf Of William H. > Geiger III > Sent: Monday, September 07, 1998 1:24 AM > To: dbs(a)philodox.com > Subject: KRAP is at it in the IETF > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hello, > > It has come to my attention that the KRAP (key recovery alliance program) > has submitted an I-D (internet draft) to the IETF for adding GAK > (government access to keys) to the IPSEC protocols: > > ftp://ftp.ietf.org/internet-drafts/draft-rfced-exp-markham-00.txt > > ISAKMP Key Recovery Extensions > <draft-rfced-exp-markham-00.txt> > > 7. AUTHOR INFORMATION > > Tom Markham > Secure Computing Corp > 2675 Long Lake Road > Roseville, MN 55113 USA > > Phone: 651.628.2754, Fax: 651.628.2701 > EMail: tom_markham(a)securecomputing.com > > > I consider this a perversion of the standards process of the IETF to > advance a political agenda which must be stopped at all cost. > > Below are the e-mail addresses of some people that you should write > (politely) expressing your objections to any such additions to the > protocols: > > IPSEC Chairs: > > Theodore Ts'o <tytso(a)mit.edu> > Robert Moskowitz <rgm(a)icsa.net> > > Security Area Directors: > > Jeffrey Schiller <jis(a)mit.edu> > Marcus Leech <mlecch(a)nortel.ca> > > As I mentioned before, be polite. These people are not the ones proposing > GAK be added to the IPSEC protocols. They have put a lot of time and > effort in forwarding the cause for strong encryption. They should be made > aware of the communities objections to these attempts by KRAP. > > Thanks, > > - -- > - --------------------------------------------------------------- > William H. Geiger III http://www.openpgp.net > Geiger Consulting Cooking With Warp 4.0 > > Author of E-Secure - PGP Front End for MR/2 Ice > PGP & MR/2 the only way for secure e-mail. > OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html > - --------------------------------------------------------------- > > Tag-O-Matic: It's OS/2, Jim, but not OS/2 as we know it. > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3a-sha1 > Charset: cp850 > Comment: Registered_User_E-Secure_v1.1b1_ES000000 > > iQCVAwUBNfOVk49Co1n+aLhhAQFJwwP+O4vrZVKFpOG8vCHFwbDuPIv/99AhBnKF > RK/Ikc5y2gGKq9hfxkTb4o77YUrDaEGkYUPHk+ZC57Oag0Lu1v6W1EAbQ5T4RpzH > JWYXOonQmbqw5rH0h6brzqrH3ep9Ej9DR0gv4mGgIfSNlJSUu6TWO5ZHXKWiE4yy > 5flH0Ngg/TI= > =EzNL > -----END PGP SIGNATURE----- > > Tag-O-Matic: Speed Kills - Use Windows! > > > ------- End of forwarded message -------

1 0

Re: KRAP is at it in the IETF
by Adam Back 17 Dec '03

17 Dec '03

Todd S. Glassey writes on dbs(a)philodox.com (digital bearer settlement) list: > Let me start with the disclaimer since I am going to vehemently disagree > with you - These are my own opinions and in no way reflect my companies or > our clients Opinions, etc. etc. etc. - [What company do you work for? You disclaim about your "company" and "clients" without mention of who they are? (I like to know who the GAKkers are, are you with securecomptuing.com also?)] > So William - IMHO, you are missing the point totally. The IETF is an > A-Political Organization investing in the development of technical standards > to accomplish various networking services. As to the issue of Politic vs. > Technology, by its actions alone, KRAP's demonstrated agenda with the IETF > is purely technical and whether it is in furtherance of its external > political agenda is really irrelevant to the IETF as and its established > process as a whole. I understood it this way: that IETF policy is not allow political considerations to weaken or otherwise damage security functions in IETF standards. eg. No weak key lengths for to satisfy local government politics etc. Read RFC 1984. I quote: : KEYS SHOULD NOT BE REVEALABLE : : The security of a modern cryptosystem rests entirely on the secrecy : of the keys. Accordingly, it is a major principle of system design : that to the extent possible, secret keys should never leave their : user's secure environment. Key escrow implies that keys must be : disclosed in some fashion, a flat-out contradiction of this : principle. Any such disclosure weakens the total security of the : system. : : DATA RECOVERY : : Sometimes escrow systems are touted as being good for the customer : because they allow data recovery in the case of lost keys. However, : it should be up to the customer to decide whether they would prefer : the more secure system in which lost keys mean lost data, or one in : which keys are escrowed to be recovered when necessary. Similarly, : keys used only for conversations (as opposed to file storage) need : never be escrowed. And a system in which the secret key is stored by : a government and not by the data owner is certainly not practical for : data recovery. This quoted point is kind of relevant here: "keys used only for conversations (as opposed to file storage) need never be escrowed" Now we move on to your GAK apologist arguments... > Remember also that it was the Government that was the primary > subsidizer of said same network and everything that evolved the old > 56k ARPANET into what the Public Internet is today. "Government" is composed of public servants. This citizen-unit doesn't want to fund spooks to spy on himself. > The world is changing into a global society and the rules about > personal freedom are evolving with it... Not everyone is going to > like them but the facts are what they are and IMHO - personally I > wonder more how some local constituency would respond to the > invasion of their personal privacy when some "pervert terrorist" > parks a recently acquired nuke or Bio-toxic Weapon from the now Oh give us a break! You already admitted that terrorists are going to use whatever crypto they want whether or not governments succeed in ramming GAK down our throats. > defunct Russian Arsenal in their backyard and pushes the #$%^&* > button. If losing absolute anonymity is the cost of better > safeguarding oneself and family from threats like these, what the > heck. Its a very small cost to pay. Perhaps you would think that video cams in all the rooms in your house (with feeds back to NSA) would be a good idea also,... well you install them, at your cost, and leave us out of your eavesdropping plans, ta very much. Adam

1 0

h
by CRBREW9802＠aol.com 17 Dec '03

17 Dec '03

how did u do it

2 1

No Subject
by Mix 17 Dec '03

17 Dec '03

Timothy C[ocksucker] Mayhem's reheated, refurbished, and regurgitated cud is completely inappropriate for the mailing lists into which it is cross-ruminated. _ O Timothy C[ocksucker] Mayhem (_ | -'_/ X-

1 0

[MilCom] MRE's, KCMO, VA Hospitals
by Jaggedrock＠aol.com 17 Dec '03

17 Dec '03

Fellow radio enthusiasts of all the above nets, In the past week I have learned of MRE stackpiling in a natural limestone cave in the Kansas City Missouri area. A 4 month government (don't know the specific agency) contract it would appear, that will result in excess of 35,000,000 MRE's having been stored in the cave. That's enough to feed 500,000 for 22 days roughly. Further, I have learned that, apparently, 23 VA hospitals that are closed (don't know where and don't know the names) are being converted into food storage facilities with all of the equipment having been removed and a special coating being applied to the interior surfaces to enhance storage life. Having said that, any fecom, milcom activity that would shed light on this activity? Any KCMO monitors hearing anything? Anyone in KCMO area that would like to try to find out more and advise the rest of us accordingly? Thanks, jaggedrock(a)aol.com (Sangean ATS803A, Uniden 100XLT, Uniden Bearcat 895XLT Trunktracker, 48 foot roof mount dipole, roof mount Scantenna 25 feet aloft, all low loss cable feeds - plus good human eyes and ears). --- Submissions milcom(a)qth.net

1 0

cryptographically secure mailing list software
by Matthew James Gering 17 Dec '03

17 Dec '03

I've been curious as to whether anyone has developed and/or whether it is technically feasible to develop a cryptographically secure listserver. e.g. User would submit their PGP public key to the listserver upon subscription, submitted messages would be encrypted with the listserver's public key, the listserver would decrypt the message and re-encrypt it with the key of all members and distribute it. This way the users don't need to manage all the keys or even know the list membership. Most listservers already have the ability to moderate subscription messages, the list would not be snoopable. What sort of overhead would exist on a list of a few hundred members? If there is not something existing that will do this, what is the best mailing list codebase to start from? Majodomo I imagine might not be up to the task being written in Perl, LSoft ListSERV I love but it is commercial (no sourcecode). Matt

2 1