December 2003 - cypherpunks-legacy

Re: Federal Key Registration Agency
by William Knowles 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- On Wed, 19 Jun 1996, Igor Chudov wondered: >Lucky Green wrote: > At 16:27 6/18/96, TM Peters wrote: > >Speaking to the Commonwealth Club of California in San Francisco, Reno said > >her plan would require people to register with the new agency the secret > >codes -- or "keys" -- they use to encrypt messages online. > >: The cat is out of the bag. Janet Reno is calling for mandatory Government >: Access to Keys. Not that her statement would surprise anyone on this list. >: Still, I believe the administration has never before publicly stated that >: people will be _required_ to deposit their encryption keys with the >: government. I wonder what the penalties for failure to comply with this >: requirement will be. > A couple of questions [admittedly, I am not the best expect in American > politics]: > 1) Is there anything real that individual citizens can do? Keep your PGP262.zip disks in ziplock bags and cache them in the backyard, forests,The golf courses. Get a GPS location and escrow the locations with with trusted friends using Secret Share. Payout to Jim Bell's AP service. Move to Canada? William Knowles erehwon(a)c2.org Finger for public key -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMcke1AURbnwsNLz5AQHmMQQA2TFznKaMSM9uayXkvpcq/SsYg1hLnNKW 4v+NKSAVoDSGyn96VPxH1zEDP+dHk2MS173ocIUcaCm3VzRbBp6qnukAzTjGxjns PVFFS5dsicx+wR4LFxWhUy/7fjvP6BUTLUwPvQGuXZyh8jof1uuL8FYXPtku6tSG a78TvfAgknU= =IZFJ -----END PGP SIGNATURE-----

6 5

Oil Change software snoops through hard drive
by declan＠well.com 17 Dec '03

17 Dec '03

Alan forwarded this to me. Thought it might be interesting. -Declan ------------------------------- Heads up: Privacy & Continuous Access Ks implicated by new software This press release for a new product - a software agent - has implications for privacy and continuing access issues, because it works by scanning user's hard disks and automatically providing software updates. Unanswered Qs: 1) What other kinds of info does/can it troll for? 2) What does it do when it finds unregistered software? 3) Does it implicate ECPA? 4) Will updates be available through other means? 5) Must a user affirmatively grant permission to the software agent? 6) Can a user decline or limit the agent's access? 7) What uses may the agent's owner make of data collected? etc. Alan L --- press release: *** "Digital Oil Change" CyberMedia announced today at PC Expo that it plans to automatically "service" personal computer software via the Net with a newly unveiled product called Oil Change. The company reports that Oil Change automatically replaces outdated, bug-ridden software and hardware drivers with clean updates. CyberMedia says the product is designed to use the Net to find, download, and install updates to Microsoft Windows 95 software applications and drivers. Oil Change reportedly tracks all currently installed versions and revisions of all Windows 95 software and hardware drivers on a PC, and then dials into CyberMedia's Internet Web Server for related updates. Users in need of an update are alerted by Oil Change with a description of what the update will do, and then the product finds the update on a software manufacturer's Web site, downloads, and installs it. Beginning today, CyberMedia says it will offer a free beta version of Oil Change for a limited time at its Web site.

3 2

where'd Bal's PKS go?
by me＠muddcs.cs.hmc.edu 17 Dec '03

17 Dec '03

Did it move? I hadn't seen any announcement of this... me -- Michael Elkins <me(a)cs.hmc.edu> http://www.cs.hmc.edu/~me PGP key fingerprint = EB B1 68 32 3F B5 54 F9 6C AF 4E 94 5A EB 90 EC

2 1

Re: Current status of RSA patent...
by jim bell 17 Dec '03

17 Dec '03

At 10:59 AM 6/20/96 -0400, Intense wrote: > >does not matter - it will be renewed in the interest of the government >The goverment want's there backdoor... would you expect less? As far as I know, patents can't be "renewed." I've heard they can be "re-issued," amended, but to my knowledge that doesn't extend their term. Jim Bell jimbell(a)pacifier.com

4 3

