December 2003 - cypherpunks-legacy

If I were the NSA...
by jf_avon＠citenet.net 17 Dec '03

17 Dec '03

If I were the NSA, I would start threads such as the one on the IPG system. They are very valuable to them in assessing and mapping the cryptanalysis capabilities of the CPunks lurkers and regulars members. Just a thought... JFA Public Key at http://w3.citenet.net/users/jf_avon Jean-Francois Avon <jf_avon(a)citenet.net> 2048 bits key ID:C58ADD0D 1996/03/01 fingerprint=52 96 45 E8 20 5A 8A 5E F8 7C C8 6F AE FE F8 91

1 0

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)extropia.wimsey.com> cpunk pgp special"; $remailer{"portal"} = "<hfinney(a)shell.portal.com> cpunk pgp hash"; $remailer{"alumni"} = "<hal(a)alumni.caltech.edu> cpunk pgp hash"; $remailer{"bsu-cs"} = "<nowhere(a)bsu-cs.bsu.edu> cpunk hash ksub"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"hacktic"} = "<remailer(a)utopia.hacktic.nl> cpunk mix pgp hash latent cut post ek"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post reord"; $remailer{"rahul"} = "<homer(a)rahul.net> cpunk pgp hash filter"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"ford"} = "<remailer(a)bi-node.zerberus.de> cpunk pgp hash ksub ek"; $remailer{"vishnu"} = "<mixmaster(a)vishnu.alias.net> cpunk mix pgp hash latent cut ek ksub reord"; $remailer{"robo"} = "<robo(a)c2.org> cpunk hash mix"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"spook"} = "<remailer(a)spook.alias.net> cpunk mix pgp hash latent cut ek reord"; $remailer{"rmadillo"} = "<remailer(a)armadillo.com> mix cpunk pgp hash latent cut ek"; $remailer{"ecafe"} = "<cpunk(a)remail.ecafe.org> cpunk mix"; $remailer{"wmono"} = "<wmono(a)valhalla.phoenix.net> cpunk mix pgp. hash latent cut"; $remailer{"shinobi"} = "<remailer(a)shinobi.alias.net> cpunk mix hash latent cut ek reord"; $remailer{"amnesia"} = "<amnesia(a)chardos.connix.com> cpunk mix pgp hash latent cut ksub"; $remailer{"gondolin"} = "<mix(a)remail.gondolin.org> cpunk mix pgp hash latent cut ek reord"; $remailer{"tjava"} = "<remailer(a)tjava.com> cpunk mix pgp hash latent cut"; $remailer{"pamphlet"} = "<pamphlet(a)idiom.com> cpunk pgp hash latent cut ?"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{'gondonym'} = '<alias(a)nym.gondolin.org> alpha pgp'; $remailer{'nymrod'} = '<nymrod(a)nym.alias.net> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk pgp hash latent cut ek"; $remailer{"treehole"} = "<remailer(a)mockingbird.alias.net> cpunk pgp hash latent cut ek"; $remailer{"nemesis"} = "<remailer(a)meaning.com> cpunk pgp hash latent cut"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"vegas"} = "<remailer(a)vegas.gateway.com> cpunk pgp hash latent cut"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk pgp hash latent cut ek"; $remailer{"ncognito"} = "<ncognito(a)gate.net> mix cpunk latent"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. Groups of remailers sharing a machine or operator: (c2 robo alpha) (gondolin gondonym) (flame hacktic replay) (alumni portal) (vishnu spook wmono nymrod) Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. Note: The remailer list now includes information for the alpha nymserver. Last update: Mon 18 Mar 96 6:46:10 PST remailer email address history latency uptime ----------------------------------------------------------------------- ecafe cpunk(a)remail.ecafe.org ##-++####### 3:40 100.00% alpha alias(a)alpha.c2.org ++++++++++++ 50:30 99.99% exon remailer(a)remailer.nl.com *-*++--++*** 18:54 99.99% portal hfinney(a)shell.portal.com ##-**#*#-**# 11:12 99.99% haystack haystack(a)holy.cow.net +#-+-**##**# 6:30 99.99% pamphlet pamphlet(a)idiom.com --+-------++ 5:49:56 99.98% nymrod nymrod(a)nym.alias.net **-++*****+* 8:47 99.98% flame remailer(a)flame.alias.net -----------+ 4:03:33 99.97% hacktic remailer(a)utopia.hacktic.nl **-++******* 13:46 99.97% replay remailer(a)replay.com **-++***+*** 10:42 99.97% mix mixmaster(a)remail.obscura.com . - *--...+- 21:59:57 99.97% c2 remail(a)c2.org -+*++++-++++ 44:35 99.96% tjava remailer(a)tjava.com ###++####### 1:08 99.96% vishnu mixmaster(a)vishnu.alias.net **--+*+*--++ 53:01 99.94% nemesis remailer(a)meaning.com -+-+ **+**** 36:11 99.86% gondolin mix(a)remail.gondolin.org .__.-----.- 9:38:20 99.66% gondonym alias(a)nym.gondolin.org .__.-----.. 9:42:41 99.63% extropia remail(a)extropia.wimsey.com .-.-+-+---- 11:49:50 99.57% shinobi remailer(a)shinobi.alias.net **#++##-+#++ 6:52 99.53% lead mix(a)zifi.genetics.utah.edu ++ ++ +*+++ 35:26 99.39% vegas remailer(a)vegas.gateway.com ** +-- * *** 15:07 99.36% alumni hal(a)alumni.caltech.edu ** ++# *-+## 1:34:05 98.76% amnesia amnesia(a)chardos.connix.com +--- 2:30:51 97.82% treehole remailer(a)mockingbird.alias.net ---- -++-+ 2:50:06 96.47% penet anon(a)anon.penet.fi _-._.. _.. 38:20:41 95.24% spook remailer(a)spook.alias.net **-+-**- + 46:36 93.05% ncognito ncognito(a)gate.net ##* 1:21 87.38% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

