December 2003 - cypherpunks-legacy

PGP's ubiquity (was Re: NRC Session Hiss)
by Bruce Baugh 17 Dec '03

17 Dec '03

At 09:15 PM 6/2/96 -0700, Lucky Green wrote: >That PGP is ubiquitous is subject to discussion. PGP is widely available, >but that doesn't mean that it is widely used. What percentage of email is >PGP encrypted? Less than half a percent? Much, much less than that. I get about five hundred messages a day. On the average day, none of them are PGP-encrypted. On the average _week_, none of them are PGP-encrypted. And by virtue of having a PGP key signed and on the servers, I'm better prepared to send and receive such mail than at least 99.9% of the net.population. >PGP was a failure in the mass market, regardless how popular it may be >with some subscribers of this list. True, and important. In one sense it doesn't matter how good a security system is if a manageable set of people are the only ones using it. There are only a few thousand IDs in the key servers, and vast majority of those, I'd guess, are like me in not using PGP routinely. But even if we were, the institutions of the State have experience in the long-term surveillance of groups quite a bit larger than us. This is where I think some forms of cyber-elitism fail. So I've got access to darned good tools. The State has numbers and resources, and memes about how the masses do right when they acquiesce, on its side. We are not, I think, particularly secure in an environment where the very fact of using secure tools stands out from the herd. But what the herd needs are good tools with good simple front ends, and a) those who design the tools generally don't care about the herd and so do nothing to get outside the crypto ghetto and b) those in a position to design the front ends generally have more immediately rewarding things to do or don't know about the tools themselves. Five years ago I was quite optimistic about strong security as an important element in bringing about the post-statist society I desire. Now I'm pessimistic. I just don't see signs of the stuff spreading sufficiently. And while S/MIME has interesting features (based on what I've read so far), the default 40-bit setup is basically no protection at all. And I know just how hard it is to get people comfortable using non-default features. -- Bruce Baugh bruce(a)aracnet.com http://www.aracnet.com/~bruce

1 0

Crypto APIs Considered Harmful
by tcmay＠got.net 17 Dec '03

17 Dec '03

A typo when I wrote: 2. Eliminates a reason for controlling the distribution and export of browsers, mailers, newsreaders, etc. Imagine the glum reaction of the NSA when they realize that they can't control these programs, because the "crypto hooks" are only the hooks to basic message payloads...and they control these. ^ *can't* I meant to include the "can't." A Web browser with no hooks for crypto absolutely will not be export-controlled. But if users in Slovakia and Beninia can _see_ the messages, as they of course can, then crypto programs they supply themselves can of course see and act on the messages. (Copying to a clipboard, for example, and lots of other ways.) No way the NSA can control that. Concentrating on integrating crypto tightly into commercial programs is playing the NSA's game. --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: Java Crypto API questions
by br＠doppio.Eng.Sun.COM 17 Dec '03

17 Dec '03

|Unfortunately, the feedback address that Sun provides in the slides is |unknow to their mailserver (at least it was last week) and no further |information seem to be avaiable about their "public and open" policy. In the actual talk, I said "will be public and open", that is when we actually announce the policy it will be public and open. The things that are certain about it is that it will be constrained only by export considerations, and that we'll sign competitors' packages. I am hoping that I can get a spec document for the API ready by the end of the month. By then we will have more details regarding the export stuff. In the meantime, I'll see if we can get an interim FAQ together. The security-api(a)java.sun.com address should be working now. -- Benjamin

1 0

Re: Fate of Ecash if RSA is cracked?
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 5:04 AM 6/3/96 +0000, Greg Miller wrote: >On Sun, 2 Jun 1996 17:42:49 -0500 (CDT), you wrote: > >>What would happen with all ecash that's been issued? Of course >>criminals would be able to forge large amounts of authentic-looking >>ecash, so banks should not be honoring requests to convert e-cash into >>real cash. > > As I understand it, ecash shouldn't be withdrawn until shortly before >it >is spent. If the RSA algorithm is broken, then then banks could refuse the >withdrawal (and depositing) of money as ecash. The remainder of the money in >each users' account would have to be withdrawn through conventional methods. > > Of course all the outstanding (between withdrawl and deposit) ecash >could be a problem. Banks running Digicash might be able to credit you account for cash on your disk using the same mechanisms they use to recover your ecash after a hard disk crash. You shouldn't need too much electronic identification since the only result is to move money to yourself. ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

