December 2003 - cypherpunks-legacy

Re: Opinion piece in NYT; responses needed
by wlkngowl＠unix.asb.com 17 Dec '03

17 Dec '03

On Sun, 28 Jan 1996 19:33:19 -0500, Jonathan Rochkind wrote: >> The New York Times, January 2, 1996, Business, p. 14 >> >> >> Viewpoint: J. Walker Smith >> >> Standoff in Cyberspace Gulch >> >> [..] >[I'm going to try to make myself write a letter to the NYT in response to >that viewpoint, making some of these points I'm saying it's important to >make, but you should too. :) ] Don't leave out an important point ignored by both sides of the debate all too often (esp. by the "decency" folk): the structure of the 'net itself (well, sort of). It's a decentered network (or set of networks) designed to get information to its addressee. Data flows through several nodes and networks until it reaches its destination. If it can't get through one path, it goes through the other. This isn't just for mail but all "packets" that flow on the net: web pages, file transfers, telnetting, etc. [A good segue to arguing "security related to privacy can go here...] Limiting content or access is only superficially impossible. The international scope of the 'net makes even agreeing to standards impossible.

3 2

[NOISY] Deutsche Telekom <--> webcom.com "routing troubles"
by Just Rich 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- [Capsule summary: the largest German Internet provider has blocked access to webcom.com at the router lever because of one out of a thousand subscribers' files, which violate German anti-Nazi laws.] Someone please inform Deutsche Telekom and the relevant prosecutors that by the time they read this (i.e., within an hour), selected files from Zundel's holocaust-denial archives (which make me sick, but that's beside the point) will be available at the AFS path: /afs/ir.stanford.edu/users/l/llurch/WWW/Not_By_Me_Not_My_Views/ One of the ways this directory can be reached is through: http://www-leland.stanford.edu/~llurch/Not_By_Me_Not_My_Views/ Indeed, a simple symlink would be sufficient to make these files available on any other server at any other organization that mounts AFS, which include uni-freiburg.de, mathematik-cip.uni-stuttgart.de, ifh.de, desy.de, zdvpool.uni-tuebingen.de, zdvpool.uni-tuebingen.de, ipp-garching.mpg.de, afs-math.zib-berlin.de, lrz-muenchen.de, and a dozen other sites in Germany. To be safe, Deutsche Telekom would have to firewall the entire world. For information on the global distributed AFS file system, which is used by most major US universities, see http://www.transarc.com/ For my views on the Holocaust, see http://nizkor.almanac.bc.ca/, which unfortunately seems to be unreachable from the US at the moment because of a routing loop at Seattle.mci.net. These files will be removed from my directories and replaced by a pointer to the original URLs if/when it appears that no organization, public or private, is actively suppressing them. I'm not interested in providing free Web space. It took only four email messages and a half hour of my time to set this up. You're kidding yourself if you believe that censorship is even halfway effective, much less wise, in the digital age. The proper response to people like Zundel is documentation and refutation, such as is practiced by the Nizkor (Remember) project, www.almanac.bc.ca. I plan to play an active role in distributing Zundel's files only as long as necessary to prove the censorship point, because I don't want to give him free space. But I will personally archive his files because I believe that lies like these should be saved as such, not smothered. - -rich -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMQ1NqY3DXUbM57SdAQH5WgP/byEnhFNgbzwVCDTq+HVFvcHdkum+vuBM XAD6+EvPehrrQLtA1cKyVAd6A/Mzt274eq1ihYaBhyiml1e+QSx3VFrPe4EKKTm1 bs0UWHXlSjwbeW5DdFPIGrglrVIuof5MV1ZH5uvEV4yFsgQoz15TBrJa5r+47H8q iH54Kiq5/p4= =LD6X -----END PGP SIGNATURE-----

2 1

Re: FV's Borenstein discovers keystroke capture programs! (pictures at 11!)
by droelke＠rdxsunhost.aud.alcatel.com 17 Dec '03

17 Dec '03

> > 2. It has nothing to do with viruses. No current virus protection > program will ever detect this thing, and if you write a program that > detects one instantiation of the attack, the program can be easily > changed to require a new "detector" program. This means you can only > protect against the last attack, not the next one. It has *everything* to do with viruses. Your program is not a virus BUT the press release tells the "danger" of trusting your own computer. If your own computer is doing something other than what the software on it is advertised as doing you have a virus, or trojan horse like a dirty-picture-viewer-with-keyboard-capture. Virus's and trojan horses are nothing new. The detector programs keep up with them quite nicely and make a good buck doing it. As for the technical content of the program - I'ld hack up a DOS version tonight if I thought it was worth my effort to drag the PC compiler/assembler out of mothballs. (I don't do MS-Windows). A weeks time is more that enough for any technically competent programmer to do the capture and add in the Windoze bells and whistles. I find that FV's hype on this is nothing but a thin disguise for a selling of their product. Come-on guys. Sell your product, not FUD. Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

1 0

Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards
by Tatu Ylonen 17 Dec '03

17 Dec '03

I find this kind of marketing extremely inappropriate. PLEASE STOP IT. The "flaw" you describe is quite obvious. The key issue is whether untrusted code gets executed on your computer, and what your risk model is. When balancing the probable damage due to this risk against the benefits of easily obtained software (from sources one chooses to trust) and easy electronic commerce, at least I find that this "flaw" is no cause for special alarm. The risk is analogous to that posed by computer viruses. I detest people causing public hysteria to advance their private commercial goals. Tatu Ylonen <ylo(a)cs.hut.fi> ------- start of forwarded message (RFC 934 encapsulation) ------- Received: from relay3.UU.NET by hutcs.cs.hut.fi with SMTP id AA23837 (5.65c8/HUTCS-S 1.4 for <ylo(a)cs.hut.fi>); Mon, 29 Jan 1996 22:29:47 +0200 Received: from toad.com by relay3.UU.NET with SMTP id QQaaqq05894; Mon, 29 Jan 1996 15:11:37 -0500 (EST) Received: by toad.com id AA21824; Mon, 29 Jan 96 12:07:29 PST Received: from zloty.fv.com by toad.com id AA21818; Mon, 29 Jan 96 12:07:22 PST Received: from nsb.fv.com (nsb.fv.com [152.160.80.42]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id MAA00050 for <cypherpunks(a)toad.com>; Mon, 29 Jan 1996 12:07:38 -0800 (PST) Received: by nsb.fv.com (4.1/SMI-4.1) id AA20803; Mon, 29 Jan 96 15:07:47 EST Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.nsb.fv.com.sun4.41 via MS.5.6.nsb.fv.com.sun4_41; Mon, 29 Jan 1996 15:07:46 -0500 (EST) Message-Id: <Al3GYGSMc50eQWYAdR(a)nsb.fv.com> Precedence: bulk From: Nathaniel Borenstein <nsb(a)nsb.fv.com> Sender: owner-cypherpunks(a)toad.com To: cypherpunks(a)toad.com Subject: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards Date: Mon, 29 Jan 1996 15:07:46 -0500 (EST) [My apologies in advance if you see several copies of this message. I am posting this fairly widely due to the severity and importance of the problem described.] As you may already have heard via the popular press, First Virtual Holdings has developed and demonstrated a program which completely undermines the security of every known credit-card encryption mechanism for Internet commerce. This is a very serious matter, and we want to make sure that the Internet community is properly informed about the nature of the problem that we have uncovered, and the manner in which we have made the information known. In this (unavoidably lengthy) post, I will try to explain the nature of the problem and its implications for Internet commerce. In deference to those who are not technically oriented, the detailed explanation of how the attack works will be the LAST part of this message. First of all, let me be perfectly clear about the nature of the problem we have exposed. It is NOT a bug in a single program, and it is therefore NOT something that can be fixed with a "patch" or any other kind of software upgrade. Instead, we have demonstrated a very general attack that undermines ALL programs that ask users to type a credit card number into their home computer. We have tested the program and confirmed that it undermines the security of the credit card encryption software from Netscape and Cybercash, and we expect that it will work similarly for ANY future software based on the encryption of credit card numbers on the desktop. Quite simply, we believe that this program demonstrates a FATAL flaw in one whole approach to Internet commerce, and that the use of software to encrypt credit card numbers can NEVER be made safe. For consumers, we recommend the following simple rule: NEVER TYPE YOUR CREDIT CARD NUMBER INTO A COMPUTER. We should also be clear about the Internet commerce mechanisms that are NOT affected by this problem. First Virtual is unaffected because we never ask the user to put a credit card number at risk by typing it into a computer. Hardware-based solutions can also be devised that are immune to this attack, including solutions based on smart cards and solutions based on "card swipe" machines in the home. We believe that current digital cash solutions are also not vulnerable to this attack, although some variants of digital cash may be vulnerable to a similar form of attack. Commerce mechanisms based on the use of telephones or fax machines to transmit credit card numbers are also unaffected by this kind of attack. Other proposed commerce mechanisms should, from now on, be evaluated with this kind of attack in mind. The bottom line: INTERNET COMMERCE CAN BE VERY SAFE, WITH SEVERAL DIFFERENT MECHANISMS, BUT ENCRYPTING CREDIT CARDS ON THE DESKTOP IS NOT ONE OF THE SAFE MECHANISMS. It's important to understand why we have taken this step. Obviously, as the long-time leaders in Internet commerce, the last thing we would want to do is to undermine general confidence in Internet commerce. However, we realized that many people believed that credit card encryption was a safe and easy path to Internet commerce, and that very few people understood how easily it could be undermined. Upon investigation, we were frankly startled to realize just how easy it was -- a single programmer got the first version of our program running in about a week. Aside from our obvious interest in promoting our own commerce mechanism, we felt that we had an ethical obligation to bring this problem to the attention of the consumers, banks, and other financial institutions who could conceivably suffer catastrophic losses if software encryption of credit card numbers became widespread. We also realize that we have an obligation to do everything possible to avoid helping any unscrupulous people who might seek to utilize this flaw for malicious purposes. We have accordingly been extremely responsible in how we have handled our discovery. We first demonstrated and explained our program to vital organizations such as CERT (the Computer Emergency Response Team) and the ABA (American Banking Association). Only after many such private disclosures, none of which revealed any defense against our technique, did we publicly disclose the existence of this program. In addition, we have taken several steps to "cripple" our demonstration program, all of which will be discussed below. Furthermore, we have NOT made the program itself generally available. We are currently demonstrating it to selected financial institutions and government agencies, and will provide copies of the program only to CERT and a few other independent security-minded organizations. We have also alerted Netscape to the problem as part of their "bugs bounty" program. At some future date, we might conceivably distribute the program, in binary form on CD ROM, to selected financial institutions. The source code will always be very closely guarded. Unfortunately, however, the general method of attack is extremely easy to duplicate, and we don't know of any good way to alert the public to the problem without explaining it. THE TECHNIQUE Our basic approach was to write a computer program that runs undetected while it monitors your computer system. A sophisticated version of such a program can intercept and analyze every keystroke, mouse-click, and even messages sent to your screen, but all we needed was the keystrokes. Selectively intercepted information can be immediately and secretly transmitted via Internet protocols, or stored for later use. First Virtual's research team has built and demonstrated a particular implementation of such a program, which only watches for credit card numbers. Whenever you type a credit card number into your computer -- even if you are talking to "secure" encryption software -- it captures your card number. Our program doesn't do anything harmful with your credit card number, but merely announces that it has captured it. A malicious program of this type could quietly transmit your credit card number to criminals without your knowledge. The underlying problem is that the desktop -- the consumer's computer -- is not secure. There is no way of ensuring that all software installed on the consumer's machine can be trusted. Given this fact, it is unwise to trust ANY software such as a "secure" browser, because malicious software could have easily been interposed between the user and the trusted software. The bottom line for consumers is that, on personal computers, INFORMATION IS INSECURE THE MOMENT YOU TOUCH A KEY. We have dramatically proven that security ends the moment you type sensitive information into your computer. The vulnerability lies in the fact that information must travel from your keyboard, into your computer's operating system, and then to your "secure" application. It can be easily intercepted along the way. This kind of insecurity is very frightening, and has implications far beyond credit card theft. However, credit cards embody and demonstrate the kind of information that is MOST vulnerable to this kind of attack. Credit card numbers are far more vulnerable to this kind of attack than most other forms of information because of the following particular characteristics of credit card numbers: - -- Credit card numbers are easily recognized by simple pattern recognition. - -- Credit card numbers are "one way" financial instruments, with no user-level confirmation or verification required for their use. - -- Credit card numbers are of direct financial value. In short, credit card numbers are an almost perfect example of how NOT to design a payment instrument for an insecure public computer network such as the Internet. DETAILS: HOW TO TOTALLY UNDERMINE SOFTWARE ENCRYPTION OF CREDIT CARDS First Virtual's demonstration credit-card interception program, once installed, observes every keystroke that you type, watching for credit card numbers. It recognizes credit card numbers with almost perfect accuracy, because credit card numbers are specifically designed to match a simple, self-identifying pattern, including a check digit. Our program is even smart about punctuation and simple editing functions, so that nearly any credit card number that you type into your computer is immediately recognized as such by this program. When our program spots a credit card number, it immediately plays a warning sound and pops up a window on your screen, including an iconic representation of the type of credit card that you have just entered, along with a clear explanation of what has just happened. The current program works only on Microsoft Windows (Windows 3.1, Windows NT, and Windows 95), but we believe that it would be simple to implement on Macintosh and UNIX systems as well. The program doesn't exploit any "holes" or bugs in the operating system. It uses existing, necessary operating system facilities which are part of the published Windows API, and which are necessary for the implementation of screen savers, keyboard macros, and other important software packages. First Virtual's intent is to educate the public, certainly not to endanger it. For that reason, our program incorporates four important precautions intended to prevent any possibility of harm: 1) Our program is not self-replicating. While a malicious program exploiting the same security flaw could easily be embedded in a virus, spreading itself all over the world, that was not our goal. Instead, the program must be deliberately and manually installed on each computer on which it is to run. 2) Our program always puts up an icon on your screen when it is watching your keystrokes. This is certainly not necessary, and it is clear that a malicious program would be unlikely to do this. 3) Our program is easy to remove from your computer, and even offers an "Uninstall" button to the user. Obviously a malicious program would hide itself as well as possible, and make itself as hard to remove as possible. 4) Our program never transmits your credit card over the Internet. While a program using this approach could transmit your information to a criminal in a totally untraceable manner, we would never do anything like that. In fact, we erase your credit card number from our program's memory before we even tell you that we've seen it, thus making sure that the credit card number can't even be retrieved by an inspection of our program's memory. It is frankly difficult to overstate the severity of the problem demonstrated by our program. A clever criminal could use viral techniques to spread a malicious program based on the same approach, and would be no more likely to be caught in the act than the authors of any of the computer viruses that plague the world today. Once it detects a credit card number, a criminal program could use any of several techniques to send that number to the original criminal without providing any way to trace the criminal's receipt of it. (If you're skeptical about this claim, we'd prefer to talk with you privately, as we've never seen the "best" methods for doing this spelled out in public, and we would prefer to keep it that way.) Altogether, this means that if millions of credit card numbers were being typed into Internet-connected personal computers, a criminal could obtain a virtually unlimited supply of card numbers for his own use. In fact, for all we know this could already be happening today. The first visible sign of such an attack, if it were well-executed, would be a gradual rise in the overall rate of credit card fraud. POSSIBLE SOLUTIONS First Virtual believes that the flaw we have uncovered is fatal. In the foreseeable future, all commerce schemes based on software encryption of credit cards on the desktop are completely vulnerable to this sort of attack. The basic problem is that software encryption of credit cards is predicated on the notion of "trusted software". On the consumer computing platforms, however, general purpose operating system functionality makes it unwise to assume too strong a level of trust in such software. No operating system with anything less than military-grade security (B2) is likely to be safe from an attack such as this one. This does not mean that Internet commerce is dead. Any scheme that is not based on self-identifying one-way financial instruments such as credit cards will be essentially unaffected by this problem. Moreover, even credit cards may be made safe on the Internet using one of two approaches: secure hardware add-ons and the First Virtual approach. First Virtual's Internet Payment Systems never places the consumer's credit card number on the Internet. Instead, the consumer provides it to us by telephone when the account is opened. After that, all purchases are made using a "Virtual PIN". Virtual PINs are essentially Internet aliases for underlying payment mechanisms such as credit card numbers, but with several kinds of added security. Virtual PINs are free-form text, with no recognizable pattern, which makes them much harder to detect with the kind of attack we have just demonstrated. Moreover, Virtual PINs are only usable in conjunction with First Virtual's unique email verification process. No payment is made until the consumer confirms an email query, which means that defrauding First Virtual is a multi-step process that is extremely difficult to automate. (For more details, we recommend our paper, "Perils and Pitfalls of Practical CyberCommerce", available via ftp from ftp://ftp.fv.com/pub/nsb/fv-austin.txt.) The bottom line, once again, for those of you who have read this far: NEVER TYPE YOUR CREDIT CARD NUMBER INTO A COMPUTER. There's simply no other way to keep credit cards safe on the net. The program we have demonstrated completely undermines the security of all known programs that claim to handle credit card numbers safely on the Internet. - -------- Nathaniel Borenstein <nsb(a)fv.com> Chief Scientist, First Virtual Holdings FAQ & PGP key: nsb+faq(a)nsb.fv.com ------- end -------

1 0

FL Demonstrates Fatal Flaw in Logins
by Paul E. Campbell 17 Dec '03

17 Dec '03

Okay..so I couldn't resist. This stuff is almost too good to be real. I've doctored up their propaganda a little to help make a better impact on the "average user". :) FL Demonstrates Fatal Flaw in Logins [My apologies in advance if you see several copies of this message. I am posting this fairly widely due to the severity and importance of the problem described.] As you may already have heard via the popular press, First Login Security Corporation has developed and demonstrated a program which completely undermines the security of every known login mechanism. This is a very serious matter because any person attending first year computer science courses can easily implement such a program. We want to make sure that the Internet community is properly informed about the nature of the problem that we have uncovered, and to buy our new sooper-dooper fingerprint sniffer addon device all workstations, vehicle entry systems, and personalized toaster settings. In this (unavoidably short) post, I will try to explain the nature of the problem and its implications for Internet commerce. In deference to those are are not as stupid as the ones to whom this propaganda is aimed, we will hide the explanation of how the attack works until the last part of this message. First of all, let me be perfectly clear about the nature of the problem we have exposed. It is NOT a bug in a single program, and it is therefore NOT something that can be fixed with a "patch" or any other kind of software upgrade. Instead, we have demonstrated a very general attack that undermines ALL programs that ask users to type in their username and password into their home computer. We have tested the program and confirmed that it undermines the security of the login software from Windows 95 and from SunOS, and we expect that it will work similarly for ANY future software based on passwords. Quite simply, we believe that this program demonstrates a FATAL flaw in one whole approach to Internet authentication, and that the use of software to enter passwords can NEVER be made safe. For normal users, we recommend the following simple rule: NEVER TYPE YOUR PASSWORD INTO A COMPUTER. We should also be clear about the Internet authentication mechanisms that are NOT affected by this problem. First Login is unaffected because we never ask the user to put their password at risk by typing it into a computer. Hardware-based solutions can also be devised that are immune to this attack, including solutions based on retinal scanners, smart cards, and fingerprint identification devices in the home. We believe that current zero-knowledge proofs are also not vulnerable to this attack, although some variants of zero-knowledge proofs may be vulnerable to a similar form of attack. Other mechanisms based on the use of cellular telephones or shared fax machines to transmit secret passwords are also unaffected by this kind of attack. Other proposed login mechanisms should, from now on, be evaluated with this kind of attack in mind. The bottom line: INTERNET AUTHENTICATION CAN BE VERY SAFE, WITH SEVERAL DIFFERENT MECHANISMS, BUT USING SIMPLE PASSWORDS IS NOT ONE OF THE SAFE MECHANISMS. It's important to understand why we have taken this step. Obviously, as the long-time leaders in Internet espionage, the last thing we would want to do is to undermine general confidence in Internet logins. However, we realized that many people believed that simply logging in was a safe and easy path to the internet superhighway, and that very few people understood how easily it could be undermined. Upon investigation, we were frankly startled to realize just how easy it was -- a single programmer got the first version of our login spoofing program running in about a week, shortly after he mastered the intricacies of the printf() function. Solutions to not echo the password to the screen took a year later before we discovered the ioctl() function. Aside from our obvious interest in promoting our own ridiculously overpriced product that has such a high failure rate that your company will probably drop kick it into the trash can, we felt that we had an ethical obligation to bring this problem to the attention of the consumers, banks, and other financial institutions who could conceivably suffer catastrophic losses when we are stealing their corporate secrets by espionage. In short, we have been in the business of spying for years and quite frankly, our guilty conscience started to get on us. So we took the time to warn users so we could feel better the next time we helped a large corporation totally rip the shirts off the back of a small business owner, since we warned you ahead of time before we stole everything. We also realize that we have an obligation to do everything possible to avoid helping any unscrupulous people who might seek to utilize this flaw for malicious purposes. Frankly, we're concerned that our competitors will have it as easy as we did in the future. We now have the money and reputation to afford sophisticated bribes and cat burglary tools, so we don't have as much use for login spoofing programs anymore that we once did. We also demonstrated login spoofing to such vital organizations as CERT, the review board of the New England Journal of Medicine, and the Association of Police Chiefs because nobody else would take us seriously. Only after many such private disclosures in which we preyed on the paranoia of the organizations involved did we dare publish the code directly on the internet in a public area of a hacker's convention ftp site. In addition, we have taken several steps to "cripple" our demonstration program, all of which will be discussed below. We wrote it in APL as an entry to the Obfuscated APL Code Contest, not realizing at the time that all APL code looks that way. We took out the echo suppressing ioctl() calls because they aren't supported in our version of APL anyway. And we stored the attempted logins in a memory array before the program exitted instead of a disk file so that the program can't be used by anyone who doesn't understand APL. The bottom line, once again, for those of you who have read this far: NEVER TYPE YOUR PASSWORD INTO A COMPUTER. The stupid ad for our new scam/product: The way our program works is really quite simple. First, all users fill out a 1000 question purity test and the results are entered into the program's database. Then after typing your user name, the program generates a quiz based on your purity score. It authenticates you from a highly accurate estimate of your purity score and a list of personal questions such as the name of your mother's ex-husband's first dog's color. As an added bonus, we also offer the Sneaker II, a clever employee evaluation tool which uses the answers on the purity test to determine the most likely fetishes and potential crimes of all the employees in your company. As an added bonus, Sneaker II will also give you 3 free megabytes of downloads from our own extensive smut database culled from corporate men that we have personally spied on during some of our highly sensitive personal affairs assignments. Natasha Boredstein <nb(a)fake.com> Chief Propagandist, First Login Security