No Subject
by Gary Lee Jeffers 17 Dec '03

17 Dec '03

>From STRATEGIC INVESTMENT March 20, 1996 Strategic Investment 1217 St. Paul St. Baltimore, MD 21202 It is published monthly for US$159 per year for U.S. residents (C$190 for Canadian residents and US$200 for other non-U.S. residents). behind the lines - by Jack Wheeler Is the IRS a paper tiger? One definition of a pioneer is a guy with an arrow in his back. So notice the above headline is a question, not an assertion. But it is nonetheless a question being asked by a lot of folks these days, from Bill Archer, Chairman of House Ways & Means, to a number of smart tax attorneys. The federal tax code has mutated into this gigantically in- comprehensible Rube Goldberg monstrosity that day by day gets closer to collapsing under its own weight. Couple that with the fact that the IRS computer system is about to go belly up. The IRS originally computerized itself AD HOC, with the regional centers getting various platforms and software that can't communicate with each other very well. The agency has now spent over $8 billion on the TSM project to re-computerize, which an independent review recently concluded is a colossal failure. As the IRS teeters on the brink, a fellow named Eddie Kahn has stepped forward and may be about to push the whole creaking mess over the edge. He hasn't got an arrow in his back yet, so he might just succeed. Dis- dainful of "tax protests" such as 5th Amendment or legal tender arguments that quickly get their advocates behind bars, Eddie looked into the stru- ture of federal law. When Congress passes a law, codified as a statute, it then delegates to a regulatory agency the authority to issue the im- plementing regulations specifiying to whom and under what circumstances the statute applies. These regulations must, by law, be published in the Federal Register. Lacking these implementing regulations, the law cannot be applied and has no force. Well, it turns out that the implementing re- gulations for IRS' enforcement statutes-things like the requirement to file a tax return and the authority to place a lien-cannot be found in the Federal Register. When queried on this, the General Counsel for the Office of the Federal Register, Michael White, replied in writing, "Our records indicate that the Internal Revenue Service has not incorporated by reference in the Federal Register a requirement to make an income tax return." This is starting to get interesting, isn't it? And yes, I see that big smile on your face. If Eddie is right, the IRS has no assessment autho- rity, no collection athority to enforce a lien or seize property, no au- thority to pursue criminal penalties for failure to file a return or make a false/fraudulent return. I am not at all suggesting you be a pioneer. But if you should have any difficulty with the lovable folks at the IRS, you might consider making an appointment to see them in person at their nearest office, and tell them face to face that you need to see a copy of the implementing regs published in the Federal Register that show they have the authority to require you to do what they want. Not one of the close to a thousand people who, following Eddie's advice, have done so received a copy-and not one has been further harassed. Better to let these folks drop out of the system quietly than risk a negative decision in court, which would be for them an ultimate catastrophe. You can get more info from Eddie at: 1-800-419-7512. --------------------------------------------------------------------- PUSH EM BACK! PUSH EM BACK! WWWAAAYYY BBBAAACCCK! BBBEEEAAATTTT STATE! Gary Jeffers P.S. This reminds me of something else that I read a few months ago. There is a book with the title The Law that Never Was - the 16th Amendment (this was the title or close) that had a similar affect on the IRS. I believe it was the SPOTLIGHT that said that when the then Commissioner of the IRS found that the book was published, he gave gave instructions that people citing the book in arguments with the IRS be left alone. The 16th Amendment created the IRS.

