- cypherpunks-legacy - lists.cpunks.org

Zimmermann charges dropped?
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Apologies if this has been discussed and I somehow missed it. I just got back from Monte Carlo last night and have briefly scanned the 500+ accumulated messages, not seeing this item mentioned. Drew Taubman (sp?), the new Executive Director of the EFF, told me that in recent days the grand jury meeting in the PRZ case did in fact decide to go forward with the indictment. However, says Drew, the judge in the case dismissed the charges after looking at them, apparently in about an hour or so. He cited the absence of relevant law in the case (as I understand it, the argument being that there is no law against what PRZ did, i.e., "make code available" in such a way that _others_ might then access it and perhaps then illegally export it (assuming such export might be later proved to be illegal). Drew went on to tell me that the judge said there would need to be a relevant law on this, and that Senator Leahy and his staff (recall their involvement in the Digital Telephony Bill) are already at work drafting such legislation. I haven't seen mention of this, so I thought I'd mention it here. I could of course try to get confirmation first from Phil, but he is notoriously hard to reach in e-mail, ironically, and this seems sufficiently important to mention to the list. And if you can't trust the EFF, who _can_ you trust? (Don't answer that.) --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero | 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. Cypherpunks list: majordomo(a)toad.com with body message of only: subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay

1 1

Re: BROKEN REMAILERS
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

>I have tested remailers and their PGP keys over some time now and this is >what I have found: > >MIXMASTER is a great, fast and reliable remailer but you can't PGP with it. > >REMAILER(a)NATELY.UCSD.EDU is just as fast and reliable (same guy) and you >can use PGP, but a few weeks ago it started acting really funny: It will >forward any ATTACHED files, but it will only read the first commandline >of a PGP block that has been pgp'ed with Nately's public key. In other >words, if you wrap layers of chained remailers inside each other, you >will now have to have NATELY as the *last* link in your chain as it will >otherwise discard the rest of the block. Alternatively you can have the >chain as a series of attached files. > I am not sure what is going on with remailer@nately. I just tested it, sending a PGP encrypted message chained through it 3 times, I also sent a message chained through nately to c2. They both worked fine. Are you using a program to build the chain, like "Chain"? If so, which? Mixmaster now has a PGP key (it has had one for a long time for testing purposes, this is a new one). The front end for using mixmaster remailer type 2 messages is on my WWW page. Right now it only runs on Suns. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAy8y6PAAAAEEAJF05HUUQM4n9G5wHOZ+bHZbF6yFmeX5wBGElssHqUnbb4PQ S/f8jWvJyfiZkjlOkzOEJ47fZ++x+yYWgzKGUKp2ejIKu2MvnzgLfIkwKfxioPXq xgBpLcFaDrbM52Mi4MEpEYW4DJqxk9TrAnHZBwXmxpOZQ57UcgbmF1BLzawNAAUR tC5NaXhtYXN0ZXIgUmVtYWlsZXIgPG1peG1hc3RlckBuYXRlbHkudWNzZC5lZHU+ iQCVAwUQLzLpflVkk3dax7hlAQH2GQP9FGBU7uGako4YghrUNzyb3tcdwZwsGkBx Gy9MGojOSwWgXQ0CRLD9+IWgkZnRY902pU65C3IZhFB7erXBk5eyGOXhbahHv07o mhHRiE2v4Z9hNapWVHHeDo0F2AoL7B8kkiFjXI2fVYzofB6gmXd7X8Wzh/9AEQsz 63U8X9cbajyJAJUDBRAvMulXBuYXUEvNrA0BAQOkA/9QfgNGLp6MX1Qwk55uLiHG ajeT+Rtgruaj9DPOoZFVj9w0pImBkCQNw5eA6iZTgiAqkbSG7RaR9yKMU27Gf/O+ yz3cWAx4slFmCpVDlEl5qSa1Bd+2LuneN4EvnxfeI7TLUIFKlPcIOnx9zsu5Ny0I SCtHVHBaGw43OT1OYmLjgA== =Zr4D -----END PGP PUBLIC KEY BLOCK----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Check out my essay on the next generation remailer Mixmaster on the WWW page. For anon remailer info, mail remailer(a)nately.ucsd.edu Subject: remailer-help "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

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

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

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