Re: Java Crypto API questions
by jim bell 17 Dec '03

17 Dec '03

At 11:20 AM 6/3/96 -0400, RHS Linux User wrote: > > >On Mon, 3 Jun 1996, Jeff Weinstein wrote: > >> Andrew Loewenstern wrote: >> > >> > Sun can export the signature though. The vendor already has the package, >> > they just need the sig/cert... >> >> Not likely. Sun will probably be required to agree not to do this >> as a condition of exporting software with "pluggable crypto". Software >> with hooks for crypto functions is treated the same as the actual crypto >> as far as the ITAR is concerned. > >When Microsoft announced their crypto API, they also announced that their >signatures on crypto modules would be export-restricted. That doesn't mean that they are, LEGALLY, export-restricted. Microsoft can't generally bind third parties to agreements with the government. Even in circumstances where it might appear that they can enter into an agreement with a customer, Microsoft is sufficiently big that any terms it forces on customers are automatically suspect of being oppressive, especially if there is no valid business reason for a particular restriction. Besides, a violation of any such agreement is merely a violation of an agreement with Microsoft, not the USG. It is unlikely Microsoft is going to take individual customers of their customer to court for violation of some no-export agreement. > According to >e-mail I received from a Microsoft employee on the project, the act of >signing was considered a "defense service" under ITAR, so exporting the >signature would somehow be performing defense services for foreign >persons. Even if it is arguable that the signing of a piece of software constitutes a "defense service," that service is performed for somebody, domestically, who delivers that software to Microsoft. Once that software is signed, the "defense service" is over and done with. At that point, you merely have an object, a signature, which cannot encrypt or decrypt data. It is even less useful than a microprocessor or RAM at facilitating encryption. It makes slightly less sense to me than the rest of the crypto >export restrictions do, but I guess that's the deal that Microsoft worked >out with the Feds in order to be allowed to do a crypto API at all. I think you've hit the nail on the head: The Feds were well aware that Microsoft had plenty of money to challenge them in court, and they would almost certainly have lost. So the Feds gave in on the API issue, and in exchange Microsoft agreed to publicly state that "the signatures on crypto modules would be export-restricted." Doesn't make it so. Jim Bell jimbell(a)pacifier.com

1 0

Crypto APIs Considered Harmful
by tcmay＠got.net 17 Dec '03

17 Dec '03