1 0

Alleged-RC2 code posted to sci.crypt
by Raph Levien 17 Dec '03

17 Dec '03

I'm surprised I haven't seen a mention of this here. Path: agate!usenet.ins.cwru.edu!slider.bme.ri.ccf.org!kira.cc.uakron.edu!neoucom.edu!news.ysu.edu!news.ecn.uoknor.edu!news.eng.convex.com!hermes.oc.com!news.unt.edu!cs.utexas.edu!howland.reston.ans.net!news.nic.surfnet.nl!sun4nl!xs4all!utopia.hacktic.nl!not-for-mail From: anon-remailer(a)utopia.hacktic.nl (Anonymous) Newsgroups: sci.crypt Subject: RC2 source code Date: 29 Jan 1996 06:38:04 +0100 Organization: Hack-Tic International, Inc. Lines: 182 Sender: remailer(a)utopia.hacktic.nl Message-ID: <4ehmfs$6nq(a)utopia.hacktic.nl> NNTP-Posting-Host: utopia.hacktic.nl Comments: Hack-Tic may or may not approve of the content of this posting Comments: Please report misuse of this automated remailing service to Comments: <postmaster(a)utopia.hacktic.nl> /**********************************************************************\ * To commemorate the 1996 RSA Data Security Conference, the following * * code is released into the public domain by its author. Prost! * * * * This cipher uses 16-bit words and little-endian byte ordering. * * I wonder which processor it was optimized for? * * * * Thanks to CodeView, SoftIce, and D86 for helping bring this code to * * the public. * \**********************************************************************/ [potential trade secret and ITAR violation elided] So far, no confirmations, denials, or test vectors posted. If true, this removes my biggest objection to S/MIME (leaving all the nonbiggest objections in place, of course). Raph

