December 2003 - cypherpunks-legacy

Re: Five industry giants propose encryption plan to protect Hollywood
by Information Security 17 Dec '03

17 Dec '03

> Date: Thu, 19 Feb 1998 11:13:50 -0800 (PST) > From: William Knowles <erehwon(a)dis.org> > > BURBANK, Calif. (February 19, 1998 09:06 a.m. EST > http://www.nando.net) -- Five computer and electronics industry giants > have agreed on a strategy to prevent people from illegally copying > digital movies and music, the Los Angeles Times reported Thursday. > > According to the proposal, high-definition TV sets, personal > computers, digital video disc players, digital video cassette > recorders and set-top boxes would be equipped with technology that > requires a code before a copyrighted piece of work can be transferred > from one device to another. > > It would ensure that someone who watches or listens to digital movies > or music over satellite services, cable networks and the Internet > won't be able to make copies without permission. > > The encryption technique scrambles the copyrighted material in one > device so it cannot be unscrambled by another device without the > correct software key. It's unscrambled when it is listened to...what are they thinking? ---guy Escpecially regarding computers, this won't work.

3 3

distributed computing
by Jon Cooper 17 Dec '03

17 Dec '03

I'm in the planning phase of a demo which should demonstrate the power of a distributed object technology which I'm working with. Any ideas for neat crypto-related distributed computation demos would be much appreciated. I've thought of: * brute forcing RC5 (lots of people are doing this already) * factoring attack on RSA modulus * Certicom's ECC challenge But I'm looking for something with more of a sort of gut-level appeal. Cracking SSL packets might be good. Hrmm. thanks for any input ... *jon

1 0

No Subject
by Mix 17 Dec '03

17 Dec '03

subskribe cyferpunks bill(a)whitehouse.gov

1 0

Re: The Continued Attack on Cash (Was: "The Right of Anonymity"...)
by Black Unicorn 17 Dec '03

17 Dec '03

At 06:07 PM 2/2/98 +0000, Attila T. Hun wrote: > I did-- tried to lay $14K out for a Mercedes (25 years ago). > they wouldnt take it. so I went and picked up two $7K > cashiers from two different banks. same thing with a pair > of Lycoming IO540 aircraft engines: 2 8s and a 9 --stay > under the $10K transaction. Careful. This may well be illegal now. Structuring transactions to avoid reporting requirements is a felony. (I'm not on cpunks, mail me).

5 4

An update on MS private key (in)security issues
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

A fortnight ago I posted a message exposing a number of weaknesses in the way various Microsoft security products handle users private keys. A few days before I was due to vanish for a security conference (where it was very difficult to contact me), the article started getting a bit of attention. This is a general response which clarifies several issues relating to the original message. First, Russ Cooper (moderator of the NT Bugtraq mailing list) made some wildly inaccurate claims about the article. I've had a bit of feedback which indicated that it wasn't even worth dignifying this stuff with a response but I've written one anyway, at least for the original NT Bugtraq messages he posted (the stuff he put on a web page is just more of the same). You can find it at http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms2.txt (even if you don't want to plough through the whole thing, you might want to read the last two paragraphs for a giggle). After this, Microsofts spin doctors leaped into action and posted a response to the article. I've replied to this one in a bit more detail, since it raises several important issues. Comments on Microsofts Response ------------------------------- >Microsoft's Response to Recent Questions on the Recovery of Private Keys from >various Microsoft Products >[...] >With the exception of the details about a possible PKCS-12 attack, all the >issues raised in the recent discussions are specifically aimed at Microsoft's >base CSPs, not at CryptoAPI. The base CSPs are the royalty-free, >software-based CSPs provided with Windows NT 4.0, Windows 95, and Internet >Explorer. These attacks do not apply in general to other CryptoAPI CSPs and do >not indicate any fundamental concerns with the security of the CryptoAPI >architecture or applications built upon it. This statement is mere obfuscation. As Microsoft have said, every single (recent) copy of Windows NT, Windows'95, and MSIE (and, presumably, other products like IIS and Outlook, which rely on them) ship with these CSP's, therefore every recent system comes with this security hole installed by default. In addition, the CryptExportKey() function is a standard CryptAPI function, which is described by Microsoft with the text "The CryptExportKey function is used to export cryptographic keys out of a cryptographic service provider in a secure manner" (obviously some new use of the term "secure" with which I wasn't previously familiar). There's nothing in there that says "Only the Microsoft CSP's support this" (some may not support it, but by Microsofts own admission the default used on any recent system does indeed exhibit this flaw). >Microsoft products do not "store" private key material using PKCS-12, contrary >to recent descriptions on the Internet. I was unfortunately somewhat unclear in my article, I've fixed up the online version at http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms.txt. To summarise, if you want to get at an exported key stored on disk, you can use the pre-4.0 key file/PKCS #12 key file flaws. If you want to get at the current users key, you can use the CryptExportKey() flaw. >The example of breaking a PKCS-12 data blob, which was given in discussion on >the Internet, is not an attack on the "weak" cryptography of PKCS-12. Rather, >it is simply a dictionary attack (long known and well understood in >cryptography), This statement is accurate. As Microsoft have said, dictionary attacks have been known to the computer industry for a long, long time (several decades). For example the Unix password encryption uses 25 iterations of DES to protect users passwords from dictionary attacks (this is rather inadequate now, but was appropriate more than two decades ago when it was introduced). If this is a well-known flaw which the entire industry has known about for decades, why are Microsoft's very latest "security" products so extremely vulnerable to it? As I mentioned in my writeup, I published an attack on the exact format used in older MS products more than 1 1/2 years ago, but Microsoft made no attempt to fix this problem at the time. It wasn't until I published the current writeup that they finally addressed it. >One statement by the original poster argues that Microsoft managed to design a >security format that actually makes it easier to break into the protected >data. As stated above, a number of well respected companies were involved >extensively in the design and review of PKCS-12 before it became a standard. The problem is that Microsoft ignored the other companies recommendations for increasing security. I'll refer people back to the original writeup for mention of the various security features which were added to PKCS #12 and subsequently ignored by Microsoft. PKCS #12 is just a basic modification of PFX, which was a purely Microsoft invention, and Microsofts implementation of PKCS #12 does indeed make it very easy to perform the attack I described (you'd have to read my writeup for the full technical details in which I describe each individual flaw which, as each is exploited in turn, make it progressively easier and easier to recover a users private key). In addition (as I mentioned in my original message), Microsoft use RC2/40 to encrypt the private keys, which means that no matter how good a password you choose, the default PKCS #12 format private key produced by MSIE can be recovered in a few days with fairly modest computing power. There already exists a Windows screen saver which will recover RC2/40 keys for S/MIME messages, and the prize of an RSA private key is a much higher motivating factor than the "Hello, how are you?" typically found in an S/MIME message. As Microsoft point out, Netscape can indeed handle RC2/40-encrypted files, however they usually use triple DES and not RC2/40 (they encrypt the private key components - the really valuable part of the PKCS #12 payload - with triple DES and the other odds and ends with RC2/40). Since Netscape also iterate the password and MAC processing, they aren't vulnerable to the attacks which the Microsoft software is vulnerable to, even though both are based on the same PKCS #12 standard. >Exploiting Internet Explorer > >One of the fundamental requirements to perform any possible cryptographic >attack discussed in the recent postings is the assumption that a malicious >entity could somehow access to data on a user's computer system, without the >permission or knowledge of the user. This is a large leap of faith. > >Users that are using Public Key Certificates today are generally sophisticated >and savvy users, Bwahahahahaha! Sorry, I guess I should explain that in more precise terms. Now I'm not trying to claim that the average Win95 user isn't as sophisticated and savvy as Microsoft seem to think, or that relying entirely on the sophistication of the average Win95 user for security is a dangerous move. However these statements do seem to completely ignore the reality of the situation. Let me go into the background of the weaknesses a bit further. When I tested the weaknesses, I asked some "guinea pig" users to send me their exported keys, with the promise that I'd destroy the keys and not keep any record of where the keys came from and so on. Because of this I can't give exact figures, however here are a few data points: - More than half the keys (I can't remember the exact figure) were in the older, pre-4.x format. This indicates that the majority of users (or at least of the crypto-using guinea pigs) are still running old versions of MSIE which contain a number of widely-publicised problems, including precisely the weaknesses required to run arbitrary code on the machine or read files off the machine. One of the respondents commented that the key was "the key I use with Outlook", I'm not sure what that says about the origins of the key. Another key was one used with IIS for a web site which runs an online commerce service that processes credit-card based orders. This must have been an older version of IIS since the key was in the pre-4.x format. - When I asked two of the people why they were still using an old version, the responses were "It came installed with the machine when we bought it" and "It does what I want, so I haven't upgraded". I expect most users of the older version would have a similar reason for using it. In a company of 20 people (some of whom participated in this test), only two were running 4.x. These people are all highly competent software developers (presumably this includes them in the group of "sophisticated and savvy users" which MS were referring to), however none of the remaining 18 wanted to risk installing MSIE 4 because of the extent with which it messed with their system, possibly jeopardising their development work. Therefore most of these "sophisticated and savvy users" were still running old, insecure versions of MSIE, and weren't going to upgrade any time soon. - For the two remaining 4.x users in the company, both are still using straight, unpatched 4.0 because they considered it painful enough to download all of 4.0 and they didn't want to bother with an upgrade just yet. This makes them vulnerable to the bug pointed out in the l0pht advisory. - When I informed one of the guinea pigs of the recovered password, his response was "Now I'll have to change my login password" (the others generally restricted themselves to some variation of "Oops"). This comment confirms that users do indeed sometimes use their login password to protect their private keys, so that a successful attack recovers not only their private keys but their login password as well. - One respondent commented that most of the code they downloaded from the net was unsigned, but they ran it anyway. This is probably typical of the average user. Although I've only been back for two days, I haven't yet managed to find anyone who has applied all the latest patches and kludges to their system which makes them immune to these problems. This includes at least one person who has a code signing key which could be used to sign malicious ActiveX controls. Therefore all of the guinea pigs could in theory have their private keys stolen. >Attacks against Authenticode signing keys > >[...] > >However, it is extremely unlikely anyone could be successful with a simplistic >strategy for stealing Authenticode signing keys and then using them. See my comments about about this. I could, right now, obtain at least one Authenticode signing key with which I could create a malicious ActiveX control. I'm sure that if I were serious about this I could obtain a number of others. >Second, anyone signing code using Authenticode technology is extremely >unlikely to leave their key material sitting on an end user machine routinely >used for browsing the Internet. I see no basis for this claim. Every developer I know uses the same machine for both code development and web browsing (in fact a number of users keep a copy of MSIE or Netscape permantly running on their machine so that they'll have something to do between compiles). Microsoft's statement seems to imply that users will be running two machines, one dedicated entirely to web browsing and the other to code signing. I find this extremely unlikely. >Attacks on Encrypted Key material > >There is some confusion over the algorithms and methods that Microsoft uses to >provide protection of encrypted key material in Internet Explorer when using >the standard Microsoft base CSPs. There were changes between Internet Explorer >3.0x and Internet Explorer 4.x specifically to address any possible concern. And the astounding thing was that, despite a complete rewrite of the code, the newer version offers no extra security at all, as my article points out. Both are equally weak, you just need to attack them in slightly different ways. >Key export attacks > >The original Internet posting raises concern about the CryptoAPI interface >CryptExportKey(). This function is fully documented and does indeed export >private key material in an encrypted format. The statement from Microsoft omits one important point here. Myself and another security researcher have been trying to tell Microsoft for more than four months (probably a lot longer, I didn't log the earlier mail) that this is a very serious security flaw. In all cases Microsoft's response was some variation of "We don't see this as a flaw". It wasn't until my warning was published that they finally addressed the problem, and even in this case (the program to set the CRYPT_USER_PROTECTED flag) it's only a quick hack to plaster over the cracks and allow them to declare the problem fixed. In fact it doesn't fix the problem at all. I'll post details in a fortnight or so when I've had time to test things, please don't ask me about this until then. >The presence of the CryptExportKey() function is to support functionality such >as migrating key material between machines for a user or creating a backup >copy of a key. It should be noted however, that many CSPs, including most >hardware based CSPs, do not allow exportable private keys and will return and >error in response to a CryptExportKey() request. However the CSP's installed by default on every recent system do allow the export. The fact that there may exist, somewhere, an implementation which doesn't exhibit this flaw really doesn't help the majority of users. >The posting also asserts that an ActiveX control could be downloaded from a >web page, simply ask for the current users key, ship the key off for >collection by an unscrupulous person, and then delete itself without a trace. > >If users run unsigned code, or code from an unknown origin, a number of >unpleasant things can happen. This could indeed occur if the key as been >marked exportable and the CRYPT_USER_PROTECTED flag is not set. Which was, until my warning, the automatic default action for Verisign, and is still the automatic default for many other CA's. This means that keys generated right up until a few days ago (and in some cases keys being generated right now) have, by default, no protection whatsoever. In addition I've just been sent mail to say that CRYPT_USER_PROTECTED still isn't the default with Verisign, you have to click a box asking for extra security or you get the usual default of no protection. To add to the confusion, a lot of documentation (including the Microsoft Developer Network (MSDN) online documentation on Microsofts web site) describes the CRYPT_USER_PROTECTED flag with "The Microsoft RSA Base Provider ignores this flag", which can cause programmers to leave it out when it is *essential* it is always included. Incidentally, MSDN also claims that Microsoft are "supporting" PFX, which is in direct contrast with the claims in their press release. >There was also discussion of 16 dialog boxes appearing to the user for their >password if the CRYPT_USER_PROTECTED flag is set. Certainly asking the user >too many times would be better than too few times, however in our tests, under >extreme (and uncommon cases), a user might be asked for their password at most >four times when a key is used with the Microsoft base CSPs. Perhaps the claim >came from an early beta release. The 16 dialog boxes problem was present in 4.0, and it's been confirmed as still being present in 4.01. This was apparently verified on Microsoft's own CryptoAPI mailing list (the claimed "beta" version was actually MSIE 4.0 final). >Microsoft is constantly working to improve the security of our products. Myself and another person had been trying to convince Microsoft for more than four months that things like CryptExportKey() are a major security hole. Their response each time has been some variation of "We don't see this as a problem". It simply wasn't possible to get them to acknowledge these flaws, therefore my posting of the details wasn't "irresponsible" (as some have claimed) but a necessity in order to get them fixed. When I pointed out several months ago that Microsoft were using, in their pre-4.x products, an exported key format which was identical to the one which I broke more than 1 1/2 years ago, their response was "What's the problem with this?". I would have liked to have included URL's for the CryptoAPI mailing list archives to prove that Microsoft were warned of these problems some time ago, but the CryptoAPI archive seems to be temporarily offline. Risks of a Private Key Compromise --------------------------------- One or two respondents have tried to play down the seriousness of a private key compromise, saying that I exaggerated the dangers in my original message. What I wanted to point out was how extremely valuable a users private key is, and how disappointingly little concern Microsoft seem to have for protecting this valuable resource. For example Garfinkel and Spaffords "Web Security and Commerce" (O'Reilly, 1997) contains the warning: "Today's PC's are no better at storing private keys once they have been generated. Even though both Navigator and Internet Explorer can store keys encrypted, they have to be decrypted to be used. All an attacker has to do is write a program that manages to get itself run on the users computer (for example by using [...] Microsoft's ActiveX technology), waits for the key to be decrypted, and then sends the key out over the network" (p.120). Including a function like CryptExportKey() (which hands over a users private key) makes this very attack possible. The potential damage which can be caused with a misappropriated private key is enormous. Consider the relative risks in the compromise of a logon password and a private key. With a logon password, the worst an attacker can do (apart from stealing possibly valuable data) is to trash the victims hard drive, which involves reinstalling the operating system (an action which many users are intimately familiar with). In contrast an attacker who obtains a private key can potentially drain the victims credit card, clean out their bank account (if the victim uses one of the emerging online banking services), sign documents in their name, and so on. The implications of that last point can be quite serious. Take for example the Utah digital signature act, which was used as a model by a number of other states who implemented or are implementing digital signature legislation. Under the Utah act, digitally signed documents are given the same evidentiary weight as notarised documents, and someone trying to overcome this has to provide "clear and convincing evidence" that the document is fraudulent, which is difficult since it bears a valid signature from the users key (this fact has been used in the past to criticise digital signature laws based on this act). In addition, under the Utah act and derived acts, anyone who loses their private key bears unlimited liability for the loss (in contrast, consumer liability for credit card loss is limited to $50). This leads to the spectre of a malicious attacker who has the ability to issue notarised documents in your name for which you carry unlimited liability. This is a lot more important than someone reformatting your hard drive, or stealing last months sales figures. Peter.

