December 2003 - cypherpunks-legacy

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

17 Dec '03

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

1 0

Differences in key generation
by Matt Thomlinson 17 Dec '03

17 Dec '03

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

1 0

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

17 Dec '03

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

1 0

RSA Key Size & QP
by catalyst-remailer＠netcom.com 17 Dec '03

17 Dec '03

A wild card here is the recent work in quantum computing, done at AT&T and reported in a recent post by Pal Vitanyi. With a specialized quantum computer (not clear yet whether one could economically built it, but it's theoretically possible) one can factor in polynomial time (computational class "QP", or something like that). If cycles on such a computer would be, say, 1,000 times more expensive than on your PC, then cracking the key would be 1,000*O(keysize^c) more expensive than generating it, not 1,000*O(c^keysize). Having a keysize of, say, 8 kbits instead of 1 kbit in this circumstance is not at all overkill; it makes a practical economic difference. Of course if your info is _very_ valuable and the polynomial is of small degree, even a large key size won't help much. If such a device was built, we'd want to switch to a cryptosystem whose inverse is not in QP; but some of our current communications would be compromised. If a QP machine is with even small probability feasible within the next few decades (or whatever your timeline of concern is), it makes sense to use larger key sizes.

5 6

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

17 Dec '03

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

2 1

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

17 Dec '03

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

1 0

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

17 Dec '03

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

1 0

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

17 Dec '03

I was surfing off the edges of my page and came across a page about secure http/mosaic. The page is: http://hoohoo.ncsa.uiuc.edu/docs/PEMPGP.html I include ASCII of this below. -- Vince Using PGP/PEM encryption This document is formatted roughly like a FAQ. Here are the section headings: What is PGP/PEM encryption? How are they used in HTTP? What do I need to use it? How do the keys get distributed? How bulletproof is it? Installation: server side. Installation: client side. What does the protocol look like? What is PGP/PEM encryption? PGP and PEM are programs to allow you and a second party to communicate in a way which does not allow third parties to read them, and which certify that the person who sent the message is really who they claim they are. PGP and PEM both use RSA encryption. The U.S. government has strict export controls over foreign use of this technology, so people outside the U.S. may have a difficult time finding programs which perform the encryption. How are they used in HTTP? We have implemented a system by which NCSA Mosaic and NCSA httpd call external programs which encrypt and decrypt their communications and thus provide secure communications between the server and the client and ensure that a user is who he/she says they are. This system currently has hooks for PEM encryption as well as PGP encryption. As interest in this area grows, more will most likely be added. What do I need to use it? You will need a working copy of either Pretty Good Privacy or RIPEM to begin with. You should be familiar with the program and have generated your own public/private key pair. You should be able to use the TIS/PEM program with the PEM authorization type. I haven't tried it. This tutorial is written assuming that you are using RIPEM. How do the keys get distributed? Currently, we have implemented this protocol with PEM and PGP using local key files on the server side, and on the client side with PEM using finger to retrieve the server's public key. As you can tell, parties who wish to use Mosaic and httpd with PEM or PGP encryption will need to communicate beforehand and find a tamper-proof way to exchange their public keys. How bulletproof is it? Pioneers get shot full of arrows. This work is currently in the experimental stages and thus may have some problems that I have overlooked. There aren't any that I can see but I've been looking at it for a long time. There may be some quirks in the additions to Mosaic and httpd as well. In particular, error recovery is not always as helpful as it could be. The only known problem that I know about is that the messages are currently not timestamped. This means that a malicious user could record your encrypted message with a packet sniffer and repeat it back to the server ad nauseum. Although they would not be able to read the reply, if the request was something you were being charged for, you may have a large bill to pay by the time they're through. Installation: The Server Side First, you must compile httpd with CFLAGS set to -DPEM_AUTH. This will enable the PEM and PGP authentication directives. Next, look in the support/auth directory. This directory contains your encryption and decryption scripts, as well as bins for your remote users' public keys. Edit ripem-dec, ripem-enc, pgp-enc, and pgp-dec and follow the instructions therein. You need not set up PGP if you don't plan to use it, and same with RIPEM. Now, edit your server configuration file, usually conf/httpd.conf. You will want to add three new directives for PGP and three new directives for PEM depending on which you plan to use (or both). PEMEncryptCmd /usr/local/etc/httpd/auth/ripem-enc PGPEncryptCmd /usr/local/etc/httpd/auth/pgp-enc These directives change what executables httpd will look for when it is trying to encrypt its reply to a client. Edit the pathnames to taste. PEMDecryptCmd /usr/local/etc/httpd/auth/ripem-dec PGPDecryptCmd /usr/local/etc/httpd/auth/pgp-dec These directives change what executables httpd will look for when it is trying to decrypt the client's request. PEMServerEntity webmaster(a)foobar.org PGPServerEntity webmaster(a)foobar.org These directives set your entity name. This should be the same as the name you place on the public/private keys you generate for your server. If you make these directives different than the key names, your server and its client will become hopelessly confused. You are now ready to protect directories of your server with this authorization scheme. For a directory you want to protect, you should first set its AuthType. Use AuthType PGP for a directory you are protecting with PGP and AuthType PEM for a directory you are protecting with PEM. The require directive accepts key names as its arguments. The AuthGroupFile directive is valid as well, to create groups of keys. A full example: AuthType PEM AuthGroupFile /httpd/.htgroup-pem Options None <Limit GET> require user robm(a)ncsa.uiuc.edu require group pemusers Let's say /httpd/.htgroup-pem reads: pemusers: pls(a)ncsa.uiuc.edu In this case, this directory will be protected with PEM encryption and will require that only users robm(a)ncsa.uiuc.edu and pls(a)ncsa.uiuc.edu be allowed to access that directory. Installation: the Client Side First, get a copy of Mosaic/X 2.2. If it hasn't been released yet, be patient. Compile it with -DPEM_AUTH to enable PEM/PGP authentication. Follow the instructions in each of the scripts in the auth subdirectory to customize them to your setup. There are six new X resources which have been defined for PEM/PGP authentication. They are: Mosaic*pemEncrypt: /X11/robm/Mosaic/auth/ripem-enc Mosaic*pemDecrypt: /X11/robm/Mosaic/auth/ripem-dec Mosaic*pemEntity: robm(a)ncsa.uiuc.edu Mosaic*pgpEncrypt: /X11/robm/Mosaic/auth/pgp-enc Mosaic*pgpDecrypt: /X11/robm/Mosaic/auth/pgp-dec Mosaic*pgpEntity: robm(a)ncsa.uiuc.edu You should change the Encrypt and Decrypt entries to reflect where you are going to install your encryption and decryption crypts. You should change the Entity lines to the key name you have given the server maintainers for yourself. If you don't, bad things will happen. What does the protocol look like? This protocol is almost word-for-word a copy of Tony Sander's RIPEM based scheme, generalized a little. Below, wherever you see PEM you can replace it with PGP and get the same thing. Client: GET /docs/protected.html HTTP/1.0 UserAgent: Mosaic/X 2.2 Server: HTTP/1.0 401 Unauthorized WWW-Authenticate: PEM entity="webmaster(a)hoohoo.ncsa.uiuc.edu" Server: NCSA/1.1 Client: GET / HTTP/1.0 Authorization: PEM entity="robm(a)ncsa.uiuc.edu" Content-type: application/x-www-pem-request --- BEGIN PRIVACY-ENHANCED MESSAGE --- this is the real request, encrypted --- END PRIVACY-ENHANCED MESSAGE --- Server: HTTP/1.0 200 OK Content-type: application/x-www-pem-reply --- BEGIN PRIVACY-ENHANCED MESSAGE --- this is the real reply, encrypted --- END PRIVACY-ENHANCED MESSAGE --- That's it. Almost all of this stuff is my fault (including the implementations), so direct comments about it to me. Rob McCool, robm(a)ncsa.uiuc.edu

2 1

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

17 Dec '03

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

1 0

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

17 Dec '03

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

1 0