December 2003 - cypherpunks-legacy

Re: signature validation on secure edit messages
by joelm＠eskimo.com 17 Dec '03

17 Dec '03

Try turning Word Wrap off in Eudora. I was encountering the same thing in the Windows version of Eudora. With Word Wrap on, it seems to add CRs (or CR/LFs on a PC) to the end of each line upon sending. This obviously causes a message not to match the signature, since all of those CRs weren't there when you composed it. With Word Wrap off, your text still wraps on the screen when you're composing, but those unwanted CRs in the sent mail don't get added. Joel McNamara joelm(a)eskimo.com - finger for PGP key >Jeez. I really don't know why the heck this always happens to me, my >digsigs not validating. > >You can finger me at tjbryce(a)amherst.edu to retrieve a message with a valid >signature. > >I always write the message in eudora, copy it, sign it in MacPGP as TEXT >with attached signature, then go back and paste it over the old message. >Then I go back to MacPGP and check the signature on the clipboard to be >sure - no problems. But after getting mailed, it doesn't work. > >Damn. > >Tom >

1 0

Judge not...
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Here's something I though would probably be of interest to more than a few here that read Usenet news. First article is the "Cancel FAQ" put out by the "Judges List", which many may have seen on the new.admin.* groups. Following it is the "Judges List" FAQ. I doubt this is a major threat, but is a good example of the sort of thing that needs to be nipped in the bud. If the "Cancel FAQ" doesn't trip any alarms, be sure to read the following "Judges List" FAQ. Please pardon the length. Articles follow: Article xxxxx of news.admin.misc: From: judges[tm](a)arch.ping.dk (NetNews Judges[TM] List) Newsgroups: news.admin.policy,comp.admin.policy,comp.security.misc,misc.legal.computing,news.admin.misc,news.groups.questions,news.groups,news.newusers.questions,alt.censorship,alt.comp.acad-freedom.talk,alt.current-events.net-abuse Subject: Cancel Messages: Frequently Asked Questions (FAQ) Date: Sat, 4 Feb 95 16:29:13 +0100 (CET) Organization: NetNews Judges[TM] List Message-ID: <01050105.limupb(a)arch.ping.dk> Reply-To: judges[tm](a)arch.ping.dk (NetNews Judges[TM] List) X-Mailer: uAccess - Macintosh Release: 1.6v2 Lines: 382 Cancel Messages: Frequently Asked Questions (FAQ). Ver. 2.0 --------------------------------------------------------- Summary: You can protect your reputation as a information source by cancelling articles posted under your name as soon as you discover that they are erroneous. Cancelling other's articles, however, can expose you, your site, and the Net as a whole, to serious threats. The sender should be notified when articles need to be cancelled. Disputes or doubtful cases can be directed to the Judges' List for resolution. --------------------------------------------------------- List of Frequently Asked Questions *** Purpose of this document 1) What are cancel messages? 2) How have cancel messages been used? 3) When should I issue a cancel message? 4) When should I not issue a cancel message? 5) What should I do when in doubt about whether a cancel is appropriate? 6) What should I do if I receive a request to cancel one of my own messages? 7) How can I request that a message be cancelled when I can not do so myself? 8) What should I do if I suspect one of my posts has been improperly cancelled? 9) Why should I follow these guidelines? *** Cancellation request form *** Contributors to this FAQ --------------------------------------------------------- *** Purpose of this document This FAQ list serves as an introduction to cancel messages. More advanced information is presented in the document "Administration of Cancel Messages", which is directed to News system administrators. The objectives and operational procedures of Judges' List are specified and explained in the Judges-L FAQ, also available as the Welcome message for new subscribers to the List. 1) What are cancel messages? Cancel messages are special USENET messages from a class known as "Control" messages. Control messages don't result in postings for people to read. Instead, they give instructions to the USENET server software at each site that gets the message. A Cancel message is a control message that indicates that a particular message (named through its unique Message-ID) should be deleted. 2) How have cancel messages been used? Most commonly they are used when a person posts something they want to delete, correct, or retract. One can cancel an old message and optionally issue a new one. (There is a better way to cancel and re-issue called Superseding, but most user programs do not support it.) Cancels are sometimes used by moderators of moderated newsgroups to delete messages that should not have been posted. 3) When should I issue a cancel message? You should issue a cancel message if it becomes necessary to delete, correct, or retract one of your own posts. You can issue a cancel message to delete a forgery: A message posted by someone else, that appears to be from you. A forgery can often be cancelled by you as if it were your own article. Such cancels should be reported to the Judges' List (see below). Some victims of forgeries don't cancel them, but consider it sufficient to post disclaimers to the affected newsgroups alerting everyone to the forgery. This is wise, in any case, since the forged message is likely to be seen by many people, even if it is cancelled. The newsreaders rn, nn, and trn use "C" as the cancel command. In Rusnews type ":cancel" while reading the message to be deleted. 4) When should I not issue a cancel message? It is not appropriate to cancel an article posted by someone else. However, a forgery is an exception. A low-tech form of "forgery" is to insert fabricated quotes in an article. Such posts should be followed-up with a correction and the poster notified. Misattribution of quotations, as opposed to fabrication, is often a result of inferior news-reading software. Such posts can be followed-up with a correction and the poster should be notified. It is inappropriate to cancel someone else's writing simply because you find the opinions expressed offensive. You can, however, ask the author to cancel the offensive post. Your news-reading software should permit you to enter the names of offensive posters in a "kill" file. Then, you will not see articles from that person in the future. Ask your administrator to upgrade your software if your news-reading software does not have this capability. The poster should be asked to cancel a chain letter or a libelous article, or any other post, such as an advertisement or pyramid scheme, that has inappropriate content. A copy of the request should be directed to the postmaster at the originating site, if the content is unlawful. 5) What should I do when in doubt about whether a cancel is appropriate? Unless you are certain the poster is acting in bad faith, you should explain to the poster why you object to the post and ask that it be deleted. State that you are considering submitting a complaint to the Judges' List and explain how one can participate in the dispute-resolution process (see below). You may explain how the offending post, or a post that accomplishes the same objective, can be broadcast. One source of information is a list of Frequently Asked Questions, "How to find the right place to post (FAQ)" in the newsgroup "news.newusers.questions". If the post comes from your site, contact your postmaster or News administrator for an opinion about whether the article violates the site's usage agreement. Doubtful cases can be submitted to the Judges' List, for an opinion. A complaint to the Judges' List must include a: :complete copy of the offending post. :complete copy of your letter to the poster, requesting that the post be cancelled. : complete copy of any reply from the poster or a News administrator (only if permission to forward is not refused). The complaint must have a subject line that starts with the characters "COMPLAINT: ", followed by the subject of the offending post. If you receive additional information after submitting a complaint or wish to withdraw the complaint, the same subject line should be used. Mail the complaint to JUDGES-L(a)UBVM.cc.buffalo.edu or JUDGES-L(a)UBVM.BITNET. If you wish to participate in the discussion of the complaint, email to LISTSERV(a)UBVM.cc.buffalo.edu or LISTSERV(a)UBVM.BITNET with only the command: SUB JUDGES-L <your-name-here> in the message body. Replace the <your-name-here>, with your first and last name, in the above command. Before making comments on the List, please wait for someone to respond to your complaint. If there is no response within a week, it is most likely that you did not file a satisfactory complaint (see above). If you find no error in your complaint and the problem still has not been resolved, send an additional message asking for help. 6) What should I do if I receive a request to cancel one of my own messages? If you do not agree that the request is valid, reply to the request with your reasons for not cancelling. If the request does not mention the Judges' List, refer to this FAQ and ask that you be notified if a complaint is submitted. 7) How can I request that a message be cancelled when I can not do so myself? If your software does not permit cancellation, or you are not confident in using it, ask your administrator to issue a cancel message for you. 8) What should I do if I suspect one of my posts has been improperly cancelled? If you suspect that your post has been improperly cancelled, contact your News administrator to rule out the possibility of a technical failure. If there has been an improper cancel, complete documentation should be directed to the Judges' List. Follow the procedures for submitting a complaint, but replace the characters "COMPLAINT: " with "CANCEL: ". 9) Why should I follow these guidelines? If you do not cancel erroneous articles that you have posted, you waste readers' time and damage your own reputation as a reliable source. Consider an article posted to a typical newsgroup with 36,000 readers, a post that takes an average of 1 second for each reader to deal with (i. e., examining the subject line) uses a total of ten man-hours (36,000 seconds / 3,600 seconds/hour = 10 hours). If the article uses up an average of four seconds, then the total time expenditure is 40 hours, the equivalent of a work-week. This is probably the minimum time expenditure on any article that is even selected for scanning. Thus, a few minutes spent cancelling an article can save a lot of time for readers. Groups with a lot of erroneous articles tend to lose readers, and articles posted to those groups reach a limited audience. By cancelling erroneous posts, you also reduce the risk that your name will be entered in numerous kill files, thus limiting the audience you can reach with your posts. Posting of apologies for faulty articles, such as those with an empty body, is to be avoided, since this wastes even more time of the reader, without supplying useful information. If you abuse the cancel facility, by cancelling other's articles, you force people to take defensive actions. Many administrators have disabled cancels, because they have been abused. The disabling of cancels means that you will not be able to delete all copies of your own posts. Therefore, if you cancel an erroneous article and then post a corrected one, readers at certain sites will first see the erroneous one and then the corrected one. They may think that the corrected one is a duplicate and not read it. This situation is obviously of no benefit to posters or readers. If your site's administrator has disabled cancels, it is wise for you to notify your administrator when you issue a cancel, so at least it can be deleted at your site. Disabling of cancels does not prevent a cancel from working at all, since the cancel message can delete the cancelled article before it gets to a site where cancels are disabled. Therefore, a cancel will be most effective if it is issued immediately after the target article is posted. In some cases, robot posters have been used to immediately repost articles that have been cancelled. This can rapidly lead to a newsgroup being overloaded at a site where the cancel facility has been disabled. This type of conflict situation should be avoided, since it makes the newsgroup unusable for most readers. Cancel messages must be used with extreme care. If you cancel articles based upon their content, you expose your site to a legal risk, since it can then be argued that you are taking responsibility for all articles' content, some of which may violate copyright or pornography laws, for example. Originating sites already are exposed to this risk, therefore, they should be allowed to cancel such posts. They should also have a user agreement that permits them to discipline a user, thus ensuring that repeated postings of this type do not occur, and thereby reducing the legal risk at all News sites. This is not a hypothetical risk. Many sites have been closed down, had their equipment seized, and their operators prosecuted, and in some cases jailed. The effectiveness of a common-carrier or "bookstore" type of defense has yet to be established (But see Mike Godwin <mnemonic(a)eff.org>. INTERNET LIBEL: IS THE PROVIDER RESPONSIBLE? Internet World, Nov./Dec. 1993) [URL: ftp://ftp.eff.org/pub/CAF/lawlibel_1.IW] The use of non-originating site cancels, to control content of articles, reduces the chances that such a defense can ever be established. This could make the risk of operating a News site unacceptable. Some sites have already been prohibited from operating moderated newsgroups or mailing lists by their legal counsel, because of the legal risk associated with assuming responsibility for content of distributed messages. The damage to USENET caused by the most extreme case of abusive posting was much less than that caused by external threats, even when those threats did not directly result in disruption of a News site. Therefore, in doubtful cases, cancel messages should not be issued. Notification of authorities external to the Net should be avoided. Contacts to the Press should be left to those who have been trained in public relations or have equivalent experience. In order to minimize legal liability, you should in, first instance, try to stop abusive posting at the source. By objecting directly to a poster of offensive material and making the person aware of this FAQ, you reduce the chances of repeated abuse. In the case, that a poster refuses to comply with a request to cancel an article and you refer the matter to the Judges' List, the conflict can be resolved in a way which benefits the Net in the long term, and reduces the risk that you will be subject to retaliation, for example, by having your posts improperly cancelled. Complaints to the Judges' List also permits a database of repeat abusers to be built up, with much more effective resolution of such cases then becoming possible. *** Cancellation request form Sample reply to a poster requesting cancellation or explanation (not usable in cases where only the opinions expressed are offensive): --------------------------------------------------------------- I object to your post, because .... Please cancel this post and notify me that you have done so, or explain why you will not delete the post. Please note that any reply may be forwarded to the JUDGES-L list, unless explicit objection is given. If I get no response, I will submit a complaint to the Judges' List. If you wish to participate in the discussion of the complaint on that List, email to LISTSERV(a)UBVM.cc.buffalo.edu or LISTSERV(a)UBVM.BITNET with only the command: SUB JUDGES-L <your-name-here> in the message body. Replace the <your-name-here>, with your first and last name, in the above command. --------------------------------------------------------------- *** Contributors to this FAQ include: Bob MacDowell <bobmacd(a)NETCOM.COM> Tim Pierce <twpierce(a)midway.uchicago.edu> David Stodolsky <david(a)arch.ping.dk> Dimitri Vulis <dlv(a)dm.com> ================================================ Posted on behalf of the NetNews Judges(TM) List. Judges-L Registrar, dss David S. Stodolsky, PhD * Social * Internet: david(a)arch.ping.dk Tornskadestien 2, st. th. * Research * Tel.: + 45 38 33 03 30 DK-2400 Copenhagen NV, Denmark * Methods * Fax: + 45 38 33 88 80 And now, the "Judges List" FAQ:

3 2

The Rise of "Worse is Better"...
by stig＠hackvan.com 17 Dec '03

17 Dec '03

A while ago, I mentioned appendix C to the _Unix-Haters Handbook_ and someone (Jason?) was interested in it. I couldn't come up with the text of the chapter until now because I didn't have it until now. Look through the Lisp-specific jargon to see what RPG (the author) has to say about the differrent priorities in getting a job done... One school of engineering follows "The Right Thing" approach, while the other uses the "Worse is Better" (quick-and-dirty) approach. Stig I have the .tex file for the article, and it's available on the WWW as http://www.ai.mit.edu/articles/good-news/good-news.html ----------------------------------------------------------------------------- [Image] [Image] [Image] Previous: Lisp's Apparent Failures Up: Lisp's Apparent Failures Next: Good Lisp Programming is Hard The Rise of ``Worse is Better'' I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase ``the right thing.'' To such a designer it is important to get all of the following characteristics right: Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation. Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed. Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness. Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness. I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the ``MIT approach.'' Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation. The worse-is-better philosophy is only slightly different: Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design. Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct. Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency. Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface. Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach.'' I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach. However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach. Let me start out by retelling a story that shows that the MIT/New-Jersey distinction is valid and that proponents of each philosophy actually believe their philosophy is better. Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called ``PC loser-ing'' because the PC is being coerced into ``loser mode,'' where ``loser'' is the affectionate name for ``user'' at MIT. The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing. The New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex. Besides, programmers could easily insert this extra test and loop. The MIT guy pointed out that the implementation was simple but the interface to the functionality was complex. The New Jersey guy said that the right tradeoff has been selected in Unix-namely, implementation simplicity was more important than interface simplicity. The MIT guy then muttered that sometimes it takes a tough man to make a tender chicken, but the New Jersey guy didn't understand (I'm not sure I do either). Now I want to argue that worse-is-better is better. C is a programming language designed for writing Unix, and it was designed using the New Jersey approach. C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%--80% of what you want from an operating system and programming language. Half the computers that exist at any point are worse than median (smaller or slower). Unix and C work fine on them. The worse-is-better philosophy means that implementation simplicity has highest priority, which means Unix and C are easy to port on such machines. Therefore, one expects that if the 50% functionality Unix and C support is satisfactory, they will start to appear everywhere. And they have, haven't they? Unix and C are the ultimate computer viruses. A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus. It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better. The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++. There is a final benefit to worse-is-better. Because a New Jersey language and system are not really powerful enough to build complex monolithic software, large systems must be designed to reuse components. Therefore, a tradition of integration springs up. How does the right thing stack up? There are two basic scenarios: the ``big complex system scenario'' and the ``diamond-like jewel'' scenario. The ``big complex system'' scenario goes like this: First, the right thing needs to be designed. Then its implementation needs to be designed. Finally it is implemented. Because it is the right thing, it has nearly 100% of desired functionality, and implementation simplicity was never a concern so it takes a long time to implement. It is large and complex. It requires complex tools to use properly. The last 20% takes 80% of the effort, and so the right thing takes a long time to get out, and it only runs satisfactorily on the most sophisticated hardware. The ``diamond-like jewel'' scenario goes like this: The right thing takes forever to design, but it is quite small at every point along the way. To implement it to run fast is either impossible or beyond the capabilities of most implementors. The two scenarios correspond to Common Lisp and Scheme. The first scenario is also the scenario for classic artificial intelligence software. The right thing is frequently a monolithic piece of software, but for no reason other than that the right thing is often designed monolithically. That is, this characteristic is a happenstance. The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing. A wrong lesson is to take the parable literally and to conclude that C is the right vehicle for AI software. The 50% solution has to be basically right, and in this case it isn't. But, one can conclude only that the Lisp community needs to seriously rethink its position on Lisp design. I will say more about this later. rpg(a)lucid.com

3 3

Re: signature validation on secure edit messages
by dmandl＠panix.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Good point. But if you turn word wrap off, your message will go out as one long line, or one long line for each paragraph. Most smart mail programs will handle this cleanly, but I assume there are still many that won't. Have all the people who are using PGP with Eudora been sending mail without line breaks? Is this not a problem for 99.99% of the mail-reading software out there? --Dave. At 5:28 PM 2/5/95, Joel McNamara wrote: >Try turning Word Wrap off in Eudora. I was encountering the same thing in the Windows version of Eudora. With Word Wrap on, it seems to add CRs (or CR/LFs on a PC) to the end of each line upon sending. This obviously causes a message not to match the signature, since all of those CRs weren't there when you composed it. With Word Wrap off, your text still wraps on the screen when you're composing, but those unwanted CRs in the sent mail don't get added. > >Joel McNamara >joelm(a)eskimo.com - finger for PGP key > >>Jeez. I really don't know why the heck this always happens to me, my >>digsigs not validating. >> >>You can finger me at tjbryce(a)amherst.edu to retrieve a message with a valid >>signature. >> >>I always write the message in eudora, copy it, sign it in MacPGP as TEXT >>with attached signature, then go back and paste it over the old message. >>Then I go back to MacPGP and check the signature on the clipboard to be >>sure - no problems. But after getting mailed, it doesn't work. >> >>Damn. >> >>Tom >> -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLzWQLZeBqjXzSLLFAQHBbwP+OwhP/d7Yim3/GTY0sI3s17QY4ve+dH6K UoxUboys/VuPFD60gYMdM8LrlxwQksRQm7JWxgp204crKucPZuyOO3ZpZyqiwAmx 23NMf5qtEmxJV5fCPQ8mh61vVeGXOuG7VUA1S+Q3yd7AmZw/PKOllF41VtfmPZvK weRwnYmb7Ho= =q+U5 -----END PGP SIGNATURE----- -- Dave Mandl dmandl(a)panix.com

1 0

Seals and Sealing Waxes
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Perry says: >root says: >> This is the same problem that arose with the original idea of seals once >> the skills of metalworking became commen enough. By the 1500's it was >> nearly impossible to keep a seal confidential more than a few weeks until >> somebody got a impression and built a copy. > >Seals were duplicatable from the start. You just needed clay and a >seal made with the oritinal if you wanted to forge them -- fairly >common stuff. Signatures have been duplicatable from the start, too. "All crypto is economics," and this is what made seals and sealing wax so useful for so long. Saying "seals were duplicatable from the start" does not mean this feat was easy, even if technically possible. In fact, the fine details produced by a good seal are hard to exactly emulate with a copy. Even on a two-dimensional surface. And with the advent of three-dimensional surfaces, which sealing wax made possible, the fine detail of a good seal was in fact very hard to forge. Not impossible, but very costly with the technology of the day. Or even the technology of _today_. After all, paper currency is largely based on seal technology, with various embossing, printing, etc. methods used (on special paper) that remain fairly hard to duplicate. (Not impossible, and counterfeiting flourishes. It's all about economics, and I'm only disputing the claims of easiness. As an added note, transactions in the Far East are still often "sealed" with "chop marks," carved stamps that are uniquely associated with persons or groups.) >Signatures and seals are NOT truly authenticating technologies. They >are just a legal mechanism for an entity to demonstrate that it has >read and agreed to the terms on a document. It was always assumed that >someone might forge a signature, which is why if you had a document >where you cared that people might disclaim their signature, you got >people who could testify to the signature to witness the signing. I think this understates the importance of signatures and seals in these earlier times. --Tim May .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

2 1

Re: "encrypt tcp connections" hacks
by lrh＠PrimeNet.Com 17 Dec '03

17 Dec '03

I realize this may be heresy, but have you considered a hardware solution? Cisco is currently offering a version of their popular routers with a builtin Zylink crypto box... uses either DES or a "proprietary single bit CFB mode" system (maybe RC4?) which is exportable. The boxes are relatively inexpensive. Zylink offers just the crypto box for even less. Both boxes offer DH key management. Lyman To obtain my PGP key, finger lrh(a)primenet.com or see my Web page at http://www.primenet.com/~lrh/index.html

1 0

Excerpts of signed messages
by Hal 17 Dec '03

17 Dec '03

(I forget if this was posted here last year, it sounds familiar.) Suppose I get a PGP-signed flaming message, full of insults, and at the end it says, sarcastically, "For a stupid moron, you've made some very nice postings." I could choose to excerpt this last part, "...you've made some very nice postings", and exhibit it in signed form. What I would do is to run the MD5 hash calculation on the first part of the message, saving the internal state of that calculation. I then publish just that MD5 state along with the rest of the message. Someone can check the signature by initializing their MD5 to that state, then running the algorithm on the part of the message I publish. This will end up with the signed MD5 value from the signature. The checker would know he was dealing with an excerpt, and that it came from the end of the message, but he would have know way of knowing what was in the part that was removed. Presently of course PGP has no mechanism to check such signature excerpts, but that could be added. Under some circumstances this might be a desirable feature. But people would have to be aware of the limitation that the excerptable portion would have to be the tail end of the message. Hal

2 1

dna ink
by Dan Harmon 17 Dec '03

17 Dec '03

I just saw an item on CNN about a company in LA called Art Guard. It sells an ink that is created using your dna as a protection against forged signatures. Interesting. Dan

4 3

Re: Remailer encryption module
by Hal 17 Dec '03

17 Dec '03

From: eric(a)remailer.net (Eric Hughes) > -- The RSA-encrypted session key does not have a flat representation > over its multiword container. This yields a statistical traffic > analysis hole. (This point is irrelevant without fixing 4.) Hal and > I completely solved this problem last year. For reference, here is that old message with an algorithm that produces an encrypted session key with a flat distribution over a specified number of bytes, along with a proof that it works. The purpose of this is you could strip off the PGP header stuff and have a file which looked for all intents and purposes like totally random bytes, but if you knew the secret key then you could decrypt it just fine. (I recently took my CP archives and indexed them using Mark Zimmermann's (no relation to Phil, apparently) FreeText browser which lets me do keyword searches. Pretty nice.) > Date: Mon, 7 Mar 94 08:34:04 -0800 > From: hughes(a)ah.com (Eric Hughes) > Message-Id: <9403071634.AA10351(a)ah.com> > To: cypherpunks(a)toad.com > In-Reply-To: Hal's message of Sun, 6 Mar 1994 11:22:17 -0800 <199403061922.LAA26901(a)jobe.shell.portal.com> > Subject: Truly Stealthy PGP (algorithm) > Sender: owner-cypherpunks(a)toad.com > Precedence: bulk > Status: RO > > >If I understand Eric's general idea, we would keep trying session keys > >under a set of rules which would lead to the desired statistical > >distribution of the encrypted key. > > I actually said nothing about how to get the particular distribution > of keys specified, since that was another issue. I was more concerned > with just getting the one result across. > > >Here is an algorithm which would work. > > It does work, and I'll put down a proof sketch below. > > Notation alert: > >Let L be the next power of 256 above the modulus n. Let t be the integer > >part of L/n, so that L = n*t + s with s in [0,n). Call the PGP IDEA session > >key SK, and the encrypted version of that m = SK^e. Now do these steps: > > >1) Pick a random SK in [0,n). > > This random number in [0,n) is the wrong distribution, but that's OK, > since we'll be throwing some numbers away. > > >2) RSA-encrypt it to form m = SK^e mod n. > > RSA encryption is a bijection (an 1-1 map). If it were not, there > would be two or more possible decryptions for a given ciphertext. > Therefore RSA encryption is a permutation, and a permutation of > probabilities preserves expected values of functions of the > probability, such as entropy. Since we assume the entropy of the SK > is maximal (probabilistic entropy), therefore the entropy of the m's > is maximal. So the m's have a flat distribution. > > (As always, the above statements about bijection hold only if SK is > multiple of one of the divisors of the modulus. But then if you do > find one of those, you've also factored the modulus and thus broken > the key. We assume this doesn't happen, since if it does little of > this matters anyway.) > > >3) Choose a random k in [0,t]. > >4) Calculate the "stegged" encrypted key as M = m + k*n. > > Hal now observes that M is uniformly distributed. This is correct, > and happens because m is in [0,n) and we are adding a multiple of n to > m. This means that each M has a unique represenative as some pair > <m,k>. Since both m and k are independently random (max entropy, flat > distribution), so is M. > > >5) if M is not in [0,L) (i.e. if M >= L) then go back to step 1. > >The idea is that once we get M uniform in [0,(t+1)*n) we can make it > >uniform in [0,L) simply by rejecting those candidates which were too high. > > What we have here is a Markov chain. We have accepting states and > rejecting/retrying states. Since the probabilities in the chain are > independent of each other and are also time-invariant, the > distribution of final probabilities is the same as the distribution of > normalized accepting probabilities. > > In simple terms, you can just retry until you get it right. Since the > probabilities are all the same before, they will all be the same > after, only larger to account for the fact that some possibilities > didn't work. > > [re: rejection and retry] > >This will only happen if k=t and m>=s. > > That's right, and that means that for m < s you have valid k in > [0,t+1) and for m >= s only for [0,t). If you go back an look at the > entropy expression, you'll see exactly this difference in relative > probability for the two parts of [0,n). > > >Now, it seems to me that the worst case for rejection is when n=L-1, in > >which case t=1, s=1, and almost one-half of all initial SK choices will > >be rejected. > > Right, but the worst case for rejection is not the same as the worst > case for entropy loss, which occurs at n=L/2+1 and s=t-1, i.e. at the > other end of the spectrum entirely. > > >Following Eric's reasoning, this would be an effective loss > >of one bit of key length, from say 1024 to 1023, which is tolerable. > > Actually not. The loss of effective key length happens based on the > posterior distribution of the session keys, not on the number of > rejections that happen in the process. > > >Using this algorithm with the current Stealth PGP would produce a > >"truly stealthy" version which I think would be indistinguishable from > >random bytes without access to the receiver's private key. > > Indeed. Observe, though, that as far as deployment went, this would > require modification to PGP itself for it to be anything like > widespread. > > Eric