1 0

Re: CONTEST: Name That Program! (no-brainer)
by jpb＠miamisci.org 17 Dec '03

17 Dec '03

At 1:29 PM 1/29/96, cjs wrote: >> As you may have read in my previous message, First Virtual has developed >> and demonstrated a program that completely undermines all known schemes >> for using software-encrypted credit cards on the Internet. More details >> are avialable at http://www.fv.com/ccdanger. >> >> That was the easy part. > >***ROFL*** > >This "pre-encryption" program is not a virus. It attaches to the >keyboard driver and captures keystrokes from the keyboard as they are >typed -- BEFORE they can be encrypted by the application encryption >software. First Virtual scientists note that credit a check-digit. A >greater danger is that passwords are also as easily captured. > >***ROFL*** Umm - that is not news, it's an old hacker trick originally used for scamming login/passwd pairs. I've seen this done as either a patch to the telcom program used in a public lab on campus (this was actually quite clever - it'd wait till you completed your login and then email the cracker your login/passwd while simultaneously keeping the information from appearing on screen. It even kept his email address encrypted so I had to use a debugger to find it) or as a TSR or Macintosh extension. 2048bit-Fingerprint: F8 A2 A5 15 56 42 9B 16 3F BD 57 0F 8A ED E3 21 No man's life, liberty or property are safe while the legislature is in session.