1 0

No Subject
by mixmaster＠vishnu.alias.net 17 Dec '03

17 Dec '03

ipgsales(a)cyberstation.net wrote: >Those of you who have had all of the materials will understand the >foregoing. With the information provided heretofore, you can determine >the effect on the other two systems. Also, those people will know my >expressed fear of a premature announcement, such as that which has >now been made, would have. This was the reason, that I resisted >so strongly the release of the materials to the C'punks list >though a few of you recommended that I do so. Perhaps we should have >released everything? Who knows. However, in any case, that is water >over the dam and IPG must go on from here. It is only another of the many >mistakes that we will undoubtedly make along the way. > >Having said that though, we must go back to our prior >evaluation method, a strict confidential mode. However, I believe that we >have added several very good additional people who can help to analyze >the system. English translation: We didn't want to release our algorithm because we were afraid somebody might find a weakness. Sure enough, somebody did. So I guess we're going to keep it a secret after all. Hey, kids, security through obscurity just doesn't work.

1 0

Re: Would the FTC crack down on snake oil someday?
by Deranged Mutant 17 Dec '03

17 Dec '03

On 19 Mar 96 at 19:10, Bill Stewart wrote: > Sure, they'll be happy to, if we really want. The NSA will advise them > on what's good crypto, and what's snake-oil. Certainly any system that > didn't provide for back-up key access doesn't rate...... > > No, I didn't think you wanted that either.... Maybe the NSA will advise them, maybe not... since there is a conflict of interest (not unusual in regulatory circumstances, though). Then again, it would be awkward if the NSA hypothetically said product A is crap and product B is secure but non-NSA people said differently, esp. if the NSA wouldn't let product A be exported. They're a governmental organization, with all the flaws of any organization/bureaucracy, let alone the government. So yes, I've pondered them asking the NSA for advice... but keep in mind it puts the NSA in a double-bind, because they aren't the only experts, and because they'll look bad if they contradict themselves. They (FTC) might go by something different, though. If a company claims their product uses an "unbreakable cipher" when there are cracking programs (commercial or free) available, then obviously its false advertising. Indeed anything that advertises itself as "unbreakable" is a lie. There's also other consumer groups that are non-governmental, like Consumer Reports, PIRGs, and even various state and county consumer advoctates who won't tow the federal line (look at bovine growth hormone for one example... hm, maybe a bad parallel.) Part of it is a public learning curve. After a while more people (though not enough to eliminate snake oil's market) will recognize "PGP", "RSA", 'IDEA", "3DES" and other strong algorithms. (Ascom Tech could do themselves a nice turn by pushing for products with "IDEA Inside" type of messages...) Rob. --- Send a blank message with the subject "send pgp-key" (not in quotes) to <WlkngOwl(a)unix.asb.com> for a copy of my PGP key.

1 0

Spare CFP '96 student reservation
by SINCLAIR DOUGLAS N 17 Dec '03

17 Dec '03

A friend of mine registered as a student for the CFP '96 conference next week, but is unable to go. Registration is transferable, so he can send another student in his place. If anyone is interested, please mail him (not me) at tew2(a)cornell.edu.

1 0

Mr Emmett Page, Asst. Sect. Defense, CCCI
by Tim Fulbright 17 Dec '03

17 Dec '03

