December 2003 - cypherpunks-legacy

NIST GAK meeting writeup, LONG part 3 of 3
by pfarrell＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- NIST Key Export meeting, December 5, 1995 Long version Part 3 of 3. This covers the notes on agent criteria, and the industry presentations. Part 2 of three hasn't been written, it is supposed to address the issues related to interoperability. I decided it was better to get this part out than to wait. Items on the criteria themselves that I think were under reported in my first reports: Ed Appel: the LEAs are very interested in Criteria #5 (two ended decryption) as they have more than 100 international offices. Miles Smid described a trick for meeting Criteria #5, if you encrypt the session key with your own public key, in addition to the key of your destination, and if you have escrowed your private key with an Escrow Agent, then nearly any approach meets criteria #5. ********* On agent criteria: ********* Geoff G. says that the discussions on agent criteria are simply a follow-on to the main criteria #3. The criteria themselves have been spam'd to the list. They are also available at url: <a href="http:/www.isse.gmu.edu/~pfarrell/nist/escagent.html"> There was a lot of reactions to the SECRET clearance requirement, which they claimed was to handle secure investigations (e.g. FISA). This has already been discussed on the list, so I'll skip it here. David Lesher asked a series of questions concerning the requirement that the Key Escrow Entity employ a person with a SECRET clearance. They included: what agency will issue the clearance? Who will authorize for the BI (background investigation)? Who will pay for it? Who does the existing RBOC clearances? Geoff dodged nearly all of them. He acknowledged that "they" will have to pay, but made no effort to define who "they" are. Geoff said that they may want legislation support for protecting against illegal release of keys, failure to release, etc. A fair number of the agent criteria would be considered professional business practice (no single point of failure, dual locations, etc.) if you thought that escrowing keys was a good thing. ********* User/Industry presentations Bill Sweet of TIS Bill gave a presentation about his CKE product, and how hard he is working to "find a global solution." This is actually the same product that Bill talked about in September when he worked for National Semiconductor. It was impressive then (private keys are NOT escrowed, only session keys, etc.) and is still not approved for export. Bill talked about "information owners," they ultimately decide which security systems get deployed "in spite of various government requirements around the world." He said that "if rational key escrow systems are not offered, or do not adequately protect their information, owners will use unescrowed encryption from whatever sources available (Germany, et al)." Bill talked about a UK University (Royal Holloway) study on UK/European needs for key escrow. He said that there was a lot of overlap with the NIST criteria, but that there were criteria that were judged as totally unacceptable. The first and loudest finding was: "the use of the scheme should provide visible benefits to the user." This begs the obvious question, what visible benefits to the user does GAK bring? Two other interesting findings in the study were: - - An entity with a warrant should not be able to fabricate false evidence." - - Abuse by either side should be detectable by the other. He suggested that these criteria be added to the NIST list of 10. Bill went on to look at the NIST criteria. He said, concerning Criteria #3 (agents certified by US Government or reciprocal agreement), that "this is a show stopper!" because: - -- no reciprocal agreements exist today, anywhere. - -- what about countries where justice systems are different, and what about where "these agreements are not desirable (e.g. Nigeria, Mexico, Saudi Arabia, Argentina, Poland, etc.)? - -- even for NATO countries, agreements will be different (Germany has data privacy laws, in Greece), or we may not want to be reciprocal (in Greece, the government likes to bug the opposition) He also says that Criteria #7, 64-bit keys, is unacceptable. CE Infosys currently sells a PCMCIA (PC Card) encryptor that does triple-DES at T1 speeds. TIS uses it, and sells it in the US. [as an aside, I was told that they can import and resell them, but when one breaks, TIS cant ship it back to Germany for repairs. Sigh.] Sweet had two recommendations: - -- develop a tiered crypto policy, with hardware and software under differing levels of rules, - -- allow a pilot project, where TIS can sell VPN (virtual private networks) using strong encryption. A VPN is the use of the Internet as a private network for a corporation by adding appropriate firewalls, encryption, etc. It seems to me that while TIS' CKE doesn't meet the criteria, it could be made to, with a few changes. They've have to change the design to allow GAK for any one target. (Criteria #5) This would mean for generating one DRF (ie., LEEF) for each recipient as well as for the sender (as opposed to just for the sender) The neat thing about CKE is that each LEEF holds only the session key -- so you never give away your private key. (I think the govenment really expects that we'll be willing to escrow our private keys. Fat chance!) But this is a bit of a catch 22, because to follow all the criteria, you can't stop there. - -- For each encryption, you generate a DRF for the sender and each recipient - -- For each DRF generated, you must have and check a certificate chain for the chosen DRC and refuse to encrypt unless all recipients and the sender have validly certified (ie., USGovt approved) DRC public keys. - -- Each receiving application must refuse to decrypt unless every other recipient and the sender have validly certified DRC public keys. This gets into the interoperability issues that I need to write up... - -- I don't know how they can meet the revised #6. It seems to be designed specifically to break CKE. To get govie approval, each DRC needs to meet all the key escrow agent entity criteria. I'm really not at all convinced that it is actually practical. This is sad, because CKE is obviously designed with the spirit of the government at heart, with just some modifications to make it marketable. Guess TIS needs an Ireland office too. Ken Mendelson of TIS Ken gave a solid presentation describing how all of the Governments need for data about key escrow agents could be met with a commercial "vendor registration" approach instead of a Government mandated "certification" scheme. This would be in keeping with the current "spend less money, have less government bureaucratic rules" political climate. I have copies of his slides, Id rather not type them in. With any luck, hell put them up on the TIS web site url: http://www.tis.com Dorothy Denning of Georgetown University Dorothy Denning gave a presentation on an article that will be published in the March 96 Communications of the ACM. It analyzes currently available products (and vapor products) and sees how well they meet Criteria #5. It says that eight of the sixteen approaches that she surveyed currently meet Criteria #5. She lists her web page as http://www.cosc.georgetown.edu/~denning, but as of Sunday 12/10, the text is not available. Melanie Janin, US Council for International Business Ms. Janins speech presented the US Council for International Business comments on GAK. They are a NY based trade group, representing 300 clients. They dont like GAK. She called for a coherent policy on all encryption. Major topics in the presentation include: - - free choice - - open to the public - - international acceptance - - flexibility of implementation - - User key management - - Key escrow (where they "embrace key escrow as one possible method of managing encryption keys.") - - Liability Ed Scheidt, Tecsec Presented both comments on the criteria and his companys VEIL and Export VEIL Version 2.0 products. He raised a number of points, including: - - how do we protect our commercial information unless we have the best cryptography? - - we need "constructive key management technology" to manage keys, key splits, and different algorithms for extended data separation. - - solution must address issues such as international trust in a key escrow. He said that his "Export VEIL 2.0" product meets "the intent of 11/95 export criteria today." Daniel Weitzner of CDT Mr. Weitzner agreed to shorten his presentation so that he could yield some time to VTW. He opened by pointing out that while the schedule had both him and Jerry Berman were supposed to talk, Jerry was too busy to make the meeting. "Jerry is out defending pornographers, so Ill be here defending terrorists." I expect that his text will be on CDTs webpage, url: http://www.cdt.org. Ill just enter the key points. The first thing he said is that "this is the wrong forum" and that "the [NIST] process will not work." He proposed a open, privately sponsored forum to develop alternatives that will work. "The NIST proposal will not provide adequate security, privacy, promote secure communications worldwide, or guarantee user privacy." Major issues are: - - Inadequate security - - No viable policy framework for the long-term - - Hinders the deployment of globally interoperable secure systems - - not necessarily voluntary - - not viable in the marketplace - - no constitutional privacy protections - - will not meet the needs of law enforcement, since it will "not deny criminals or terrorists access to strong encryption, the stated objective of the policy." Shaber Safdar, Voters Telecommunication Watch Described the results of an Internet-based, non- scientific survey that the VTW recently made. Not surprisingly, those who replied were overwhelmingly against the NIST proposal. I dont have the slides, but VTW has a website with most of their information. The url is http://www.vtw.org There were 26 respondents to the survey. 24 out of 26 said that they would never buy products with law enforcement access. 16 out of 24 are already using security products. He described a Technology Pledge that VTW is presenting to politicians (available at url: http://www.vtw.org/pledge/) and stated that Rep. Ronald Wyden (D-OR) signed the pledge with pro- freedom, pro-market answers. David Sobol, EPIC As expected, EPIC doesnt like much about the NIST proposal. Their comments are on their web page, url: http://www.epic.org/crypto/EPIC_Statement.html A key statement is "Given the reality that users are unlikely to adopt key escrow systems on a voluntary basis, we believe that the current policy will result in the eventual prohibition of non-escrowed products. Indeed, documents released to EPIC under the Freedom of Information Act (FOIA) reveal that NSA and FBI concluded nearly three years ago that Technological solutions such as they are, will only work if they are incorporated into all encryption products." Major points - --Public comment is frequently solicited but never heeded. - --Relevant information has not been released. - --The proposal conceals the attempt to expand wiretapping capability As a result, EPIC proposes the following Policy Recommendations - --Relax export controls on encryption and permit the free flow of encryption products across national borders - --Withdraw FIPS 185 (the Clipper standard for voice, fax,... and low speed data networks in the federal government) - --Remove "cryptology" from items that may be classified ... under executive order - --Do not fund the Telephone Carrier Compliance Program (the "Digital Telephony" proposal) - --Do not permit the use of classified algorithms for public networks - --Examine the activities of the National Security Agency ... since passage of the Computer Security Act of 1987. NOTE: during Mr. Sobels discussion, a FBI representative sitting at the head table said that the issues addressed by key escrow are "not just wiretapping, they include search and seizure of all stored media." I was not able to identify the person. He was sitting at Ed Appels seat, but did not have a namecard. No one sitting near me recognized him either. Padgett Petersen, Lockheed Martin Noted Internet personality, Padgett Petersen took a rarely held position, he spoke as a Security officer of Lockheed Martin, rather than speaking as a private net-citizen. He said that "these criteria are acceptable and can be made to work." He also said that "without US agreements, there is no reason to be concerned with export." Lockheed Martin was looking forward to participating in using and buying the escrowed products that will hit the market as a result of this process. Robert Hollyman, Business Software Alliance Mr. Hollyman said that "the facts are clear, companies are unanimous against" the NIST proposal. His members agree that: - - security is critical - - 40 bit is not viable - - the 1992 government review requires a change in policy. He recommended: - -- immediate approval of DES or equal strength alternative for export. - -- encourage companies to build encryption software by submitting code to NIST (under non-disclosure) for review - -- add two bits ever three years to allowable key lengths in recognition of Moores law. He called this a COCA allowance (cost of cracking algorithms). - -- removal of restrictions on interoperability because they are artificial and antithetical to the Global Information Infrastructure. He stated that the current criteria are vague, and will take years for approval. Yet he notes that in industry, the average life cycle of software is 18 months. Alex McIntosh, PC Security PC Security sells key management systems. Shell is a customer. He addresses a couple of areas that his commercial customers ask. The first question is "why encrypt?" He said that the answer is to protect confidential data. These data include email, PC files, and archival data. This leads to the obvious question, why use key management? The two separate answers are to have operational backup and to allow compliance with internal and external law enforcement. He said that he has a surprise for the NIST folks concerning key escrow agents. The corporate customer is the key escrow agent. Other key observations: - -- Companies, such as Shell, often do business in countries where they can not trust the government. - -- Shell handles over a million email messages a day. This defines engineering requirements for any system to meet. - -- Liability is a huge issue, and the amounts are huge. Geologic information, market strategies, etc. are worth staggering amounts of money. The "US Government can NOT cover Shells liabilities." Doug Miller, Software Publishers Association Mr. Miller said that his members need immediate relief from the current encryption export policies. "our members are poised, but cannot leap, because of the barriers that U.S. cryptographic policy continues to impose." He wants to be able to export 56-bit DES. His position paper says, "we believe the discussion should also include assessment of the exportability of products employing the DES algorithm. DES-strength (56-bit) products can compete with 179 foreign products (80 of which are software products) that employ DES. Liberalization of the export restrictions of software with encryption capabilities is essential if U.S. companies are to compete with strong, widely available non-escrowed products." Viktor Hampel, Hampel Consulting Proposed "a Consumer Protection Act for Digital Products to support electronic commerce and to control the increasing abuse and lack of security on the national information highways." A copy can be obtained from Hampel Consulting, 1515 Jefferson Davis Highway, Crystal Square Suite 913, Arlington VA 22202- 3312. In his remarks, Mr. Hampel said that trust is important between business. Business worries about issues as varied as what accountability is in the system and how much is the per minute interest on a billion dollar money transfer? These cause business to need solutions that NIST hasnt raised. He recommended that a public key infrastructure be included into the Uniform Commercial Code. Closing comments. Mike Nelson noted that the meeting had some time for floor questions. He was asked what is the timeframe for finishing the process. He danced, saying that promising a fixed date for policy decisions is bad for your career, but thought it would be done in a couple of months. Someone asked about the "Personal Use" export process (the one that will allow you to export PGP on a laptop computer for personal use, and that was promised for "in a couple of weeks" at the September NIST meeting). They said that it is about to go to the Federal Register, and should be available within weeks. Nelson was asked about foreign escrow agents. He said that "if there exists bilateral diplomatic agreements, then the US will allow specification of Foreign Escrow agents." [Of course, no such agreements exist now.] Ed Appel of the White House said that the intent is to make export "as easy as 40-bit" is under the existing policies. The existing export policies will continue. He also said "so far, we are only controlling export" and that "the government has very strong cryptography available to them, so they are not worried about export." He said they hope to control export in two ways, first by applying the combined purchasing power of the US Government to encourage the market, and by controlling export. ********* After the meeting closed, I invited both Mike Nelson and Ed Appel to the next DC Cypherpunks meeting. Somehow I expect it when they declined. ******** A note on quoting within this document: I did not take a tape recorder to the meeting. Words in quotes were taken from either my hardcopy of handouts, words in documents on cited webpages, or from my noted. I tried hard to keep the words accurate and in context. There may be some cases where my quotes are incorrect. If I've misquoted anyone, it is not delibrate, and if told, I'll post corrections. Pat Copyright (c) 1995, Pat Farrell. Permission granted to electronically redistribute, provided it is transmitted in the whole and unaltered. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBMMsugLCsmOInW9opAQGWSAP/QC3Xja8kE56XGximmiiIVEv3ihJI1uY5 2eWZSVUGOxATc3jbwtLS5bqmkDnSXhQaaD6Slk/zA9IGlNhzi4tMV1xsrKwj4l4d 0KefEWOTinVze+6SQFsIVizGb9WzRaTrGwCV9RY7RRbC0dYa+cb21JXvlZOxYk/Q wGfkSY5/H0Y= =hJvT -----END PGP SIGNATURE----- Pat Farrell grad student http://www.isse.gmu.edu/students/pfarrell Infor. Systems and Software Engineering, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer

1 0

Re: GAK and self-incrimination?
by Greg Broiles 17 Dec '03

17 Dec '03

Ed Carp writes: > Greg Broiles writes: >> Tim May writes: >> >> >Consider this hypo: I send an encrypted message to a partner in crime >> >containing plans for future crimes and descriptions of past crimes. I >> >don't GAK the message. The government prosecutes me under the >> >Anti-Terrorism and Child Protection Act of 1997. >> > >> >My defense? That GAKKing the message would be tantamount to incriminating >> >myself, which the Fifth Amendment protects me against. > >> The Fifth protects you against *compelled* self-incrimination . . . In >> particular, you're free to simply not send the message at all. > >I don't believe that that would be a consideration. Wasn't there a >court case a few years ago, in which a convicted criminal sued the >government, charging that filling out one of those forms that you >have to fill out when you buy a gun was a violation of his 5th >amendment rights? What ever happened to that case? This sounds like _Haynes v. United States_ 390 US 85 (1968); the Supreme Court ruled that requiring registration of particular weapons (possession of which was illegal) violated the Fifth Amendment. The difference between _Haynes_ (and _Albertson v. Subversive Activities Control Board_ 382 US 70 (1965)) and Tim's hypo is that Tim's hypo doesn't force only guilty people to provide information, it requires all people using crypto to do so - so it's not targeted at "persons inherently suspect of criminal activities" (see _Haynes_ at 96, _Anderson at 79), and it doesn't necessarily give rise to "real and appreciable hazards of incrimination" (_Haynes_ at 97). But it seems to me that the real bottom line is that the information which is compelled is not incriminating, and the information which is incriminating is not compelled. The keys to my crypto might lead to incriminating evidence, or they might prove to be useful in a prosecution, but they're not in themselves any sort of a signal that a crime has been or will be committed. I think it's a different argument - and probably even comes out the other way - if the command to reveal a key is made to a particular individual in circumstances where possession/knowledge of the key is likely to implicate the holder in criminal activity. If the police find an encrypted disk which is labelled "The Story of How I Killed Jimmy Hoffa and Where I Put His Body and the Murder Weapon", compelling someone to reveal the key which decrypts the file(s) on that disk seems incriminating, even if the information produced (the string of binary digits which is the key) isn't by itself incriminating. Is it "self-incrimination" to require people to provide the government with an address when they register a car, even though the police may use that address to look for evidence if you're suspected of a crime? Is it "self-incrimination" to require drivers involved in an auto accident to remain at the scene and provide a name and address to cops or other drivers? (Supreme Court says no self-incrim re hit & run statute, _California v. Byers_, 402 US 424 (1971).) (Now, if the government required people who weren't using GAK to provide a "Statement of Refusal to Comply with GAK", I think it'd be a different kettle of fish entirely.) I'm not trying to say that I think GAK is good - I think it's awful. But I don't think it's incompatible with the way that the Fifth amendment has been interpreted over the past 200 years. I think it's possible to ignore those interpretations and make up your own, but I don't think that's of much practical utility where the dominant local gang doesn't find your theory plausible or expedient. So much for the rule of law. >I also think that, besides the obvious 5th amendment problems, there >would be a 1st amendment problem - if you "*had* to use GAK to >communicate, that would be an impermissible restriction on your 1st >amendment rights. I agree with you re the First amendment. -- "The anchored mind screwed into me by the psycho- Greg Broiles lubricious thrust of heaven is the one that thinks every temptation, every desire, every inhibition." greg(a)goldenbear.com -- Antonin Artaud gbroiles(a)darkwing.uoregon.edu

2 1

Free calls to Govt (fwd)
by Robert A. Hayden 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is being forwarded from the ALA Intellectual Freedom mailing list. Thought it might be important here :-) - ---------- Forwarded message ---------- Date: Sun, 10 Dec 1995 09:59:48 -0500 From: Charles Willett <willett(a)AFN.ORG> To: Multiple recipients of list ALAOIF <ALAOIF(a)UICVM.CC.UIC.EDU> Subject: Free calls to Govt (fwd) - ---------- Forwarded message ---------- Date: Sat, 9 Dec 1995 14:31:58 -0700 From: El Tiburon <proteios(a)indirect.com> To: internet_censorship(a)monad.net Subject: Free calls to Govt 1) Dail 1-800-444-1555 2) They will give you a short recorded message. 3) Follow instructions if you have a touch tone phone, public ones work best and they have other advantages. :> 4) Enter a zip code...they ask for yours but it doesn't have to be...it can be any in the US. 5) Make a choice of the elected politician's office you want to be connected to. 6) When the staff person answers you are set to discuss the proposed environmental reform regulations, OR ANY OTHER ISSUE YOU WANT! Couple of tricks...we found they limit the number of calls to 3 from each number. Solution: public phones are everywhere...enjoy Exxon's corporate attempt to influence "grassroots democracy". M ______________________________________________________ Activism - Isnt it just participation? Internet Users Consortium 7031 E. Camelback Ste 102-515 Scottsdale, AZ 85251 IUC URL: http://www.indirect.com/www/molsen/ Proteios URL: http://www.indirect.com/www/proteios/ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Signed with PineSign 2.2 iQCVAwUBMMsZczokqlyVGmCFAQE+8AP7BkUKpHH06aC79T8P/J+YRF1AeMC/MB0W 2mEqED/zNhNF7pp2v0mUlRLpG6jrY0NRGip3JWZhRcdTwiMaVEWYNNHE6dUeklzO zm27/NxqKpi/e5ie+CsNwXKeket87+af8OZ8bzvIYg28pNcHAjnq5PLG62Oqsrxz 8E3QAHjAwc4= =l1BI -----END PGP SIGNATURE----- ____ Robert A. Hayden <=> hayden(a)krypton.mankato.msus.edu \ /__ Finger for Geek Code Info <=> Finger for PGP Public Key \/ / -=-=-=-=-=- -=-=-=-=-=- \/ http://krypton.mankato.msus.edu/~hayden/Welcome.html -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GED/J d-- s:++>: a-- C++(++++)$ ULUO++ P+>+++ L++ !E---- W+(---) N+++ o+ K+++ w+(---) O- M+$>++ V-- PS++(+++)>$ PE++(+)>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++ G+++++>$ e++$>++++ h r-- y+** ------END GEEK CODE BLOCK------

