December 2003 - cypherpunks-legacy

Microsoft Flame[tm] [NOISE]
by roy＠cybrspc.mn.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- There's a lot of finger waving going on over Microsoft's alleged predatory practices. I just want to remind the pro-MS folks of something. Microsoft has a documented track record of using undocumented entry points in their OS and Windows products. These entry points allow MS apps to do some things more efficiently than a competitor which uses the published API. MS has been known to rearrange these undocumented calls, resulting in sudden incompatibilities with competitors. (remember when Win3.1 came out and DR-DOS was suddenly unable to run Windows?) And in the MS countersuit against Stac Electronics, MS successfully argued that undocumented system calls were protected as Trade Secret material. While this isn't the grand-scale conspiracy some people seem to see, IMHO it's still predatory. Perhaps the call to separate the OS and apps divisions is a good idea. It would be interesting to see if Microsoft could maintain its edge in applications when it had no sub rosa advantage in OS access. - -- Roy M. Silvernail [ ] roy(a)cybrspc.mn.org PGP Public Key fingerprint = 31 86 EC B9 DB 76 A7 54 13 0B 6A 6B CC 09 18 B6 Key available from pubkey(a)cybrspc.mn.org -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMNlXShvikii9febJAQFoGgP/YtHdGqO8++MfZmk3h61F8SmJBfPYfa1R JlccdIP9BZHVXZseao9b9DqxLY1xRYkK6fWETielJaSjXZKam1WlYKFzL5E8Hf1z IXQmj7rCIIfvqvq3byJq8B3IUbT4UnTMNDAHVlNUwkzrcJ+py8czsWtNy15g3ahY NzYL8UsOtwI= =MpV3 -----END PGP SIGNATURE-----

1 0

cyphernomicon
by avatar＠mindspring.com 17 Dec '03

17 Dec '03

If anyone is interested I would be willing to e-mail a copy of the cyphernomicon to you. BEWARE that it is 1.3MB in file size and 414 pages in text. Charles Donald Smith Jr. 582 Clifton Rd. N.E. Atlanta, Ga. 30307-1787 (404)-378-7282

1 0

Re: The Problem With Blaze And Weinstein
by Bob Bruen, MIT Lab for Nuclear Science 17 Dec '03

17 Dec '03

> MIT is practically floating on government subsidies. It's funny how the grass is always greener somewhere else... Bob

1 0

Re: ex encrypted script
by John Pettitt 17 Dec '03

17 Dec '03