1 0

Re: finney's perl scripts
by Hal 17 Dec '03

17 Dec '03

From: anonymous-remailer(a)shell.portal.com > hal , gotta question regarding your perl scripts . > i ran em thru sh and d/l'd em , and here are the > results of my tests . first , i pgp'd a file in > binary format , then ran " perl pgppadt.pl > test.pgp 10 " . the error i got was " Couldn't > create test.pgp.pad " . so i renamed the file to > " test " and tried again with good results ! i got > " Input file test has size 732 bytes 10 bytes > pgppad returns code -3 " . then , iran " perl > pgppad.pl test 10 " and after the bit about perl > running under dos/4gw protected mode , i get dropped > to my command prompt . i took a look at the file , > and it's size wasn't any different , so i renamed the > file to test.pgp and ran it again and got the same > results . so i guess i'm wonderin' if it added the > padding , or what might be the problem ? for your > info , i'm using perl 4.0. Unfortunately, my PC's disk died several months ago so I don't have one right now. pgppadt.pl sets the output file name with: open (OUT, ">$ARGV[0].pad") || die ("Couldn't create $ARGV[0].pad\n"); This doesn't work on DOS since it appends .pad to the input file name so it doesn't fit the 8.3 character format. The other errors you are getting are probably due to the difference between binary and ascii I/O mode on DOS. I forgot about that in my test script. Try this revision of pgppadt.pl, and let me know if it works on DOS: ----------------------cut here------------------------------ # Test program for pgppad.pl, showing how to use it. # Revised 2/5/95 for DOS legality # Usage: perl pgppadt.pl infile <bytes-to-add> # Output file is infile, stripped of extensions, with .pad appended. require 'pgppad.pl'; open (IN, $ARGV[0]) || die ("Couldn't open $ARGV[0]\n"); $outfile = $ARGV[0]; $outfile =~ s/\..*//; open (OUT, ">$outfile.pad") || die ("Couldn't create $outfile.pad\n"); binmode IN; binmode OUT; $padding = $ARGV[1]; @stat = stat(IN); $size = $stat[7]; print "Input file $ARGV[0] has size $size bytes\n"; print "Output file $outfile.pad will have size ",$size+$padding," bytes\n"; if (($code = &pgppad (IN, OUT, $size+$padding)) < 0) { die ("pgppad returns code $code\n"); } close (IN); close (OUT); print ("Done\n"); ----------------------cut here------------------------------

1 0