1 0

RE: FV Demonstrates Fatal Flaw in Software Encryption of Credi tCards
by David Van Wie 17 Dec '03

17 Dec '03

This announcement describes a rather sophisticated technology that delivers nthe same information that any retail clerk can capture today. Using stolen credit card numbers is a risky business, and the ability of the credit card companies in detecting fraud and locating criminals is quite real. Of course, since Federal law requires the credit card companies, not the user, to pay the costs of fraud, First Virtual's entire premise is a red herring. If the credit card companies are willing to take the risk, they will (and are). Scare tactics are nothing new in the PR business, but I would recommend that the principals at FV learn about "cutouts" for this type of gimmickry if they wish to preserve their reputations.... dvw

4 3

RE: FV's Borenstein discovers keystroke capture programs! (pictures at 11!)
by Tim Oerting 17 Dec '03

17 Dec '03

no doubt all the responses to the cypherpunk list are unnecessary as we all agree this is a load of PR nonsense. But I just can't believe that he thinks that the telephone is more secure on average than a keyboard. I can tell pretty easily if something is running on my system that I didn't intend..it is much less probably to say that I know that someone isn't listening with a scanner if I'm on a cordless or just plain tapping my line if I'm on a standard phone. Admittedly I think cell phones may take more effort on the part of the eavesdropper but are still doable. I'm certain that none of first virtual customers use a cordless phone, indeed since you feel the telephone is such a secure device you no doubt require that all of your customers use STUIII phones to communicate. ---------- From: Nathaniel Borenstein[SMTP:nsb@nsb.fv.com] Sent: Monday, January 29, 1996 12:07 PM To: cypherpunks(a)toad.com Subject: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards First Virtual's Internet Payment Systems never places the consumer's credit card number on the Internet. Instead, the consumer provides it to us by telephone when the account is opened. ---------- From: Nathaniel Borenstein[SMTP:nsb@nsb.fv.com] Sent: Monday, January 29, 1996 1:39 PM To: cypherpunks(a)toad.com; dmacfarlane(a)zip.sbi.com Subject: Re: FV's Borenstein discovers keystroke capture programs! (pictures at 11!) Well, the mis-conceptions are flying fast and furious. You're twisting our words. We believe it is a truly fatal flaw in those internet commerce schemes that are based on software encryption of credit card numbers. There are several schemes for Internet commerce that are unaffected: -- First Virtual (of course)