I think you or someone here recently remarked the U.S.Government has the only _real_ capability to wage world terrorism on the internet, and after I read Frank Sowa's feb. Boardwatch article I'm beginning to wonder. I suppose quoting the article at length will be at least as good as some of the other traffic around here... just in case anybody missed it, Sowa reviewed 35 federal reports, and quotes Page saying "As a result, we've had no choice but to create an offensive capability in cyberspace. I can't discuss it ... However, you'd feel good and feel safe and secure if you knew about it" (yeah, really) Further, Sowa reports the Natl Defense U is forming an elite Information Corps, 'a F0rce whose scope is to fight the battles of "Information Warfare from the Pentagon war room to the home PCs" according to DOD' (p90-92).... And further, RAND corp is using an "all out cyberwar simulator at their research center in Santa Monica" and... oh well, the whole article is just crammed with stuff! Yikes! I would sure like to know what people think about it. thanks.

2 1

Re: The return of the IPG Unbreakable System (fwd)
by David K. Merriman 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 07:24 PM 03/19/96 -0600, you wrote: ... <sniveling excuses deleted> ... >Accordingly, this will be the last letter posted to the entire >cypherpunks list for the time being. If any reader posts something to the >entire Cypherpunks list, do not expect any response to from IPG, there >will be none. Thank you, thank you, thank you! (see? there *is* a God!) Dave Merriman -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMU7xkcVrTvyYOzAZAQGCSAQAj3wI2g4R6W8/iEhRaYn1y3SwfhS5g2UT 0BpdsUqNbJXA3Qbj4OlrT2SSWp7Glm4uymlJVM1AjXo36Jjo3XTZilMeTaVed5DW idH8gfV/Wp6DJIPv3RqwtYysBur1pXgqmsEIEovIHhY7uP5yhW7JJL2NrZ/Dht4T 3DvZ/On3cdk= =+acg -----END PGP SIGNATURE----- ------------------------------------------------------------- "Giving money and power to government is like giving whiskey and car keys to teenage boys." P. J. O'Rourke (b. 1947), U.S. journalist. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> http://www.shellback.com/personal/merriman/index.htm

1 0

Re: Dorothy Denning attacks Leahy's crypto bill
by jim bell 17 Dec '03

17 Dec '03

