- cypherpunks-legacy - lists.cpunks.org

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

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

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

Re: MacPGP2.6
by Jeffrey I. Schiller 17 Dec '03

17 Dec '03

Hmmm. I just tried and was unable to reproduce your problem. I created a secret keyring which contained two keys. MacPGP2.6 happily let me select either one. How did you wind up with two keys? Did MacPGP generate them both or did you import one (or both) of them? What actually happens when you attempt to use the one that MacPGP doesn't want to use? -Jeff P.S. We might want to move this conversation to pgp-bugs(a)mit.edu

2 1

One man's view on Clipper...
by Michael Wilson 17 Dec '03

17 Dec '03

Cypherpunks... just thought I would contribute my two cents on the recent developments, by showing you a response I wrote to a friend on the issue recently. I've been building anti-Clipper sentiment in some 'old school' businessmen friends of mine, since my belief is in free markets and money trails... === >Many thanks for the messages -- Clipper is still bothering a bunch of >people including me, and I hope the cyberworld will do something organized >about it. If I were more competant in computers than I am I would be >willing to lead the charge. The politics of Clipper are insidious. If it actually gets passed off as the standard, it will show up in pretty much any standard product that will hook into the grid. Most people, since there is already encryption built into the products they use, won't advocate the use of anything else, and more importantly, won't PAY for anything additional. I can tell you from experience, people won't buy security products, there is no security market; security is something that people expect to get built in to a system. The only reason that there is any market to speak of at all is a symptom of just how bad the current security situation is--essentially, most systems, including critical ones, are wide open, and you can certainly say that secure communications make up less than 1% of the total amount of traffic on the grid. So what happens when Clipper gets in? People once again abdicate responsibility for handling their own security and secure communications. Why pay more (money, time, effort) when it is already taken care of? The market for competing products dries up; interest dies. If there is no money, how can you expect to pursue a product or create a market? There is no perceived need to address. And so Big Brother wins; they once again become the only experts in the field, since they are the only ones with the money to continue playing the game. Direct outlawing of the technology would only make martyrs of the people trying to present it. Instead, the government is striking in a much more intelligent and, from my viewpoint, dangerous strategy. Their [govt] encryption scheme is good enough... Yes, there are holes, but only to 'hackers'... People who want to have secrets must have something to hide... Only criminals will need to protect themselves, and have additional security and cryptography.... The folks at NSA have struck a blow from a very advanced PsyOps perspective, rather than a cryptographic one. They destroy the marketplace, and also attack any popular support that could be put to good use by the opposition [cypherpunks]. Does this outlaw other cryptographic methods? Not at all; there is the fiction of choice still available (the old game of "let them hold free elections as long as we get to choose the candidates"). Cypherpunks and others who are concerned will be the 'lunatic fringe.' And their more secure traffic will stand out like a sore thumb; somebody somewhere will be making lists. So at this stage, I am increasingly convinced that the solution, actually the groundrules of the game, are not technical at all, but belong solidly in the realm of political warfare. It just so happens that I know more than a little about that game. === The rest of the communication is confidential, but I thought you folks would appreciate some additional thoughts. Michael Wilson Managing Director, The Nemesis Group An old hand at political warfare...

1 0

Re: NSA and competence
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

>Do not, however, assume that they do not know and perform their job to the best >of their abilities, or you will be in the position of the mark talking to a >cardsharp: 'I'm not any good at cards, but I sure do like to play for money.' OTOH, one need not assume that everyone at NSA is a rocket scientist and that they are miles ahead of us in this game. The long undistinguished history of federal agencies shows them to be full of incompetence, waste and usually gross fraud as well. Considering the huge budget and lack of accountability, NSA seems an unusual place to look for an exception. A truly competent and efficient government agency that can hold its own against competition from the private sector is a rarity indeed. Granted, NSA had a head start of a few decades, yet it would be surprising if their lead at this point is more than negligible. Yes, I have read Bamford (though - sorry - not Kahn): remember that Bamford's book is already 12 years old and was probably out-of-date WRT the technology when it was published. <not the same anonymous author>

2 1

GILMORE IN THE SUNDAY PAPER
by Sandy Sandfort 17 Dec '03

17 Dec '03

C'punks, John Gilmore has a hot op-ed piece in the business section of the San Francisco Examiner entitled, "Strong Cryptography a Must." Lots of good stuff. My favorite was, "...we want the public to see a serious debate about why the Constitution should be burned in order to save the country." Gee, I'm glad John is on *our* side. S a n d y

2 1

Re: anon service at vox.hacktic.nl
by usura＠vox.hacktic.nl 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- There are basicly two remailers at vox.hacktic.nl : - -> a cypherpunx-style remailer with three adresses -) nobody -) remail -) remailer - -> a anon mail back ID remailer -) anon Sometimes you may find it conveniant to have te ability to receive mail, but to remain anonymous for the sender. anon(a)vox.hacktic.nl gives you that ability. Here is some info: {step 1} send some mail to ping(a)vox.hacktic.nl to receive a pong and an account ie. an0(a)vox.hacktic.nl {step 2} send your first message to anon(a)vox.hacktic.nl, the commands for remailingare similair to the cypherpunx-remailers, the only differance will be the sender. If you send mail to remail(a)vox.hacktic.nl, the name that will appear in the FROM: line is nobody(a)vox.hacktic.nl. If you send mail to anon(a)vox.hacktic.nl the corresponding entry for the adress that is sending the mail will be in the FROM: line, ie an0(a)vox.hacktic.nl so someone can contact you by sending mail to an0(a)vox.hacktic.nl. This mail will not be anonymised, you -will- know the sender. If you - -as a sender- want to remain anonymous send the mail trough a remailer or aquire a anon account at vox.hacktic.nl and send the mail using the anon(a)vox.hacktic.nl remailer. {step 3} make -absolutily positively- sure the header pasting tokens [::] are the first thing you type, if you start with a blanc line, your remail request -will- fail. Hope this helps. -----BEGIN PGP SIGNATURE----- Version: 2.6 for VoX Labz. iQCVAgUBLg4Ki1nfdBSNVpE9AQG+jgP+PUmaqszGp+aMelflYXOOin47Zu+dVIqX 25Ry356L3/dGD2rMKYZMTK3P1+ly4F4ildgh/Gf5zQiqTh4Ry4L0zG8z3/xYEzwJ vNun9e6zREXGhnaFx9W/7Da67AHfhe38hvcO15riG9Jl4sEQWAXCkqQmyj+05KFx oxxt2XbkQ+U= =Rg9Y -----END PGP SIGNATURE----- Regz, -- ____ Alex de Joode <usura(a)vox.hacktic.nl> \ /__ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- \/ / "It's dangerous to be right when the government is wrong." \/ --Voltaire --finger usura(a)hacktic.nl for PGPKEY -kinky-

1 0

Sternlight
by Bill O'Hanlon 17 Dec '03

17 Dec '03

Has anyone else noticed that David Sternlight has been quiet for the past two weeks or so? I hope he's not like you-know-who in that mentioning his name summons the fiend. ObCrypto: Maybe he has decided that PGP 2.6 is okay, and now has had the wind removed from his sails... Doubt it. -Bill

2 2