There are obviously lots of snags and restrictions being imposed on crypto APIs. "Hooks for crypto" lead to trouble of various sorts. Well, we've talked about this before, but I'll say it again: * For now and for the foreseeable future, maybe the focus should be on better and more efficiently integrating crypto (e.g., straight PGP) with the _contents_ of programs (e.g, the innermost pure text blocks, such as what you are now reading). The integration can be done separately and orthogonally from the basic crypto package, just as PGP did. * This is largely, in my opinion, what made PGP so popular. Whether one had a PC. a Mac, an Amiga, various flavors of Unix, etc., one could send and receive messages with PGP to other users, regardless of their platforms or their choice of mailers, editors, word processors, newsreaders, or browsers. This was because PGP was a "payload-centric" (to coin a phrase) program. * PGP did not need to know any details of the message headers, MIME sorts of stuff (though a MIME field for PGP exists, as I understand it). Thus, there were no "hooks" in PGP for specific mailers, editors, etc., except things people added later. * Better integration is needed between crypto and mailers, editors, Web browsers, but then this runs smack into the "crypto API" issue. (It also narrows the richness of applications, in the sense that if a lot of work goes into "Netscape 4.x with S/MIME," as a likely example, then there are fewer combinations of crypto + tools.) Thus, it seems to me that we gain more overall leverage, and more flexibility, and less hassle from the ITAR folks, if more of the focus is kept on the "crypto API" it is essentially impossible to control: the message payload. So long as ASCII (or Unicode, increasingly) message blocks can be handled by a variety of editors, mailers, news programs, browsers, etc., it will be impossible to stop users from using crypto on these blocks. But if crypto is tied to specific browsers, mailers, etc., this gives the NSA and ITAR office a way to impose limits. I think there are a _lot_ of advantages to maintaining orthogonality, to _not_ more tightly integrating crypto with mailers and browsers. Sure, it would be very nice if hooks existed. But the fact is that this gives the NSA an avenue for restricting export of programs (e.g., Netscape), and such restrictions may cause companies like Netscape to compromise by giving _everyone_ a "weaker-but-more-tightly-integrated" crypto package. I would rather have a "strong-as-I-wish-but-loosely-integrated" package! (Greater convenience can be handled on a platform-by-platform basis, possibly easier than trying to get industry-wide compliance with a crypto API spec. Thus, on the Mac it is possible to have macros or scripts which take a received message (from whatever source and with whichever mailer, browser, etc.), process the message block, and return the result to another window or as a file. MacPGP mostly works this way, and other enhancements exist as well. At no point was the basic spec for PGP affected, and no "crypto API" was needed....since the fact that we can _see_ and _read_ messages is in fact the crypto API!) * Disadvantages of Not Having Crypto APIs in Popular Packages 1. Many users, especially those just getting on the Net, want "all-in-one" turnkey programs. Not having crypto APIs built into Netscape Navigator, for example, will reduce the number of users of crypto. (On the other hand, if most new users are using Navigator 4.x "now with extra strong 47-bit crypto," they at least get into the habit of using crypto and can "graduate" up to crypto packages external to Navigator, so maybe it won't be a disaster for Netscape to offer NSA-approved crypto APIs, so long of course as external packages can access the message blocks freely.) 2. Not having APIs may affect digital commerce, as robust systems involving many transfer points should have robust links to message internals, and not rely on something so potentially prone to error and glitches as a bunch of macros and scripts. (Can be done, but having a bunch of Macs and PCs communicating with a bunch of clipboard macros...ugh!) * Advantages of Not Having Crypto APIs in Popular Packages 1. Separates the development of strong crypto from the development of browsers, mailers, etc. (I'm not saying Netscape, for example, is developing the algorithms, but by including integrated crypto they are automatically in the loop on developments...and maybe it would be better if they weren't.) 2. Eliminates a reason for controlling the distribution and export of browsers, mailers, newsreaders, etc. Imagine the glum reaction of the NSA when they realize that they can't control these programs, because the "crypto hooks" are only the hooks to basic message payloads...and they control these. 3. Orthogonality and independent development means the _best_ crypto (PGP, S/MIME, whatever...) can be combined with whichever mailers and browsers people want to use. Netscape users will not be limited to S/MIME, for example, with its strange notions of where the signatures belongs, or its default key size. 4. In some sense, the "basic data structure" of nearly all personal communications _is_ the basic ASCII (or Unicode, rich MIME, etc.) message. At least for the things most _personal_ users are now sending. (I acknowledge that business users have needs for richer data structures. As noted in Disadvantage #2, running a commerce system (think of SWIFT) with macros and scripts reaching into message blocks...shudder! But business users can work out separate plans.) 5. Finally, placing more of a focus on the messages and not on crypto APIs for currently popular programs like Microsoft Explorer and Netscape Navigator makes better use of scarce programming resources. And it is, in my opinion, a more "grassroots" and "cypherpunkish" thing to do than to try to work with large corporations to integrate tools into their programs. (The NSA would clearly rather have crypto tools tightly integrated into popular programs, despite what some have said. It gives them control and it's easier for them to jawbone Netscape and Microsoft than a million users.) Obvious points. But in light of all the recent moves to limit deployment of crypto by limiting the "crypto API" approaches, it's useful to remember that for most applications, the message payload is perfectly suited for carrying digital signatures, encrypted blocks, etc. They can't stop the messages, can they? --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: Security of PGP if Secret Key Available?
by Deranged Mutant 17 Dec '03

17 Dec '03

With the MD5 collisions, can it be shown that plaintext passphrases are more likely to map to certain hashes than others? (And hence IDEA key search space reduced?) Just speculation. Rob. On 3 Jun 96 at 2:36, Robert A. Hayden wrote: [..] > However, I got to wondering about the security of PGP assuming somebody > trying to read my PGPed stuff has my 1024-bit secret key. ie, if I have > it on my personal computer, and somebody gets my secret key, how much > less robust has PGP just become, and what are appropriate and reasonable > steps to take to protect this weakness? --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

1 0

Re: Saw this on CNN: Anonymous Stock tips over IRC as bad???
by Duncan Frissell 17 Dec '03

17 Dec '03

At 11:23 AM 6/3/96 -0400, Perry E. Metzger wrote: >No, I'm afraid they aren't. Under the rules, if you have nonpublic >information, even if you are not a corporate officer, you are an >insider for purposes of "insider trading" and your trades are illegal. Though if I trade based on my non public knowledge that the Gray Aliens will strike at Midnight on 31 December 1999, I am probably safe. Doesn't the non-public knowledge have to have been generated or concern internal company information (or the intentions of a publisher or buyer concerning the company). If info that is too far removed is included then any stock analysis system would be illegal. Note BTW that the Feds lost almost all of the '80s insider trading cases that actually went to trial. They only won 2 or 3 that went through the full trial and appeals process. That is a very poor record since prosecutors usually have an 80-90% success rate in criminal trials. >Securities laws are extremely complex, extraordinarily broad, and >subject to extremely flexible interpretation. I would suggest not >attempting to skate a fine line near them -- the ice is very thin. And like most federal criminal procedures based more on hype than reality. One should emulate the head of Princeton Securities who showed up for settlement negotiations with the Feds wearing a "Shit Happens" baseball cap. All charges dismissed on appeal. I do think though that many actual "inside traders" are pretty dumb since it is not hard to trade securities anonymously. DCF

2 1

Idea 'bout banning the internet
by Blake Wehlage 17 Dec '03

17 Dec '03

What if in the future a country banned the internet and all things that had to deal with it (ie- telnet, irc). It would be the "underground" thing. Just a thought, it would really suck! As I think about it it is impossible or is it???? Hell the usa cant even ban porn let alone the whole thing. They could ban it like they did fizzies. Hey there making a comeback did you here now they have nutrasweet in them. If you know what fizzies are than your pretty kewl. I'm only 13 and love then they are the drink of the future!!!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Blake "Pokey" Wehlage Gaa- 3.69 <jwilk(a)iglou.com> Record- 2-4-4 Age- 13 Final Standings- 2nd Place (Beat in Championship) President & Founder: Revolution Software "I have the fastest glove in the east!" Profanity Software "Hackers never stop hacking they just get caught" VSoft My life- Rarely eat or sleep, Hack til' 7:00a, goto school, play goalie til' 8:00p, hack til' 7:00a Hank Aaron- d:-)!-< Pope- +<:-) Santa Claus- *<:-) The Unabrower |:-) Current Girlfriend(s)- Lindsey Wilcox, Laura Schubring Personal Quote- Mr Plow, thats my name, that name aguin is Mr. Plow -Homer Simpson ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: Why PGP isn't so ubiquitous (was NRC Session Hiss)
by Clay Olbon II 17 Dec '03