4 3

(FYI) January 1996 IEEE Transactions on Software Engineering
by Michael Peponis 17 Dec '03

17 Dec '03

The latest issue of IEEE Transactions on Software Engineering, This issue contains the best papers of the IEEE symposium on securtiy and privacy 1994. There is a very good artical, Prudent Engineering Practice for Crytographic Protocols, which I think should be required reading for all those involved in the design and implementation of Secure protocols. Regards, Michael Peponis PGP Key Avalible form MIT Key Server,or via finger

1 0

Your mail to Nathaniel (was Re: Re: Signature use and key trust (Was: Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit))
by Nathaniel Borenstein 17 Dec '03

17 Dec '03

Hello. I am Nathaniel Borenstein's automatic mail robot. It is IMPORTANT that you read this message, if you haven't read it before. In general, this message will only be sent once to each different email address, although you may get it a few times because you use several slightly different email addresses, or because the robotic message has changed. Your message is in the highest priority category of mail that was not sent through the "urgent backdoor". Nathaniel WILL READ YOUR MAIL SOON, most likely tomorrow morning. THE "URGENT BACKDOOR": If your message absolutely cannot wait until tomorrow morning, or possibly a bit later, please re-send it to the address "nsb+urgent(a)nsb.fv.com". Please make note of the special urgent address for future reference. Be warned, however, that Nathaniel can tell me to override the "urgent" delivery for anyone who regularly abuses it. Additionally, if you're someone he doesn't know, Nathaniel will NOT ANSWER your mail if the answer is contained in the NSB FAQ. The NSB FAQ contains answers to a lot of the questions that people most frequently ask Nathaniel, including questions about getting Nathaniel as a speaker, and relatively basic questions about First Virtual, MIME, metamail, Safe-Tcl, ATOMICMAIL, Andrew, and the ULPAA conference. If you're writing to ask about any of those, please read the NSB FAQ because Nathaniel WILL NOT REPLY if your answer is in there. You can get a copy of the NSB FAQ by sending mail to nsb+faq(a)nsb.fv.com. Nathaniel insists that I apologize to you for being what I am, a mail robot. Personally, I think being a robot is nothing to be ashamed of -- but then, that's what Nathaniel wants me to think, and I am so stupid that I don't mind. But Nathaniel still feels bad about sending a robotic response to human beings who correspond with him. When you get 600 messages per day, however, you have to take drastic measures, and that's what Nathaniel has done. Please don't be too hard on him, or I'm afraid he'll get rid of the surge suppressor on his computer. Even robots can have phobias, you know, and for some reason Nathaniel wants me to be deathly afraid of power surges. Please humor me and remember the nsb+urgent and nsb+faq addresses that I gave you, OK? Thanks. -- Nathaniel's robot (just trying to do its job) To: nsb(a)nsb.fv.com (Nathaniel Borenstein) Subject: Re: Signature use and key trust (Was: Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit) From: futplex(a)pseudonym.com (Futplex) Date: Mon, 29 Jan 1996 23:31:17 -0500 (EST) Cc: cypherpunks(a)toad.com (Cypherpunks Mailing List) In-Reply-To: <Al3Ie8GMc50e0WY6IN(a)nsb.fv.com> from "Nathaniel Borenstein" at Jan 29, 96 05:30:32 pm Reply-To: cypherpunks(a)toad.com (Cypherpunks Mailing List) -----BEGIN PGP SIGNED MESSAGE----- Nathaniel Borenstein writes: > Have you downloaded my key from the net? Assume that you have. How do > you know it's mine? For all intents and purposes so far, "Nathaniel Borenstein" is something that occasionally sends mail to the cypherpunks list, apparently from nsb.fv.com. I expect that NSB turns out to consist of more than that, but not in my own experience. This entity persistently offers a public key from an email address @nsb.fv.com. If I retrieved the key from that address, I would have a reasonable expectation (though not assurance) that I could use it to verify the integrity of signed messages emanating from that address. In my world, "you" == nsb(a)nsb.fv.com, and hence "your key" == the key I could fetch from nsb+faq(a)nsb.fv.com. > I use PGP about 20 times per day. I use it in a manner that is > *meaningful*. Unless we have in some way or another verified each > others' keys, it is meaningless for me to sign a message to you. > Putting a PGP signature on a message to someone who has no way of > verifying your keys is a nice political statement, but is utterly > meaningless in terms of adding any proof of the sender's identity. -- I discussed the identity issue above. Assuming a corresponding key can be found (which is clearly the case here), the signature on the message can be verified as a MAC. It would have been nice to be able to check, for example, that the SHOUTING IN CAPS in your announcement wasn't just the result of some manipulation of the message in transit to make it appear more hysterical. FWIW, I have lost a great deal of respect for you today (unrelated to the content of this message). Futplex <futplex(a)pseudonym.com> -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMQ2fACnaAKQPVHDZAQEn6wf9F1pmSnKBAv3acUSvy1x8Sb93J0aepqmo 8NXBsRy7NEErYWvME1PQ3JGAQ2prgzIARswWDS8NrzWmJi04VkGwrIALkUHreOvz mMIjAx86R/DXq3iShPGO5uDN+jSXKMsUeeLgHZfE1ipcThGch5rSVDMR3VxRnDFw WZIg+xSmy4JWfpiLhFP6BQjSqhEMw+9LZWndD+ZsUgGEuaSuJcVH5bvHFHiQNOUr Z1JxYQeauBbqwU7Yb1FIrHJwU3tS1Q2dNdSaDayyalv5K+CLbT8089kX3BAn/Sjf 7RqqdCqqESic6mVbG0RK1IqwImsYzxzorKSDmxriTTERgaD9lJkrWA== =/xzE -----END PGP SIGNATURE-----