1 0

Re: More FUD from First Virtual
by Ed Carp 17 Dec '03

17 Dec '03

> From: Adam Shostack <adam(a)homeport.org> > Subject: Re: More FUD from First Virtual > To: khijol!netcom.com!ecarp(a)homeport.org > Date: Sun, 10 Dec 1995 13:08:29 -0500 (EST) > Cc: cypherpunks(a)toad.com (Cypherpunks Mailing List) > Ed Carp wrote: > > | Adam Shostack <adam(a)homeport.org> > | > jim bell wrote: > | > > | > [Good points about cost of transactions deleted] > | > > | > | The answer, I think, it that there would be no problem finding people to > | > | take that risk in exchange for the return, ESPECIALLY if they have some > | > | input into the design (level of security) of the system. They might insist > | > | on 2048-bit RSA keys, instead of 1024-bit, for example. > | > > | > (I know its only an example, but...) > | > > | > Key length is not what is needed for better security; more > | > solid code and better interfaces are needed. (I might also argue for > | > hardware keys that are more difficult to steal..) > | > | Nonsense. The code is pretty solid, the interfaces aren't very > | difficult. What is needed is better human management of keys. Why > | brute-force, why look for weak keys, why bother calculating how much > | safer 2047-bit keys are rather than 1024-bit keys when someone can > | look on your HD and find your secret key, when they can open your > | desk drawer and find your pass phrase or password, when they can > | guess that you used your wife's maiden name as your password? > | > | Adam, I don't understand why you wrote nonsense in the first > | paragraph, then followed it up with textbook attacks such as: > > I use PGP becuase its pretty good, but if I was going to trust > all my money to it, I'd want better code (especially in key > management. And the Mac port needs a few man months of work. ;) I > don't know how solid the code is in the ecash client. I do know that > Netscape & Microsoft can't seem to ship decent code. (This is a > reflection of the way the industry has evolved; the first system to > require a bigger processor due to creeping featuritis gets the most > market share. Quality of code seems to be unimportant.) No flame at > Netscape here; they're doing what the market, conditioned by MS to > never expect bug free code, seems to want. As I understand it, the problems in the code aren't the result of the underlying algorithm being flawed, but a flawed implementation, especially in the areas of key management, RNG, and the amount of information revealed in the final encrypted product. As far as anyone can tell (unfortunately, as BS pointed out, we don't have the mathematical tools to prove one way or the other that RSA or BBS or any of that algorithmical "stuff" is secure or not) the algorithms are secure. The problem can almost always be traced back to either a poor implementation or poor QA/QC, something that TQM and all the current management buzzwords are going to do nothing to fix. > Further, the interfaces are not decent. Ever tried teaching > your mother to use PGP? I have a lot of smart freinds; a lot of them, > while understanding how easy it is to read mail in transit, haven't > found a PGP front end thats easy enough to use that they will use it. I wasn't referring to the user interface, I was referring to the code interface, but I'll comment on the user interface. For most people, crypto is *hard* to understand. If it's easy to understand, you're probably making a LOT of assumptions about key management for your user, and some of those are almost certainly going to be bad ideas - that's why PGP gives you such flexibility. If you want to shoot yourself in the foot with PGP, Phil will certainly let you, but not without warning you first. IMO, taking the complexity out of the key management process will almost certainly lead to designers and programmers making bad decisions about how the process should work, and that's going to lead to a whole host of problems, most of which will come home to roost at PZ's doorstep. Yes, you and I and most people on this list know that this is bullshit, but you'd be amazed at what people will believe - witness the "ASCII virus" crap we all had to endure a few months back. There were a lot of people who actually believed it. I haven't found *any* PGP code that was well-integrated into anyone's mailer (including my own). Maybe the code for Pegasus is different - I certainly hope so. I, as well as many people, have got wrapper scripts around vi and emacs and pico that will do automatic encryption/decryption/signing for elm and pine, but that's not Windows. If I could get my mother to use UNIX, she'd find that she can send and receive encrypted/signed email as easily as she can unencrypted/unsigned email - the back-end work has all been done for her. The problem is, she'd rathet "do Windows" - the overall OS interface (if one can all Windows an OS) is a *lot* easier to work with and understand than UNIX is. So, she's stuck with Pegasus and Eudora and such - and no way to do encryption and signing without having to go to a lot of trouble. > (This is not an invitation to send me your favorite GUI to PGP > (although if anyone has a web page of all/most of them, with reviews & > comments and maybe even screen shots, I'd like the URL.) I would, too... :)

3 3

Re: Still more on the Digicash protocol
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: futplex(a)pseudonym.com (Futplex) It seems to me that end-to-end encryption is not significantly more important for remailed messages. Really, there's less information in the message when it emerges from the last remailer, so there's less to protect than in the ordinary case. Furthermore, it may not even be feasible, since I may not have a public key I can associate with my correspondent. ------------------------------------------ A possible solution: the correspondent generates a new public key and sends it as part of the transaction. The key is then wiped afterward. Sorry if this isn't possible due to something that I've misunderstood. -Allen

1 0

Re: Free calls to Govt (fwd)
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

I've been told that number is out of date. Since I forgot to save it, would someone who did check and find out? Thanks, -Allen

1 0

Re: Warning about Pegasus Mail and PGP (fwd)
by Adam Hupp 17 Dec '03

17 Dec '03

Where can you get the Open Encryptor PGP interface? -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQBtAzCNppQAAAEDALhWZl7IuGZ9zZT5bACo0b/1L0Nv0C72vKHIO3IHh+cwpHHa 2Ozb9aeO0UvXGwkkZIYgUm0EvmzKh7yb1GTLvBp5kXpR3I9w+Yj4LGlBDERpUWw6 x4ED49pwDnz1Hl5FBQAFEbQYYXNoIDxhaHVwcEBwcmltZW5ldC5jb20+ =PtJK -----END PGP PUBLIC KEY BLOCK-----

1 0

Re: Windows .PWL cracker implemented as a Word Basic virus
by daw＠quito.CS.Berkeley.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <95Dec10.175318edt.1732(a)cannon.ecf.toronto.edu>, SINCLAIR DOUGLAS N <sinclai(a)ecf.toronto.edu> wrote: > My understanding was that MD4 had been broken once, at the cost of > much computer time. Not *that* much computer time... In my copy of Hans Dobbertin's paper, the abstract says ``An implementation of our attack allows to find collisions for MD4 in less than a minute on a PC.'' As far as I know, the difficulty of inverting MD4 is still an open problem -- but why would you want to use a broken algorithm like MD4 when you can use MD2, MD5, or SHA? - --- [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 iQBFAwUBMMtrRCoZzwIn1bdtAQGQwQF+JlWjDgMCs+Y6nO/tUzrXcd9wJCrTLHx2 NlC+1bHspTvJSXSD29M73rfeyOfWOTtQ =4jl6 -----END PGP SIGNATURE-----

2 1

mailing List
by John H. Wynne 17 Dec '03

17 Dec '03

Please put me on your mailing list

1 0

[NOISE] REQ: "Markov" filter as recently posted in .shar form
by Damaged Justice 17 Dec '03

17 Dec '03

Apologies, but I already tried all standard net searches on this. Someone recently posted a .shar archive for a program called Markov, which filters input Usenet posts and outputs a reasonable facsimile of that person's "style". (It was posted in one of the "Alice" threads, in response to the claim that posting styles could be a unique form of identification.) I also looked on the archives at hks.net, but had no luck there. If some kind person will post it again, I'll give it a home on my page of WWW resources. I have the binary, and am impressed and amused enough to keep it for regular use.. anyone for alt.usenet.kooks.markov? -- http://yakko.cs.wmich.edu/~frogfarm ...for the best in unapproved information EmmaGoldmanCamillePagliaMarieCurieAynRandSapphoDianaToriAmosPJHarvey&Demona Hate, hate your enemies save, save your friends find, find your place I feel a groove comin' on | speak..speak the truth | Freedom...yeah, right.

2 1