"encrypt tcp connections" hacks
by strick at The Yak 17 Dec '03

17 Dec '03

Perry, could you enumerate them? I take your opinions more seriously than perhaps I should, so I want to understand what you're saying. I'm not doing this to re-invent the wheel. I'm doing it because I need it, and nothing else is working very well for me. I'm doing it because I don't see anything that's easy-to-use in wide use today. I don't just want one or two encrypted applications -- like the Kerberos telnet and rcp -- but something to transparently provide privacy for all TCP sockets -- like SMTP sockets between (re)mailers, NNTP, X11, FTP, MUDs, etc. Let me name the ones I can think of. 1. Matt Blaze just announced one. As always, he has the best crypto. But his world interface seems to be a hacked up script.c. If I lift his crypto, and make it a standard module in Skronk, I can reuse 90% of his good work. 2. Kerberos4. I use Kerberos4 between home and work all the time. However the only command I have that actually encrypts the session is the "rlogin" replacement. (But I sure use it, even if it's just DES.) Also Kerberos administration is a nightmare. I'm a fairly knowledgeable crypto hacker and unix system administrator but honestly I don't understand what I did. If it weren't for the Cygnus installation manuals giveing line-by-line instructions, I wouldn't have made it. I've taken the reference manuals to bed with me several times, but still haven't gotten a grasp of how to fully use it. And the reason big providers like The Well and Netcom won't run kerberos (or at least not the last time I asked) is that they would have to hire another person just to do the password management etc. Skronk should be "just plug it in and it works". There should be no reason why big providers can't offer it as an option. 3. Kerberos5. I've been unable to build Kerberos5 on my sun3. Honestly. To build it, I have to have ISODE, which seems to be some enormous ISO thing that I haven't been able to build. Again, not too encouraging for your average unix sys admin. 4. The new telnet program with Telnet Options for authentication and encrytion. Well it won't do encryption unless you can get the authentication done, and so you're back to problems 2 and 3 above. I couldn't get it to work in an evening, and decided the world needed something better. Also even if it did work, it's only Telnet. None of the other apps I named above can use it. 5. Standards for IPng. Vapor, as far as I know. Is there any usable code, that works in IP this generation? I think it comes down to the fact that, of these, only Skronk and Blaze's software use a Diffee-Hellman -like Key Exchange so that administration stuff doesn't have to be done by humans and footnet. The real value I'm adding is not the crypto. It's the packaging. When I'm done it should be possible to skronk all your current clients and servers by just overriding the shared library libc.so, running a skronk map UDP daemon, and customizing a configuration file to tell the daemon what to say. ================= As for the UDP service: > UDP won't get through most firewalls. > > Build in support for non-transparent firewalls (ie: telnet gatekeeper, > c sys port). UDP packets are for automatic configuration of skronk maps. Skronk maps could be announced other ways too -- including via manual configuration, where you put skronk maps in your SKRONK_CONF environment variable. I may have to spend more effort on this than I wanted to. I have a SKRONK_CONF variable, and an option to say "dont ask the UDP skronk map daemon" about this port, just skronk it -- but right now it's only dependant on port number, not on the IP address too. This can be fixed. > UDP Port 333 - does this imply you need to be root to use it, > at least as a server, or are only TCP ports typically root-limited > for low-number ports? > Bill You need to be root to install it properly on your system, for the skronked services to become bona fide system services. Users should not be able to hijack SMTP and TELNET connections to a site unless they're root. For people who run their own web server on a nonstandard port on a machine that someone else administers -- we're back to the manual configuration method. Maybe we can build a PGP service with signed certificates to collect nonstandard skronked services. But really I think these services will be marginal. I had thought about using DNS TXT records. But I decided against that because a *lot* of people have autonomy over their workstation on the net, but not over their DNS records. Linux boxen in dorm rooms come to mind. Or anyone who puts a new machine on someone else's ethernet, grabbing an IP address via ARP. ================= Thanks to everyone for your comments. The discussion question is -- if we have so many hacks already -- howcome they're not in use. I hope I found the reasons and addressed them. The firewalls issue bugs me a bit. Would using a well-known TCP port instead of the UDP port fix the problem? I don't think so. Firewalls will block my new TCP port as well. Matt Ghio's project to tunnel through the telnet port sounds good. Of course, that defeats the purpose of the firewall, which is not my aim. My aim is to work with the internet and within its policies, so it can get widespread use. How much of skronk works today? I'm nearing alpha of a version that's hardwired to do DH exchange (using RSAREF2.0) and IDEA CBF (stolen from PGP sources) for the symmetric encryption. But I broke it recently when I added hacks for servers to fake select() listening on both skronked and normal ports, when the program only thinks it's only listening on normal ports. I gotta go ... strick ================== p.s. need some wizard-level help here. I use syscall(2) when I reimplement read() write() connect() accept() etc. on SunOS. On LINUX I borrowed code from the libc sources. On HPUX and Solaris and AIX I'm having difficulty finding a way to do what system calls do, without using the manufacture's packaging. any help would be appreciated.