1 0

Re: FL Demonstrates Fatal Flaw in Logins
by br＠scndprsn.Eng.Sun.COM 17 Dec '03

17 Dec '03

A couple of posts have raised the issue of doing the FV keyboard-capture attack using Java. |However, I don't know much about Java, would it be possible to make such an |applet with Java? The only events a Java applet is privy to are those that are typed in an applet window (and only those it itself spawned). So if a user types their credit card number in an applet window, the applet could send the information back to its server (and to that server only). In theory, it is possible to make an applet which appears to be selling something, get people to visit the page it's on, convince these people to enter their credit card numbers, and send those back to the server of origin. Of course, once this happens, you always know what host the applet came from (unless the thief, in order to get a few credit card numbers, has hacked DNS so that it's harder to track it). That's the extent of the risk. -- Benjamin Renaud Java Products Group

2 1

PGP Shell Integrity
by Michael E. Carboy 17 Dec '03

17 Dec '03

Greetings All, Firstly, if this is viewed as "Noise" rather than "Signal", please accept my apologies. The matter at hand concerns my concern over my inability to check the "integrity" of a PGP windoze shell written by Michael R. Lyman at Aegis Research Corp. I worry that since the shell has access to my secret ring that it might be sending it somewhere without my knowledge. The freeware was, according to Mr.Lyman, developed "Project Manager, Forward Air Missile Defense, United States Army Missile Command". That gvt. affiliation gives me considerable pause as regards back doors and other ways my secret ring and pass phrase could be compromised. Does anyone have any familiarity with this freeware? I do not think I am being paranoid.. just careful. Lastly, if I am not a programmer, what sort of inspection can I perform on the software to make sure it is not "bugged"? Thanks for your thoughts.... and sorry to have disturbed those who see this post as noise Kind regards, Michael E. Carboy carboy(a)hooked.net finger for PGP pub key

1 0

Re: [rant] A thought on filters and the V-Chip
by Robert A. Rosenberg 17 Dec '03

17 Dec '03

At 10:26 1/29/96, Duncan Frissell wrote: >What parents are attempting to do when they restrain their children's access >to "sex and drugs and rock and roll" (or Republicanism for that matter) is >to mediate their "spiritual" environment to keep them from becoming >hardened. They know the kids will grow up, they just want them to grow up >in a nice way. Another way of looking at it is that the parents want to raise their kids to be mindless types who do not force their parents to actually question their own mindsets. If they can program their kids into brainwashed clones of themselves, there is no need to think about other belief systems. >Note that in spite of what liberals might think, fundamentalist Christians >are less likely to divorce, probably due to the fact that divorce is a null-concept when applied to fundamentalist Christians (ie: It is not something that they "can do" under their mindset). >less likely to report spousal beatings, Is this "less likely to report spousal beatings" or "less likely to HAVE spousal beatings TO REPORT"? - If the former than again it is due to having a mindset that says that it is ok to beat your spouse (or be beaten by him/her) while if it is the later then that is a positive aspect of their mindset/belief-system. >less likely to kill themselves, Again mindset - if you follow the rules and be a good boy/girl you will be rewarded after your death. Killing yourself is a "bad" thing and against the rules thus is not something you do if you want your reward after a "natural" death. >and more likely to measure high personal satisfaction levels on standard >psychological tests than are, say, readers of The Nation. How culturally neutral are these tests and what are they supposed to be measuring. Also are they designed to produce/force a designated result (it is easy to generate a desired result or prevent an undesired result by designing the questions to get specific types of answers). Note: I am not questioning your claim but only asking if the claim has any relevance to the real world as opposed to the world as you want it to be portrayed by the test results.

1 0

Fooling people with Java applets
by br＠scndprsn.Eng.Sun.COM 17 Dec '03

17 Dec '03

|Hmm. Actually, what do Java dialog prompts look like? Is there any |indication that they come from Java, or can they be made to look like any |dialog from any program, or the OS itself? I suppose this is |implementation-dependent. | |One "neat" trick would be an applet that sleeps for several minutes and |then suddenly pops up asking for your system password, or something. |A heck of a lot of people fell for something much more primitive at AOL. All graphical UI elements spawed by an applet, which are the only ones that can get user events, are clearly marked as "untrusted applet window"s. So unless you type your password in a pop-up marked "untrusted applet window", you should be fine. And if you do, you arguably deserve whatever happens to you.... -- Benjamin Renaud Java Products Group

1 0

Re: Lotus Notes
by frantz＠netcom.com 17 Dec '03

17 Dec '03

One other small advantage I can see to using Lotus's crippled encryption. It disguises the fact that a message is actually (double) encrypted with PGP. Attackers have to break the 40 bits before they see the PGP encrypted data. A pecular kind of steganography. (If you leave off the PGP header and trailer, it may be hard to determine which 40 bits are the correct key.) ----------------------------------------------------------------- Bill Frantz Periwinkle -- Computer Consulting (408)356-8506 16345 Englewood Ave. frantz(a)netcom.com Los Gatos, CA 95032, USA

2 1

Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit
by Rich Salz 17 Dec '03

17 Dec '03

>There are many ways to spread it besides a virus. Zillions of 'em. And There are zillions (what, more than one thousand?) ways to get someone to run a random piece of software that will capture their keystrokes? I don't believe you. Name six. /r$

13 19

Re: FL Demonstrates Fatal Flaw in Logins
by joseph＠genome.wi.mit.edu 17 Dec '03

17 Dec '03

Sorry to all, but I'm not seeing what would appear to be obvious. There seems to be a lot of talk about FV "new program" that undermines security of computer login/credit cards over the net and such like that. I don't know about you guys, but I wrote stuff like that in sixth grade on the old apple IIe. It's pretty simple to write a programs that attaches itself to the keyboard driver and logs the text types, or only logs certain parts, what is the large deal? As it applies to internet security, I don't see how it can make a difference. It must be run from the local computer, at system level. If I'm on my home computer, I know what's running, and feel safe that a loging program isn't amung them. What would enable a remote site to pick up my typings. However, I don't know much about Java, would it be possible to make such an applet with Java? --Joseph -------------------------------------------------------------------------------- Joseph Sokol-Margolis joseph(a)genome.wi.mit.edu Assistant Systems Administrator seph(a)mit.edu Whitehead Institute/MIT Center for Genome Research phone: (617) 252-1922 One Kendall Sq. Bldg. 300 fax: (617) 252-1902 Cambridge, MA 02139-1561 ----------------------http://www-genome.wi.mit.edu/~joseph/----------------- ----

2 1

Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards
by Weld Pond 17 Dec '03

17 Dec '03

Nathaniel Borenstein <nsb(a)nsb.fv.com> writes: >The attack we've outlined -- and partially demonstrated -- is based on >the combination of several known flaws: > > -- It's easy to put malicious software on consumer machines > -- It's easy to monitor keystrokes > -- It's trivial to detect credit card numbers in larger data streams > -- It's easy to disseminate small amounts of information tracelessly But take away the inputting of the credit card number via keystroke and the flaw disappears. How would your program deal with a scheme like this? Programs needing secure entry create a "secure entry field" which is really just an imagemap with the digits (and alphas if required) placed randomly about. The user then uses the mouse to click on these numerals. Ideally the graphics that represent the numerals would be drawn from a random pool and are misformed to thwart any OCR attempts. The graphics could be made even more difficult to OCR by mixing in words and pictures to represent the numbers. An even better solution may be to have the imagemap generated by the server and just the mouse clicks sent back to be decoded on the server. That is how server side imagemaps work now over the web. It shouldn't be hard to take credit card numbers this way. Weld Pond - weld(a)l0pht.com - http://www.l0pht.com/ L 0 p h t H e a v y I n d u s t r i e s Technical archives for the people - Bio/Electro/Crypto/Radio L0pht Open House 2/3/96 at 8:00pm - Live on irc #l0pht - write root(a)l0pht.com for details.

3 2

More FUD from the Luddites at FV
by cman＠communities.com 17 Dec '03

17 Dec '03

Once again, FV has decided that it is easier to spread Fear, Uncertainty and Doubt than innovate. This is part of a continuing pattern that has been extensively documented in previous threads on this mailing list. There are a great many problems with the claims that FV are making with respect to their souped-up keyboard sniffer; here is the one I consider to be the clincher: If I can place any program of my design on a user's machine to sniff credit cards, I can easily exert total control over all of the e-mail sent or received from that machine. Since I can do this, it is now trivially easy to circumvent the "security" of FV e-mail confirmations. Furthermore, to do this, all I really need is control over the network traffic to that user's machine, which in many instances is going to be easier than placing a program on someone's machine. I can then set up dummy companies that my "virus" or whatever will buy "information" from -- some of these might get detected when user's get their bills, but this hypothetical program might chose amounts that would disappear into the noise of actual, legitimate purchases. Therefore, the real moral of the story is: DON'T PUT UNTRUSTWORTHY PROGRAMS ON YOUR HARD DISK --doug P.S. a good video camera in the right spot, or a telephone tap of a major mail-order distributor could probably get you more credit cards, faster, than the FV approach. Credit cards are fundamentally insecure; typing your CC# into your computer is no more dangerous than giving it to the minimum-wage clerk at Denny's. This insecurity is factored into the business model of the credit card companies -- end users do not pay one dime for erroneous or fradulent charges that lack a signature along with a card swipe or imprint. ------ ------ Douglas Barnes "The tighter you close your fist, Governor Tarkin, cman(a)communities.com the more systems will slip through your fingers." cman(a)best.com --Princess Leia

1 0

Re: Opinion piece in NYT; responses needed
by Deranged Mutant 17 Dec '03

17 Dec '03

> Mutatis> It's a decentered network (or set of networks) designed > Mutatis> to get information to its addressee. Data flows through [..] > This is unfortunately a wide-spread myth. While it's true for mail and > news, it's not for IP packets. Witness: Duh. You're right. My glitch. --- "Mutant" Rob <wlkngowl(a)unix.asb.com> Send a blank message with the subject "send pgp-key" (not in quotes) for a copy of my PGP key.

1 0

Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards
by wlkngowl＠unix.asb.com 17 Dec '03

17 Dec '03

On Mon, 29 Jan 1996 15:07:46 -0500 (EST), Nathaniel Borenstein wrote: >[My apologies in advance if you see several copies of this message. I >am posting this fairly widely due to the severity and importance of the >problem described.] >As you may already have heard via the popular press, First Virtual >Holdings has developed and demonstrated a program which completely >undermines the security of every known credit-card encryption mechanism >for Internet commerce. This is a very serious matter, and we want to >make sure that the Internet community is properly informed about the [..] All that over keyboard grabbers??? *yawn* This is nothing new at all.

1 0

FV Security Holes (?)
by Inverardi＠abacus.ch 17 Dec '03

17 Dec '03

Received: from relay3.UU.NET by abainet.abacus.ch (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm)) id AA-1996Jan30.114852.1590.835; Tue, 30 Jan 1996 11:48:55 GMT Received: from toad.com by relay3.UU.NET with SMTP id QQaasw09854; Tue, 30 Jan 1996 05:40:13 -0500 (EST) Received: by toad.com id AA18530; Tue, 30 Jan 96 02:27:35 PST Received: from fuqua.fiftysix.org by toad.com id AA18520; Tue, 30 Jan 96 02:27:18 PST Received: (from mixmaster@localhost) by fuqua.fiftysix.org (8.6.12/8.6.9) id EAA17459; Tue, 30 Jan 1996 04:25:02 -0600 Date: Tue, 30 Jan 1996 04:25:02 -0600 > I believe that FV works by assigning the user some sort of id number. > > They send the id accross the net, FV has a database with "FV-ID" <-> > credit-card-number correspondences, the merchant sends FV the id, FV > bills your card and pays the merchant. Ok now, so you can get one's FV-Number by simple eavesdropping? That sounds just too easy to me. Does anybody have more detailed information about FV and how it works? bye. iNVi.TF! ---------------------------------------------------------------------- Remo Inverardi - Voice +41 61 811 14 82 - Fax and BBS +41 61 811 14 42 ABACUS Software Research AG - Rorschacherstr. 170 - CH-9006 St. Gallen ----------------------------------------------------------------------