At 09:45 PM 3/19/96 -0800, Declan McCullagh wrote: >I may have to adjust my position on Leahy's bill. Any legislation that >Dorothy Denning attacks so virulently must be worth passing. That position would be a serious mistake. Denning knows that she is a negative barometer: Her position will be looked on with contempt by most of us. That, ironically, makes her "useful" to the government should they want to sneak one past us. I think we've already established that this bill sucks, although it could become good with major repairs. Problem is, nothing that Denning wants to do to the bill constitutes an improvement, except not passing it in the first place! ----------------------------------------------------------------- > >Date: Tue, 19 Mar 96 14:53:35 EST >From: denning(a)cs.cosc.georgetown.edu (Dorothy Denning) >To: farber(a)central.cis.upenn.edu > March 14, 1996 > >The Honorable Patrick Leahy >United States Senate >Russell Building, Room 433 >1st and C Streets, NE >Washington, DC 20510 > >Dear Senator Leahy: > >As author, scholar, lecturer, researcher, and consultant to the >government and industry in cryptography and information security, I am >concerned that S.1587, the "Encrypted Communications Privacy Act of >1996," is not in balance with society's needs. By removing practically >all export controls on encryption, the bill will make it far easier for >criminals, terrorists, and foreign adversaries to obtain and use >encryption that is impenetrable by our government. "Far easier"? That's an odd statement, because the export of encryption is easy with or without restrictive laws. How much trouble is a "criminal or terrorist" going to risk by violating a few measly export laws? Besides, Denning hasn't established that encryption will be any better inside the country than without; this means that export controls will have no effect even in the most optimistic scenario. >The likely effect >will be to erode the ability of our law enforcement and intelligence >agencies to carry out their missions. Since when is this news? Freedom costs. But it also pays. > This is not consistent with your >own findings in the bill which recognize the need for a "national >encryption policy that advances the development of the national and >global information infrastructure, and preserves Americans' right to >privacy and the Nation's public safety and national security." > >I am concerned that the proposed legislation responds only to a loud >cry for assistance and is not the reasoned and practiced position of >our multinational corporations. Of what significance is the "practised position of our multinational corporations"? They'd sell us out if it preserved THEIR rights. I'm more concerned with the rights of the individual. > At the International Cryptography >Institute, which I chaired in September 1994 and 1995, our discussions >did not find that this unrestricted distribution of encryption >technology was required to satisfy business objectives. Notice that we've already established that this bill in no way produces an "unrestriction distribution of encryption technology." Wish it did, but it doesn't. [much Denning-crap deleted] >The Commerce/NSA study did acknowledge that the existence of foreign >products claiming strong encryption could have a negative effect on >U.S. competitiveness. However, by allowing encryption services to be >sold separately from the applications software that uses them, CAPIs >will make it extremely unlikely that general-purpose software will be >substantially effected by export controls. That's odd. Most people around here seem to be of the opposite opinion: CAPI's seem to be used by the government to justify controls even on software that has no encryption capability. Even security-specific >products, which are a growing industry, can use CAPIs to separate out >the encryption component from the main product (e.g., firewall). >Moreover, if keys can be held in other countries under appropriate >bilateral agreements as noted earlier, export controls need not >substantially impact encryption products. Notice that she seems to be making policy for the government, yet again. > >Export controls are often blamed for the lack of security in our public >infrastructure. The Commerce/NSA study found "little evidence that >U.S. export controls have had a negative effect on the availability of >products in the U.S. marketplace," although they "may have hindered >incorporation of strong encryption algorithms in some domestic >mass-market, general-purpose products." There are many factors which >have played an even larger role in the general lack of security we find >on the Internet: the high cost and low demand for security, the >difficulty of designing systems that are secure, pressure to bring new >products to market before their security implications are understood, >the willingness of users to take risks in favor of acquiring new tools >and services, and lack of a public key infrastructure to support >encryption on a national and international basis. Many systems are so >riddled with security holes that any would-be attacker can gain access >to the system itself, and from there access to plaintext data and >keys. Malicious code can be injected into a victim's system through >electronic mail, documents, images, and web browsers; once there, it >can transmit sensitive data back to its owner. Keyboard sniffers can >capture a user's keystrokes before they are ever encrypted. Thus, >while export controls have played a part in the slow integration of >strong encryption into software and systems, they are not responsible >for most of the security vulnerabilities we see today. Moreover, most >of these vulnerabilities are remedied with non-cryptographic controls >(e.g., process confinement, trusted systems engineering, biometrics, >and location-based authentication) or with cryptographic techniques for >authentication, data integrity, and non-repudiation, which are exempt >from State Department export controls. I do not mean to suggest that >encryption is not important. In fact, it is essential to protect >against certain threats. However, it must be kept in perspective. The >use of encryption for confidentiality protection is but one small, >albeit important, piece of an information security program. > >The provisions is S.1587 regarding trusted key holders could have the >benefit of increasing public trust in key holders. However, I have >some concern that the current provisions may be overly restrictive. >Thus far, we have practically no experience with the operation of third >party key holders and the circumstances under which they will be called >upon to provide keys or decryption assistance. It will be extremely >important that the provisions allow enough flexibility to accommodate >legitimate use of the data recovery services of key holders for >criminal investigations, civil litigation, and intelligence >operations. The liability risks to key holders should not be onerous. >The definition of key holder and exact wording in the bill may also >need some refinement in order to accommodate existing and proposed >methods of trusted third party encryption. > >Encryption policy is a difficult and often emotional issue. It's only emotional because of malicious and counter-productive efforts by government, and government suck-ups like Denning. It is >important that Congress work closely with the Administration, industry, >and other interested parties to develop the best legislative strategy >for promoting information security on the national and global >information infrastructure without diminishing the ability of our law >enforcement and intelligence agencies to protect the public safety and >national security. Export liberalization should proceed cautiously, >tied to key escrow or other methods that accommodate the needs of the >government as well as those of users and industry. The >Administration's plans to liberalize export controls on software key >escrow is a good next step. As trust and confidence in key escrow >grows, the export of virtually unlimited strength encryption systems >may be possible. Because export controls are our only lever for >controlling the spread of encryption, they should be used to their full >advantage. Decisions to liberalize these controls must be fully >informed by classified national security information as well as by >economic analysis and market studies. > >Law enforcement agencies are encountering encryption with ever greater >frequency. Excellent! It means they're being held back! > Within a few years, the successful execution of practically >all court-ordered intercepts and searches and seizures is likely to >depend on their ability to decrypt communications and stored >information. If the encryption cannot be broken, it could be >impossible to successfully investigate or prosecute those cases. Bullshit! [more Denning-shit deleted] >I will be pleased to meet with you and the committee for comment and >questioning, or to assist in any way I can with the development of a >balanced approach to encryption legislation. > >Yours respectfully, > >Dr. Dorothy E. Denning >Professor of Computer Sciences >Georgetown University >denning(a)cs.georgetown.edu >http://www.cosc.georgetown.edu/~denning I refuse to be used by Denning. If we make the mistake of supporting this bill merely because she claims to oppose it, we would merely be falling into her (and the government's) trap.