Re: rsync and md4
by David F. Ogren 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > > "David F. Ogren" writes: > > > I'm afraid you are totally wrong here. MD4 has been completely > > > broken. I wouldn't trust it for anything. In fact, MD5 is no longer > > > trustworthy, either -- it was broken recently. Stick to SHA. > > > > > > > MD4 has had successful attacks on limited rounds. It has _not_ been > > completely cracked. > > Could you please quit spewing inaccurate information? > > Dobbertin completely cracked MD4 already, and found MD5 collisions in > a document circulated on May 2nd that mean it isn't far behind. > > The comments you are making are dangerous because they encourage > people who don't know better to think that hashes which are known > unsafe are safe. Please quit posting until you start monitoring the > field enough to have accurate sources of information. > I stand by my statements. I have followed the current developments regarding MD5 with interest, and am using SHA1 in the program that I am currently authoring because of its MD5's weaknesses. However, MD5 (and MD4) have not been completely cracked. The problems that you bring up have to do with situations where an active attacker develops a slightly different pair of documents with the same hash. Although this is highly undesirable characteristic for a hash function, and shows a weakness in the function that may eventually lead to its being completely cracked, it does not mean that a fraudulent document can be created from an already signed document. This is an old argument and I don't want to get into it here. However, there a lots of people that who still think MD5 can be safely used to a) sign documents that you create yourself, and b) sign documents that you have made cosmetic changes to. Irregardless, this argument is moot. This thread is titled "rsync and md4". It is a discussion about which hash function suits this particular purpose and he is not particularly concerned with resistance to deliberate attack. In this case MD4 will function adequately. - -- David F. Ogren | ogren(a)concentric.net | "A man without religion is like a fish PGP Key ID: 0x6458EB29 | without a bicycle" - ------------------------------|---------------------------------------- Don't know what PGP is? | Need my public key? It's available Send a message to me with the | by server or by sending me a message subject GETPGPINFO | with the subject GETPGPKEY -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMddp3uSLhCBkWOspAQEI1Qf/VLg6ak6Y/VfbynFhCcA69RZKAQ/C6pCx DMdz3OFitOwQM/csjTPBs7jue/3ArIQ+jevBOjp/NyAoJ4U8+Np4yv7ksmpEjTKq EWq4DcvAB7MgpgJ72A92tO55vQo8AjYPmcZT2LhqeiTg+R6yL437T4gqS0ZSs7Ud 7e1anp7m72shSel6OKsxtfgiyVDlVi6mdtpXlLegWxcZhPaRYaZen3mHJ3JdxCpc EsQupdrNVxBGMuxKeBwlkjCxD1TbqFpHTodh0oapEDScjpzTMmQeHYavmboI+Pys 32jt1PI9JEPIDracYcI3ovkgvR5VmMlKhAPDXcYbr2MWeBbVRDOaJw== =9dqv -----END PGP SIGNATURE-----

4 6

Re: Ga Law/No False Identity
by Bill Stewart 17 Dec '03

17 Dec '03

>>: It shall be unlawful for any person, ... to transmit any data >>: through a computer network ... if such data uses any individual >>: name, ... to falsely identify the person, ... You don't have to falsely identify yourself to do spam canceling - in addition to the header saying From: Spammer <president(a)whitehouse.gov> you can put in a header with your real name Really-From: Mario Greymist <mario(a)luigi.com> or put your real name in the body, or a nym you use (e.g. Cancelpoodle) with an explanation that you're cancelling the spam posted by the spammer. >>Spamming aside, this strikes at my privacy and choice of anonymity. Well, of course - it's an offensively bogus law for a variety of reasons :-) # Thanks; Bill # Bill Stewart +1-415-442-2215 stewarts(a)ix.netcom.com # http://www.idiom.com/~wcs # Distract Authority!

1 0

Re: rsync and md4
by Andrew Tridgell 17 Dec '03

17 Dec '03