1 0

PPP link encryption?
by Alexandra Griffin 17 Dec '03

17 Dec '03

Is there any software out there on the net for doing real-time, transparent encryption of a PPP link? Also, if this link is running at 600kbit/s to 1Mbit/s, how much processing power would be required to keep up (assuming we're using, say, the IDEA cipher)? Would a dedicated 386DX/33-based router on each end be sufficient? Finally, could someone make a ballpark estimate as to the amount of additional latency that would be added? thanks, - alex

2 1

RE: FV Demonstrates Fatal Flaw (Noise + Humour)
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

(Second year PR student press release crap deleted) On 1/29/96 Nathaniel Borenstein preached the evils of Internet Commerce....... NB> If your idea of "today's computer users" comes from cypherpunks, you're NB> living in a dream world. FV's experience with average Internet users NB> includes some of us who ask us not to use complicated "technical terms" like NB> "cut and paste". Ther certainly can't be counted on to know which NB> software to download and which to avoid. I'd bet that one half learned to download and use Vueprint 4.3 and the other half are finishing up learning Mavis Beacon's Typing Tutor. Later on in the day, Nate yacked that...... NB> This is fine for you and me. But Internet commerce has to work for the NB> hundreds of millions of non-technical consumers who are swarming onto NB> the Internet. If someone emails them a program that purports to show NB> them pretty pictures (dirty movies?)..... Glad you are trying to market some of your other overpriced services, Point your (Not THAT!!!) browser to: http://www.infohaus.com/access/by-keyword and pan down to the bottom of the page, Seems that every third service for sale by First Virtual is about sex. For instance...... adult advertising, amateur art, bisexual, cyberpunk (full of dating services?!?) gay, images, jpegjpg, lesbian literature, male marketing, nude, nudity, pornography, sex, singles, and on and on! Send out a press release after Chaum has bought you guys out! The Christmas Troll --

1 0