At 10:57 PM 12/21/95 -0500, Beavis B. Thoopit wrote: >> >| Is there a way to encrypt a script yet still allow it to be runnable? I >> >| know that the simple answer is to write it in C and compile it but I don't >> >| have the means of doing that at the moment. (i.e. there is not compiler on >> >| the system) >> >| >> >| I thought of a few simple protections but they all involve decrypting before >> >| running. >> > >> > Ever hear of chmod? chown? >> >Adam >> >> The vendor also has superuser access.. chmod chown won't protect it.. :( > >I once had to obfuscate an awk script. "Cryptography is Economics." My >job was to make it difficult for the enemy to steal the source. There >was a license agreement... > >The simple answer of "no" is right in the strong sense, but there are >tricks to make life difficult for the amateur attacker. > >My approach was a self-decrypting program. The "real" script was >encrypted within the body of the encasing script. For increased >obfuscation, decrypt only small pieces at a time. > > There is encrypt and then there is render useless to the reader. A tale I hear is that when HP had to deliver operating system source to the french government they stripped all comments and changed all variable and subroutine names to 32 byte strings of I 1 0 (zero) and O (uppercase O). It still compiled but was 100% useless to human readers. -- John Pettitt email: jpettitt(a)well.sf.ca.us (home) jpp(a)software.net (work)

1 0

Re: Political Cleanup program
by James M. Cobb 17 Dec '03

17 Dec '03

Friend, On 12 17 95 jimbell(a)pacifier.com proposed ...a system...that would "blind" campaign donations as to their source: The donor could be satisfied that his dona- tion gets to the candidate or cause, but the candidate could- n't know who actually paid the money (and the donor would be unable to prove that he made a donation...). Let's analyse: A gives B what B wants (money) so that B will give A what A wants (whatever). A knows B got the money. A can't prove he gave the money to B. B knows he got the money. B can't be sure that A gave the money. So, depending on time, place, and circumstance; and assum- ing B's elected: B will not give A what A wants OR B will give A what A wants For instance, if... A gives the money but dies before B gets elected. A gives the money but gets sent to the Balkans. A is a nobody. ...B will not give A what A wants. For instance, if... A gives the money but B's already in debt to him, and the baloon payment's due. A gives the money and A's appointed head of an office where B's relatives "work." A is the main man in town. ...B will give A what A wants. Some things are known by some people whether they're entered on the books or not. I agree with the proposer that his system ...would change politics as we know it. Flexible corruption is best. Cordially, Jim

1 0

brief review of MIT 12/15/95 "micro-commerce" talks
by james＠sparta.lcs.mit.edu 17 Dec '03

17 Dec '03

This is a quick summary of the Friday 12/15/95 talks at MIT on micro-commerce: Millicent --- Mark Manasse, Digital Equipment Corporation Brokers purchase "scrip" in large batches from vendors; users purchase scrip small batches from brokers; users give small scrip to vendors in each purchase transaction. "Scrip" is vendor-specific and its validity can be efficiently verified using hashing. No public-key crypto is required to carry out the protocols, because pairwise trust relationships between user and broker, and between broker and vendor, are established and these pairs share secrets. PayWord --- Ron Rivest, MIT Users are issued certificates by brokers, indicating that the broker will extend credit to the user. Users generate long hash-chains by repeatedly hashing a random seed value to obtain a hash-chain root. Then the user promises to a specific vendor that he will pay one cent per element of that hash-chain. This promise is made by the user signing (using PKC) the root of the hash chain. Each time the user wants to pay one cent to the vendor, she sends another element of the hash-chain, working backwards from the root, as in the S/Key system. The vendor redeems the whole chain (or whatever portion the user has spent) by sending the user's signed promise and the last spent element of the chain to the broker. MicroMint --- Adi Shamir A scheme for issuing coins that is much more like traditional physical coin systems in that forgery and cheating are possible, but only practical on a large scale, and are detectable and can be combatted. A "coin" in the MicroMint system is a set of 4 values that hash to the same value. Producing such 4-way-colliding values is much less expensive in bulk than individually. The mint produces coins in bulk and will redeem them into cash. To combat active forgers, the mint can embed secrets in the coins and reveal the secrets progressively so that vendors can detect forged coins cheaply. Lightweight Signatures for Revocation --- Silvio Micali, MIT A cost/performance analysis of the key revocation system for the U.S. Federal Goverment's Public Key Infrastructure. Taking a MITRE-designed plan as a starting point, the communications costs are analyzed. In the MITRE plan, the certification authorities issue revocation lists on a semi-weekly or daily basis, these lists being then stored in an untrusted and highly replicated database. When a public key is being checked, the receiver queries the database to determine the status of the public-key. In the talk, Silvio showed how lightweight signatures can be used to reduce the size (and therefore transmission cost) of the revocation lists. He also showed that transmission costs can be dramatically reduced by not sending large revocation lists in response to queries. Instead, the replicated database can store a timestamped key-status-report (signed by the certification authority) for every single key. This key-status-report is much smaller than the full revocation list. Overall, the PayWord scheme is probably the one to watch for actual use on the Internet. Millicent has an advantage of not using PKC, but PayWord may be simpler to implement and is being discussed in the WWW Consortiom and the IETF as a possible draft standard. It is also worth noting that PayWord operates essentially by combining a PKC-signature-based authentication (between user and broker) with a One-Time-Password (OTP) authentication scheme (as in the S/Key system). OTP has been getting standardized recently on the Internet and maybe that will help too.

1 0

Encryption Rules Coming
by John Young 17 Dec '03

17 Dec '03

Financial Times, December 21, 1995, p. 4. Encryption rules to be prepared By Andrew Jack in Paris Representatives of international business and government yesterday agreed to draw up guidelines on encryption, a system which allows computer users to transmit information electronically with little risk that it can be intercepted and understood by unauthorised "hackers". The meeting, which was held at the International Chamber of Commerce in Paris, could lead to formal propositions prepared jointly by business and government organisations that could be ready by as soon as next summer. Yesterday's meeting did not have any formal legal authority, but was highly significant as the first forum where so many representatives of governments businesses and computer experts met to discuss developments in encryption. Highly sophisticated encryption technology already exists in a number of countries including the US and Sweden. In the US, companies already have access to these programs. A growing number of businesses -- led by the banking sector -- are demanding access to these programs. However, many governments, including that of the US, have resisted permitting the technology to be exported because they fear it will fall into the hands of organised crime and terrorist organisations. They have demanded that they should be able to "hack" into computer transmissions for counter-intelligence and criminal investigation work, in the same way that they can conduct telephone-tapping exercises. An important conclusion of yesterday's Paris meeting was that business agreed in principle to allow such hacking to take place as long as sufficient safeguards were in place and "electronic search warrants" had been issued with proper judicial approval. A number of governments appear willing to permit relaxation of export controls on sophisticated encryption devices as long as these safeguards are in place. Among the issues that experts on both sides need to resolve are the ways in which "keys" allowing computer transmissions to be decoded would be handled. A number of business organisations have discussed the use of third-party organisations, which would be independent of government, would have the keys and would hand them over to government investigators when demands were justified. However, the organisations still have to resolve a number of issues, including how these custodians could be made legally liable for any unauthorised access to this information and for the costs of its misuse. [End] ---------- Does anyone have press reports or more information on this meeting? Any connection to the recently signed Transatlantic Agenda?

3 2

Re: The Problem With Blaze And Weinstein
by James A. Donald 17 Dec '03

17 Dec '03

>ECafe Anonymous Remailer wrote: (A bunch of ridiculous nonsense) At 01:48 AM 12/21/95 -0800, Jeff Weinstein wrote: > I am against GAK. I have been contributing to [...] Please do not reply to silly trolls. By replying, you act as if what this loon said mattered. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

just a reminder...
by Perry E. Metzger 17 Dec '03

17 Dec '03

This isn't anti-trust punks... ...or microsoft punks... ...its cypherpunks... ...Just a reminder. .pm

1 0

FWD: Intuit and SSNs
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

What does our man in Intuit have to say about this? > Date: 18 Dec 1995 19:10:07 -0800 > From: michael(a)piglet.amscons.com (Michael Bryan) > Subject: SSN Shown On Payments by Intuit's Banking Service > Organization: none > > Another user (Robert Mayo) discovered, and I confirmed, that Intuit's > online bill payment service sends your payees a printout containing > your social security number. > > This applies to any person who is using Quicken for Windows or > Microsoft Money for Windows to send payment requests electronically, > using Intuit's service. It specifically does -not- apply to using > Quicken with the Checkfree service, as the Checkfree service does not > supply anybody with your SSN. > > The details: > > When the Intuit service sends a payment to a merchant, it will do one > of three things. First, it will try to perform an EFT directly from > your account into the merchant's. Most merchant's are still not setup > for this, however. Second, if your payment is the only payment going > to a given merchant on a given day, then they will print a check, drawn > against your account, and mail it to the merchant. Both of these > methods are ok, and do not result in your merchant receiving your SSN. > > However, if there are multiple payments going to a single merchant on a > given day (i.e., more than one customer has requested a payment to the > given merchang), all of these payments are sent in a single envelope, > and a summary sheet is enclosed. This summary sheet will have a field > called "Control Number", which consists of your SSN, followed by two > other digits. This summary also lists your checking account number, in > addition to your name, account with the merchant, and the amount of > your payment. (In my opinion, only these last three fields are called > for. There is no need for the checking account number to be listed, > even though it -is- printed on your check as part of the MICR > encoding.) > > I have contacted Intuit regarding this matter, and they have been > decidedly less than helpful. I know at least three other people who > have called them, and we have all been told the same thing: > > 1) "Most of your merchants already have your SSN". Perhaps this is > true for some people, but it is not the case with me. > > 2) "The SSN is encrypted on the printout". Absolutely not true. It is > printed under the label "Control Number", and has two extra digits > appended, but this does not "encrypt" the number. Anybody who knows > what the field contains has instant knowledge of your SSN. > > Intuit is currently refusing to address this issue. Furthormore, when > I called in, they tried to tell me I was the only person who was > complaining. I immediately gave them the names of three other people > who had called in, one of whom I knew had talked to this particular > individual. So that little "divide-and-conquer" trick backfired. > > Also, when I said that I would be forced to go to the media if they > didn't address this issue, I was told that by doing so, I would be > responsible for broadcasting this information to those who might then > illegally use the information. I found this two-faced attitude > particularly annoying. On the one hand, they are claiming it's not a > problem, yet on the other they tried to keep me from going to the media > because it might give criminals information they could then exploit. > > Anyway, I've done all I can with talking to Intuit, so I am now > pursuing other avenues. My bank (Union Bank) was particularly > concerned that the SSN was being printed out and mailed with > potentially every payment, and vowed to look into it and work with > Intuit on my behalf to get this behaviour stopped. Also, I and a few > others have contacted various media representatives, in an attempt to > get them to focus a spotlight on Intuit, and let people know that > Intuit is broadcasting their SSN, without their knowledge. And of > course, I'm posting Usenet articles in the privacy newsgroups, as well > as the newsgroup where most Quicken discussion occurs, > comp.os.ms-windows.apps.financial. > > If you are using Intuit's Online Bill Payment service, and are > concerned about this, please call Intuit and express your displeasure. > The number for the Online Bill Payment service is 708-585-8500. Also, > call your bank, and inform them as to what's going on. Finally, write > to your local (or national) newspaper, let them know about this, and > ask them to cover this in their paper. > > It appears that the only way Intuit is going to address this is by > getting some negative publicity, since customer complaints don't seem > to carry enough weight. I wish they were more reasonable, but that > just doesn't seem to be happening here. So be it --- they want a > fight, they've got one.

2 1