1 0

RE: Microsoft's "answer" to Java
by Blake Coverett 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Commenting on a quote from a magazine about MS's new code-download/wintrust stuff Alan Olsen wrote: >As a web developer, I have some problems with this scheme. Giving Microsoft >access to virtually every OLE control on the Web does not make me more >secure. Sounds like a way to rip off ideas from the rest of the development >world. If someone has a control that might compete with a Microsoft >product, it could be shelved and/or delayed for "further security testing". I think you've been badly misled on this one. I've just been through all of the related specs from the MS INetSDK. While they are still incomplete in places, they look pretty workable to me. In particular the certainly don't suggest that MS would be involved in signing anything. To quote from the beta docs: The present tools therefore allow any user of this development release to authorize themselves as a "Software Publisher" for test purposes and to sign their code, allowing for extensive testing of the tools and code used but not actually providing a secure infrastructure. In future releases, the tools will require software publishers to obtain certificates from companies whose function is to verify the identity of the publishers, providing end-users with a high level of assurance about the authenticity and origin of code that they receive. >Java has a decentralized mechanism for security. No one group controls what >is a "certified" control and what is not. You write the code and compile it >and that is that. Furthermore, you are not stuck with Microsoft approved >platforms. (I wonder if there will ever be a version of Explorer for the Mac.) The current version (2.0) is already available on the Mac and the 3.0 alpha versions appear to be about equally buggy on both the Win32 and Mac platforms. (I haven't, on the other hand, heard any news of Unix versions. Perhaps Bristol and/or Mainsoft will cover that port.) ================ Here's my quick overview of the specifications in question for those interested. Microsoft is providing the following components: - - A generic trust management called (ever originally) WinTrust. WinTrust provides an API to ask whether a given subject is trusted to perform a specific action. The API is extensible in that multiple 'Trust Providers' can be installed and each can define the types of subjects and actions they manage. The docs define the role of a 'Trust Administrator' who can configure the rules used by the trust provider services be neglect the give the details. - - An implementation of a trust provider called the 'Windows Software Publishing Trust Provider' This provider supports subjects which are executable images and the action of 'being published software'. The decision to trust is based on a PKCS #7 embedded within the executable containing a signed digest from the author and a chain of X.507 certs back to some configurable set of CAs. If the executable is not verified the user is prompted with the offer to approve it manually. - - A set of developer tools for creating your certificate and signing executables. Note that the beta includes a hard-coded root CA key and all certs must trace back to it. The existing library for munging executable images has also been enhanced to support adding, removing, enumerating and retrieving certs from an image as well as reading the stream that should be included in digest calculations. - - A single function solution for browsers and other applications to download, verify, install, and create a class factory for an OLE object given an URL. In the web case the HTML <OBJECT> tag is used to embed an OLE object in a page. The browser tries to create it based on the CLSID attribute (which contains a DCE-ish uuid.) If it fails it calls CoGetClassObjectFromURL() passing in the URL from the CODE attribute of the same tag. This function does all the magic including the WinTrust call from above. (Apparently there will also be support for an 'Internet Search Path' if the CODE attribute isn't specified.) Then of course there is the MS CryptoAPI but that's a discussion for another day. - -Blake (who hasn't worked for Microsoft for years now) -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMU/Dirmr67p11D8rAQGHnQP/YI+EjCIcpBF3HQznruVBUkGsZls1ZVTf SRvPJN7n+HrtvQ4WFSyAawsPnhRH183GTrtWAy+yhmmuzA6/Br/+rNJ/q0jSIlZw w+RUsni9H9a7NsO1Y9xPQq//SHODYC0K+1vB6tU8XE56lZf9F0IZ4iP4El4PUWxD 7kXMboN1Nf0= =5eH2 -----END PGP SIGNATURE-----

1 0