8 10

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

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

New directions in anonymity (needed)
by Mike Ingle 17 Dec '03

17 Dec '03

There has been a lot of talk about anonymity and the best ways of providing it recently. Anonymity now is about where cryptography was before Diffie and Hellman's paper, or untraceable transactions before Chaum. To use it, you have to trust someone, or at least a group of people. All of our anonymous systems boil down to only two techniques: indirection and broadcast. Indirection is sending a message through one or more intermediate nodes to conceal its point of origin. Broadcast is sending a message to multiple recipients to conceal the intended recipient. Indirection is somewhat secure for anonymous-to-known messaging. Properly done, all intermediate nodes must be compromised to reveal the anonymous sender. It is entirely broken for allowing replies to an anonymous person. To allow a reply, a traceable path must exist back to the anonymous person. Having obtained whatever piece of data is used to send a reply, the attacker can trace this back one node at a time. Kludge all you want, but there is no good solution to this. You can make the path disappear when it is used, but if the attacker gets it first, there is nothing you can do. Broadcast is exactly as secure as it is nonscalable. If you broadcast to 100 people, an attacker's uncertainty is one in 100. The security grows linearly with the overall bandwidth. For cryptographic-level security, it would need to grow exponentially with bandwidth. Anonymity needs something fundamentally new, something comparable to public key for cryptography or blind signatures for digital cash. Suppose a server has a large file. A message comes in and is combined into this file. Another message comes in with a key to retrieve data. The server processes the retrieval key against this large file and comes up with an output, which it returns to the person doing the retrieving. This output contains the input message, transformed in such a way that even the server cannot match it to the input that produced it. This is what we need. It would require three keys: an encryption key, a selection key, and a decryption key. The sender uses the recipient's encryption key to encrypt the message, then sends it to the server. The server mixes the message into its file, but cannot identify the encrypted file as destined for a particular recipient. The recipient's selecting key extracts the data, but the data extracted does not resemble the data the sender sent. The decryption key, kept private by the recipient, is necessary to return the data to its original form. The server must be unable to link the data from the sender to the data sent to the recipient, and this is the hard part. A method like this would permit anonymity without trust, much as public key allows secrecy without trust and digicash allows transaction privacy without trust. Is there any way to do it? There are functions like the Fourier transform that can distribute data over a large file, but the inverse function gives you back the same data. We need the not-so-inverse function to give back a different piece of data, but one that can be converted, by a private key, into the original, which the server never sees. Mike P.S. Have any of the "beta testers" actually tested RSAREF for Perl? RSA gave me permission to call the random number and DES routines, so I am ready to add that in and release the code.

4 4

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