> The odds of a certain file having a certain hash are one in 2^128. But, > the odds of any two files having the same hash (the "Birthday Attack") is > just one in 2^64. The birthday paradox doesn't apply in my case I believe. Its not an all-to-all comparison. One file is "given" by the user. I'm definately not a crypto-expert, however, so I could be wrong. > That's good, because MD4 collisions can be produced in a matter of > minutes. But if you're not concerned about attacks, then MD4 is probably > more than you need. I'd like to know more about this. > You could, but why bother? If you've got a 14.4 or faster modem, you can > send a lot of hashes in a short time. The real load won't come until you > try to download an altered file. You'd have to read the tech report on rsync. It does not download the whole file when a checksum mismatch is found, that would be next to useless. It effectively creates binary diffs of the two files, without direct (local) access to both files. As far as I know this is a new type of algorithm. In practice the hashes and checksums dominate the data that is sent over the link. They total about 1/30 of the total file size for the default settings. > MD4 is not strong- people can deliberately produce files with the same > hash in a matter of minutes. MD5 is secure for now, but it seems to be > gradually falling to cryptanalysis, and should be phased out of use before > it breaks. IMO the best hash algorithm is SHA1 (which is an updated > version of the original SHA). Do a web search for "FIPS PUB 180-1" for the > specs. Do you have references to the md4 collision stuff? The situation I have is a bit unusual so its just possible some of the results may apply. > For what you're doing it sounds like you don't need a cryptographically > secure hash function. If you're not concerned about people deliberately > trying to defeat the system, then just use a 32-bit CRC. It already uses a 16 bit hash as a first level filter and a 32 bit "rolling checksum" as the 2nd level. The 2nd level fails about 25 times on a 25MB test file I've been using. The failure rate goes as the square of the file length. When the 2nd level fails it is detected by the md4 hash which has to be much stronger. Cheers, Andrew

2 1

Re: [Fwd: Doubleclick]
by Yanni 17 Dec '03

17 Dec '03

> [short-attention-span summary: someone's using Netscape cookies as a > way to target-market browser users. Since I hate being targeted, I > came up with a hack "fix" to prevent it, see below] Whatever. > > >Date: Wed, 26 Jun 1996 19:42:00 -0700 > > >From: Scott Wyant <scott_wyant(a)loop.com> Subject: COMMENT: > > >Cookie dough > > > > > >If you're like me, you never went to a site called "doubleclick." > > >So how did they give you a cookie? After all, the idea of the > > >cookie, according to the specs published by Netscape, is to make a > > >more efficient connection between the server the delivers the > > >cookie and the client machine which receives it. > > >But we have never connected to "doubleclick." Scott must have. Navigator is very picky about where a cookie comes from and what is put in the domain field of the cookie. Go read about the domain field in the Cookie spec. Then, write a CGI to play with setting/deleting cookies yourself. You will find out that it is actually almost an art to even get a cookie set. > > >Pay special attention to the information at: > > ><www.doubleclick.net/advertising/howads.htm> Maybe this scott wyant guy works for doubleclick? ;) > > >You'll see that the folks at "doubleclick" make the point that > > >this entire transaction (between their server and your machine) > > >is "transparent to the user." In plain English, that means > > >you'll never know what hit you. No sh*t. The cookie spec says that as well. > > >So what's happening is, subscribers to the doubleclick service put > > >a "cookie request" on their home page FOR THE DOUBLECLICK COOKIE. There is no such thing as a "cookie request". It is up to the browser to send the cookie and up to you to parse it out of the HTTP header. There is no way that the browser is going to send the cookie unless the domain and path matches. Go read the Cookie spec. > > >When you hit such a site, it requests the cookie and take a look to > > >see who you are, and any other information in your cookie file. > > >It then sends a request to "doubleclick" with your ID, requesting > > >all available marketing information about you. (They're very coy > > >about where this information comes from, but it seems clear that > > >at least some of it comes from your record of hitting > > >"doubleclick" enabled sites.) You then receive specially > > >targetted marketing banners from the site. In other words, if > > >Helmut Newton and I log on to the same site at the exact same > > >time, I'll see ads for wetsuits and basketballs, and Helmut will > > >see ads for cameras. Whatever. What are you saying doesn't make any sense if you knew what the heck you were talking about. > > >If you log in to a "doubleclick" enabled site, and it sends a > > >request for your "doubleclick" cookie, and you don't have one, why > > >each and every one of those sites will hand you a "doubleclick" > > >cookie. Whatever. > > >Neat, huh? And you can bet they're going to be rolling in the > > >cookie dough. > > >Me, I edit my cookie file each and every time I go to a new > > >site. (Despite the dire warning at the top of the file, you can > > >edit it with no adverse consequences.) Whatever. > > >Oh, and one other thing. If you edit your cookie file BEFORE > > >you connect to "doubleclick," and then jump around at the site, > > >you'll notice that they DON'T hand you a cookie. I probed the > > >site pretty carefully, checking the MagiCookie file, and > > >nothing happened. > > > > > >Until I closed Netscape. The LAST thing the 'doubleclick" site did > > >was.... > > >You guesed it. They handed me a cookie. So much for making > > >the client-server negotiation more efficient. (In fairness, > > >that cookie may have been in memory until I closed Netscape -- I > > >can't tell for sure.) Scott Wyant > > >Spinoza Ltd. No duh. Navigator doesn't fflush() the cookie file until you quit. It keeps it in memory for speed. > My own experiments shows that simply removing the cookie file (~/. > netscape/cookies) works to "fix" this, as long as you don't have > old netscape config files lying about (then it pops a dialog asking if > you want to nuke the old config, and uses the old cookies file). > Netscape (version 3.0b for Linux) doesn't recreate the cookies file. > Of course this "fix" means that I'm not able to take advantage of > whatever cookies might offer me, but since I can't control them and > never see them there's probably not a lot that they do that I'll miss. Who cares if you can't control them? They don't contain any information that you don't already know about! > I think that Netscape should add a configuration to the browser so > that paranoid privacy fanatics like me can disable cookies or better > yet control which ones that we'll accept. Navigator 3.0 has a preference. -jon (who has had more than enough real world experience with cookies) Jon (no h) S. Stevens yanni(a)clearink.com ClearInk WebMagus http://www.clearink.com/ finger pgp(a)sparc.clearink.com for pgp pub key We are hiring! Check out... http://www.clearink.com/clearink/home/job.html