2 1

INFO-RUSS: Israel Issues Iraq Warning (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: >From INFO-RUSS-request(a)smarty.ece.jhu.edu Mon Feb 2 19:00:52 1998 Message-Id: <9802022059.AA22808(a)smarty.ece.jhu.edu> Errors-To: INFO-RUSS-request(a)smarty.ece.jhu.edu Sender: INFO-RUSS-request(a)smarty.ece.jhu.edu Date: Sun, 1 Feb 1998 19:32:58 +0200 (IST) To: info-russ(a)smarty.ece.jhu.edu From: info-russ(a)smarty.ece.jhu.edu Subject: INFO-RUSS: Israel Issues Iraq Warning --------------------------------------------------------------------- This is INFO-RUSS broadcast (1200+ subscribers). Home page, information, and archives: http://psi.ece.jhu.edu/~kaplan/IRUSS/inforuss.html To post, or to subscribe/unsubscribe, mail to info-russ(a)smarty.ece.jhu.edu INFO-RUSS assumes no responsibility for the information/views of its users. --------------------------------------------------------------------- Reuters, Sunday February 1 3:34 PM EST Israel Issues Iraq Warning JERUSALEM (Reuters) - Prime Minister Benjamin Netanyahu Sunday reserved the option of retaliating for any Iraqi missile attack on Israel, despite assurances the United States would step in quickly to punish Iraq. "The only ones who will make decisions, the only ones who make decisions, are us and us alone," Netanyahu said in remarks on the Iraq crisis in a speech to visiting American Jews. During the 1991 Gulf war, Israel held its fire in the face of 39 Iraqi Scud missile attacks, bowing to U.S. pressure not to take action that could push Arab states out of a U.S.-led alliance to drive Iraq out of Kuwait. On a visit to Israel Sunday, U.S. Secretary of State Madeleine Albright spoke of a U.S. "iron-clad commitment" to Israel's security and gave notice any Iraqi threat to countries in the region in the current crisis would not go unpunished. "If they do threaten their neighbors or do damage to them our response to it will be swift and forceful," she said. But in apparent reply, Netanyahu said in his speech: "One thing has to be understood -- that we will do whatever is necessary to defend Israel and strengthen Israel's national security." He said Israelis should view the Iraqi crisis "calmly because there is a government here that handles matters professionally and with reason." Netanyahu spoke after convening cabinet ministers to discuss the possibility that a U.S. assault on Iraq would push Baghdad to launch missiles against Israel tipped with biological weapons. After the session, Deputy Defense Minister Silvan Shalom declined to comment on the deliberations but he said earlier that Israelis were thronging to army distribution centers to exchange old gas masks. Israel's Ha'aretz newspaper reported Sunday the United States had agreed in principle to send Israel vaccines against anthrax and other biological agents Iraq is believed to possess. The newspaper report, attributed to U.S. sources, said Israeli leaders asked Washington to store hundreds of thousands of doses of the vaccines in Israel. Asked if Israel had ordered the vaccines, Defense Minister Yitzhak Mordechai told reporters: "Some things are done in coordination between us and the United States to be able to defend ourselves today and in the future against the possibility that non-conventional weapons will be possessed by someone who wants to endanger us." Israeli officials have said the probability was low that Iraq would launch a strike but authorities have made clear they are preparing for the worst. The United States is rallying support from allies for a possible attack on Iraq to punish President Saddam Hussein for not complying with U.N. arms inspectors searching for documents and materials related to its weapons programs. Iraq says it has no nuclear, chemical or biological weapons or ballistic missiles -- banned under terms of the cease-fire that ended the Gulf War in which U.S.-led forces drove Iraqi troops out of Kuwait. ----------------------------------------------------------------------------

1 0

VMM question - reply (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Mon, 02 Feb 1998 01:39:47 -0600 > From: Lenny Blumberg <lenny(a)bga.com> > Subject: VMM question - reply > Hmmmm..... > I would imagine that the OS would keep a disk map in memory and > mark it with a flag to indicate if it's been paged into memory. This is a function of the "Look Aside Buffer" and the actual operation is a bit more complicated. The vmm must keep up with which processes have it mapped, where in their indipendant memory maps it shows up at, what the status is in each of those maps, whether it's sharable or not (though the Linux vmm doesn't seem to do any write locking), and probably some functions that I've missed. > At > that point, instead of updating the disk drive - It looks up the page in > memory and updates that copy. There are two ways to do this in general... Write-through: means the vmm goes ahead and not only updates the vmm copy but the copy on the drive. Note that this may or may not actualy update other copies if a process has one that isn't sharable (ie has its own private copy). This has a lot of over-head in that there is lots of i/o. Write-back: means that the data in the individual pages doesn't get written to the drive until the page is either swapped out of active memory (and written to swap) or is closed. This is a form of 'lazy propogation'. Again, this doesn't address how other processes may have their images effected. > The only problem is that at that point, > you're now running into a mess of lock problems that carry their own > overhead. One easy way, at least on a Unix machine, is to keep the system clock setting when the page is created. Then close them in chronological sequence. This obviously has it's problems. The first person to open isn't guaranteed to be the first person done. Another method would be to select via a PRNG the 'first' process to update the page. Then each following would take their turn according to the spin of the wheel. This leaves us with two options, as each process closes it only writes the changes that it has made; which could overwrite the previous user if they edited the same part of the file. The alternative would be to force each user to create a different file with some filename convention to differentiate them. Then leave it up to some unknown method to arbitrate the file propogations at that point by some 'compare and share' method perhaps. > Another alternative would be to track the disk map and force a > write for a page that is pending a read. How do you know ahead of a read that a process is going to read that page? Or are you saying that before another process can open a file we force the first process to go ahead and write its changes? What happens once two or more have the page mapped and begin editing? How do you propose to manage the file closure writes that will occur? ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

No Subject
by Pepe 17 Dec '03

17 Dec '03

1 0

RE: The Continued Attack on Cash (Was: "The Right of Anonymity"...)
by James O'Toole 17 Dec '03

17 Dec '03

Tim, Maintaining anonymity in the face of the regulatory framework is certain to be difficult, and anything difficult is usually rare, expensive, or both. An interesting question about the Privacy Card product is whether the social pressure against it is strong enough to defeat its privacy whenever the product is well advertised. In other words, will a privacy product survive in spite of its own publicity in our current environment, or can privacy products only exist when their own existence is relatively unknown. This is interesting because in the latter case, we have only a very very weak form of privacy/anonymity because it is hard to be sure how much privacy backs a product whose very existence is semi-secret. Maybe we should consider putting up, and encouraging existing privacy-enhanced institutions to put up, challenge prizes based on privacy/anonymity preservation. Just as we've seen prizes set for the cracking of specific composites and encrypted messages, we could ask Credit Suisse to put $1M in an escrow account at their main branch (Zurich?). This escrow account would be a numbered account held by a trustee selected by the bank. Let's say they wire $1000 per week to RSA Data Security in California, or to EFF.ORG, or to me, for that matter, and I wire it back. I publish the full text of any documentation I can get from my bank account (an empty account I would maintain for this anonymity challenge). Credit Suisse would promise to release the contents of the account to the first person to arrive at their main branch and present the name of the trustee. That's not a very creative challenge...this could use more thought. The point is that as far as I know, we haven't yet seen any really solid rewards placed to validate, advertise, or demonstrate the weakness of, well-known privacy-enhanced financial systems. I don't even know that Digicash, which would be another logical sponsor, has put up such a challenge. Have they? --Jim ---------- From: Tim May[SMTP:tcmay@got.net] Sent: Monday, February 02, 1998 1:18 PM To: Black Unicorn Cc: rotenberg(a)epic.org; nym(a)vorlon.mit.edu; dcsb(a)ai.mit.edu; cypherpunks(a)Algebra.COM Subject: Re: The Continued Attack on Cash (Was: "The Right of Anonymity"...) At 10:51 PM -0800 2/1/98, Black Unicorn wrote: >Mr. May said: > >>Suffice it to say that I find nearly all cases where someone is "demanding" >>personal information to be cases where the government has required them to, >>for various unseemly purposes, or in cases where credit is being arranged. > >Of late I tried to pay off a rather large American Express bill. > >Suddenly, AMEX won't take cash in excess of $1,000 in any single billing >period (30 days). The large sign on the wall indicated the substance of .... It's worth noting (again) that a very simple technological/social solution to the "credit card companies have records on people" problem, the one often cited by "privacy law advocates" as the reason for a Data Privacy Act, is easily found. Namely, remove any impediments to the issuance of credit or debit cards unlinkable to the True Name of a user. A card issuer could feature this as a Privacy Card, either backed by transfers of backing capital to accounts, or using Chaum-style methods. This is fully feasible using Chaumian credential-revealing mechanisms. (Cf. Chaum's seminal "Transaction Systems to Make Big Brother Obsolete," in Communications of the ACM, November 1985. Updated a few times and available in reprints or other places. Try search engines for latest locations.) However, the trends are in just the opposite direction, as both Black Unicorn and Bill Stewart have noted in this thread. Between the War on Drugs, the laws about money laundering, the fears of tax evasion, and the general burrowcrat desire to record the movements and actions of citizen-units, such a Privacy Card would be frowned-upon. Various roadblocks, ranging from "know your customer" restrictions on banks to anti-money-laundering laws, would be thrown up to stop any such Privacy Card. The real solution is easy. --Tim May The Feds have shown their hand: they want a ban on domestic cryptography ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^2,976,221 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway." For help on using this list (especially unsubscribing), send a message to "dcsb-request(a)ai.mit.edu" with one line of text: "help".

2 1

Hacker group battles child porn [c|net News, 2/2/98]
by Ken Williams 17 Dec '03

17 Dec '03

Hacker group battles child porn C|NET News.Com News Story: http://www.news.com/News/Item/0,4,18717,00.html?st.cn.fd.tkr.news CNET Radio Interview: http://www.news.com/Radio/Index/0,55,,00.html?st.cn.fd.tb.ne By Courtney Macavinta February 2, 1998, 1:10 p.m. PT A secret society that hunts the Net to reveal the identities of alleged pedophiles and child pornographers has a message for those who think there's too much media hype about the problem: Believe what you hear. Members of a group called Ethical Hackers Against Pedophilia (EHAP - http://www.hackers.com/ehap/index2.htm) are using their high-tech cracking talents to find out the identity and physical location of people they say post child pornography within newsgroups, chat rooms, and Websites. The 17-member nonprofit group also says it tries to determine the sources of video streaming sites that feature children being sexually assaulted in real time. "The pedophiles that are distributing child pornography online are skirting the law by remaining anonymous. We decided to use the skills that we possess as hackers, engineers, and teachers to educate the public that hackers aren't all bad guys, and to help law enforcement in apprehending the child pornographers," said EHAP's secretary, "Oracle," who asked that his real name not be published. "As long as the people are arrested and the kids aren't hurt anymore, every one of us is willing to accept responsibility for our actions as long as one kid is helped," he added. EHAP may go so far as to dig up the Social Security numbers of people it suspects are producing and distributing child porn on the Net. Under the guise of a confidential informant, EHAP then passes on these details to various law enforcement agencies, such as the FBI. It's virtually impossible to know if EHAP's tips have led to any investigations or arrests, though the group says its information has been put to work. Still, its vigilante tactics raise privacy concerns, as well as serious questions about law enforcement's possible use of information that could have been obtained illegally. According to the FBI, the Net increasingly is being used to lure children to physical meetings, which could lead to abduction or abuse, and there has been a boom in child pornography being trafficked online. These acts violate federal law. During two congressional hearings last year, FBI officials told lawmakers they are working to stop the rise in these illegal acts through the bureau's Crimes Against Children initiative. "The FBI has investigated more than 70 cases involving pedophiles traveling to meet undercover agents or officers posing as juveniles for the purpose of engaging in an illicit sexual relationship," Stephen Wiley, chief of the FBI's violent crime and major offenders section, testified in November before the House Judiciary Subcommittee on Crime. The FBI has launched other special programs, such as Innocent Images, in which agents go online and portray themselves as children and crack down on those who solicit encounters with them. The program, which is run by the Baltimore, Maryland, FBI field office, also serves as a clearinghouse for tips and information regarding suspected online crimes against children. The program was started in 1994 after local agents uncovered an online child porn ring while searching for an abducted boy. The 13-year-old boy, George Burdynski of Prince Georges County, Maryland, has never been found. But the program has lead to more than 90 arrests as well as the development of online crime fighting techniques. For instance, in October, three Californians were collectively sentenced to 60 years in prison for running the so-called Orchid Club, an international service that used the Net to distribute child pornography to its members. Despite growing efforts by the FBI and organizations such as the National Center for Missing and Exploited Children, EHAP says its private campaign is vital, as these agencies don't have the full-time resources to combat online child pornography. EHAP also readily admits that it would be unconstitutional for law enforcement to use some of its methods. "We're extremely careful about who we hack. There are so many people trading child porn out there, but we go after the people who are producing the material. That's who we hunt," Oracle said. "Law enforcement are restricted in ways we're not--but I'm not saying that we break the law." EHAP is not the first group to use its own devices in an effort to assist law enforcement in tracking down people who they suspect use the Net to perpetrate crimes. For example, a worldwide network of Internet users known as the CyberAngels provide online safety tips and work with law enforcement to stop the trading of online pornography. Other Net users have been known to shut down chat rooms or flame those who they deem pedophiles or sexual predators. CyberAngels doesn't support the electronic harassment of others. EHAP keeps its methods confidential. "Although we would appreciate any information these individuals may have, to violate the law to get the information is not acceptable," said George Grotz, a spokesman for the FBI's San Francisco office. "But how many pedophiles would come to us and say their site had been broken into?" Still, the FBI and other child protection agencies say they need all the help they can get. "Here in the San Francisco office, we have neither the time or resources to surf the Net looking for child pornography," Grotz added. "That said, we do respond aggressively when information is brought to our attention from outside sources, or if we develop information during the process of another investigation." The National Center for Missing and Exploited Children, which is supported by the Justice Department, also expanded its efforts to encompass online activity. As announced in December at the White House-endorsed Children's Internet Summit in Washington, the center will launch a Web site on March 1 to collect tips regarding online child porn and suspected crimes against children. "It's a huge problem that is as new as the Internet. For law enforcement, it's not easy to handle," Todd Mitchell, program advocate for the exploited child unit, said today. "Parents can't leave their child in front of a computer for hours and hours where they can stumble upon pornography or be solicited in a chat room. They have to teach their kids some safety guidelines," he said. Regarding private citizens' groups such as EHAP and CyberAngels, he said there are legitimate concerns, but that community activism is needed. "If they work in conjunction with law enforcement, it can be something that is a nice partnership between law enforcement and the community. If they take the law into their own hands, it could do more harm that good," Mitchell said. [EOF] -- For more information about EHAP, go to http://www.hackers.com/ehap/index2.htm or send email to ehap(a)hackers.com Regards, TATTOOMAN Vice President of Ethical Hackers Against Pedophilia http://www.hackers.com/ehap/ ehap(a)hackers.com http://152.7.11.38/~tattooman/

1 0