17 Dec '03

On Mon, 3 Jun 1996, TT <apache(a)quux.apana.org.au> wrote: >I think it is actually easy to use, although granted others may not; but >that people tend not to use it as a matter of course (and it is my belief >this is a desireable thing) due too the time taken to manually sign mail >or sign and encrypt. Lets face it the average user has trouble with a >dos command prompt and until there is a point and click emailer easily >available most people just won't try PGP for email. Most people I have encountered don't use PGP because of the initial learning curve, more than the overall ease of use. I work in a small office that is separate from corporate HQ. I have been trying for over a year to convince people to use PGP for intra-office communication. What I have found is that for people within the office, it is fairly easy - hands-on instruction works well. Convincing folks at HQ has been a royal pain however. Most of the problem appears to be the "you mean I have to learn new software?" variety. Once I have coached someone over the "knowledge hump" (often by phone), they tell me that using pgp is pretty easy. <disclaimer> We use Eudora Light for the Mac, YMMV </disclaimer>. The trick is convincing the user that the benefits associated with using pgp are greater than the initial pain. This is something I have only accomplished with a few people. This educational process will continue to be the stumbling block for widespread use until there is truly seamless encryption. My fear is that seamless encryption will be weak; witness the widespread use of 40bit Netscape and the supposedly 40bit default behavior for S/MIME. I think that export controls are a driver towards weak defaults. OK, that last part was a WA tangent from my "ease of using pgp" thread. It's late and I'm hungry. Sue me. Later, Clay --------------------------------------------------------------------------- Clay Olbon II | Clay.Olbon(a)dynetics.com Systems Engineer | ph: (810) 589-9930 fax 9934 Dynetics, Inc., Ste 302 | http://www.msen.com/~olbon/olbon.html 550 Stephenson Hwy | PGP262 public key: on web page Troy, MI 48083-1109 | pgp print: B97397AD50233C77523FD058BD1BB7C0 TANSTAAFL ---------------------------------------------------------------------------

1 0