2 1

INFO: Photos, testimony, and audio transcripts of 6/26 crypto hearing, get it now!
by Voters Telecommunications Watch 17 Dec '03

17 Dec '03

============================================================================= ____ _ _ _ / ___|_ __ _ _ _ __ | |_ ___ | \ | | _____ _____ | | | '__| | | | '_ \| __/ _ \ _____| \| |/ _ \ \ /\ / / __| | |___| | | |_| | |_) | || (_) |_____| |\ | __/\ V V /\__ \ \____|_| \__, | .__/ \__\___/ |_| \_|\___| \_/\_/ |___/ |___/|_| MISSED THE CRYPTO HEARINGS? HEAR THE TRANSCRIPT WITH REALAUDIO, READ THE TESTIMONY WITH ANY BROWSER, VIEW THE FUZZY PHOTOS Date: June 28, 1996 URL:http://www.crypto.com/ crypto-news(a)panix.com If you redistribute this, please do so in its entirety, with the banner intact. ----------------------------------------------------------------------------- Table of Contents News Security And Freedom through Encryption forum: July 1, 1996 (that's MONDAY!) How to receive crypto-news Press contacts ----------------------------------------------------------------------------- NEWS The second hearing on the Burns/Leahy Pro-CODE bill (S.1726) brought down the house in the Senate this past Wednesday. With a number of firsts (first cyber-simulcast of a Senate hearing, first time testimony was submitted purely through a WWW page) this is a monumental event. But wait! If you missed this standing room only event, you can still attend virtually by visiting the hearing wrapup page at http://www.crypto.com/ There you will find the two hour RealAudio transcripts of the audio portion of the day, links to online copies of many witnesses written testimony, and some photos taken at the hearing. ----------------------------------------------------------------------------- ATTEND THE SAFE FORUM - JULY 1, 1996 STANFORD CALIFORNIA On July 1, 1996, in the heart of California's Silicon Valley at Stanford University, members of Congress, prominent computer industry leaders and privacy advocates will meet to discuss the need to reform U.S. encryption policy. The event is FREE and open to the public, but space is limited and is going fast. To find out more, and to reserve your free ticket, visit the SAFE Forum Web Page at: http://www.crypto.com/safe CONFIRMED SPEAKERS INCLUDE: Among other prominent industry leaders, cryptographers, privacy advocates and members of Congress, confirmed speakers include" Industry Leaders and Cryptographers Members of Congress * Marc Andreeson, Netscape * Rep. Anna Eshoo (D-CA) * Jim Bidzos, RSA * Rep. Tom Campbell (R-CA) * Eric Schmidt, Sun Microsystems * Rep. Zoe Lofgren (D-CA) * Brad Silverberg, Microsoft * Sen. Conrad Burns (R-MT) * Phil Zimmermann, PGP Inc * Sen. Patrick Leahy (D-VT) * Matt Blaze, AT&T * Sen. Larry Pressler (R-SD) * Bruce Schneier, Counterpane Systems Privacy Advocates and Legal Experts: * Michael Froomkin, U. of Miami Law School * Jerry Berman, Center for Democracy and Technology * Grover Norquist, Americans for Tax Reform (invited) * Ken Dam, U. of Chicago Law School (invited) This event will be "cybercast", with full audio and still video clips, live online with the help of MediaCast. Details on the cybercast are available at http://www.crypto.com/safe/ SAFE FORUM SPONSORS This important discussion on the need for an alterative policy to protect privacy and security and promote commerce on the Global Information Infrastructure is being made possible by the generous support of the following companies and public interest organizations: America Online Americans for Tax Reform AT&T Business Software Alliance Center for Democracy and Technology Center for National Security Studies Commercial Internet eXchange CompuServe Incorporated Computer Professionals for Social Responsibility Cylink Corporation EDS Electronic Frontier Foundation Electronic Messaging Association Electronic Privacy Information Center Information Technology Association of America IEEE - USA MediaCast Media Institute Microsoft Corporation Netcom Online Communication Services Netscape Communications Corporation Novell, Inc. Oracle Corporation Pacific Telesis PGP Inc. Prodigy, Inc. Progress and Freedom Foundation Securities Industry Association Software Publishers Association Sybase, Inc. Voters Telecommunications Watch Wired Magazine Please visit the SAFE Forum Home Page for more information (http://www.crypto.com/safe/) ----------------------------------------------------------------------------- HOW TO RECEIVE CRYPTO-NEWS To subscribe to crypto-news, sign up from our WWW page (http://www.crypto.com) or send mail to majordomo(a)panix.com with "subscribe crypto-news" in the body of the message. To unsubscribe, send a letter to majordomo(a)panix.com with "unsubscribe crypto-news" in the body. ----------------------------------------------------------------------------- PRESS CONTACT INFORMATION Press inquiries on Crypto-News should be directed to Shabbir J. Safdar (VTW) at +1.718.596.2851 or shabbir(a)vtw.org Jonah Seiger (CDT) at +1.202.637.9800 or jseiger(a)cdt.org ----------------------------------------------------------------------------- End crypto-news =============================================================================

1 0

MD5 breaks, etc.
by John Hemming - CEO MarketNet 17 Dec '03

17 Dec '03

Accepting for a moment that MD5 collisions have been identified. From a commercial aspect I am concerned to ensure the cryptographic security of our ECheque system. Just a thought on the use of MD5. If two signatures are appended to the same document both using MD5, but one either a) Signing all but the last octet of the message ... or b) Signing the whole of the message and signature. Would that not make the determination of useable collisions either impracticable or impossible? I must admit I am inclined to encode additionally the key components of the message (amount paid, to whom) as well as the hash using a Private Key encryption. After all we have at least 60 octets of important data that can be encoded in this manner using one simple encryption sequence, this can cover account credited and amount easily. If someone can collision codge the description I am not desperately concerned. Alternately, could someone please point me at the SHA algorithm.

2 1