December 2003 - cypherpunks-legacy

None
by Mr. Nobody 17 Dec '03

17 Dec '03

In article <ad32cd9601021004af4e(a)[132.162.233.188]> jrochkin(a)cs.oberlin.edu (Jonathan Rochkind) writes: > 3) 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. Now, if I'm correct about how FV works, > we could clearly write a program that searches your HD for FVs data files, > extracts your FV-ID from it, and steals it. It could be a virus, it could > send the FV accross the net, whatever. We could then use your FV-ID to > make fraudulently make purchases through the FV system that would be billed > to you. This is essentially the same attack as FV "demonstrates" against > software encrypted credit cards over the net: that is, the "You have an > insecure system and if we can put evil software on it, we can get you." > attack. This sounds like a fatal security flaw in FV's system! We need to publicize this fact widely to prevent innocent people from using their FV accounts from computers or over the network.

1 0

Page one, NY Times, 29 January 1996
by Matt Blaze 17 Dec '03

17 Dec '03

One of those microscopic bottom-of-page-one ads from John Young: "BOYCOTT ESPIONAGE-ENABLED SOFTWARE", with phone number and email address to contact for more information. I'd be curious as to what the response has been like. -matt

2 1

Re: Time codes for PCs (fromn German Banking)
by JR＠ns.cnb.uam.es 17 Dec '03

17 Dec '03

From: SMTP%"jimbell(a)pacifier.com" 27-JAN-1996 03:43:05.83 >A peripheral I've long wanted to see, commonly available: ACCURATE time, >broadcast to the millisecond/microsecond/nanosecond, available from sources >as varied as TV VIR's, FM subcarriers, and other sources, available as an >easy input (via a peripheral card) to a computer. > Yup! Do you think it is really possible? If I remember well speed of light is 300.000 Km/s. That means that light takes around 1 ms. to cover 300 Km. If you use a satellite, antenna, whatever to broadcast a timing signal, the accuracy will depend on when do you receive it, and that in turn on your distance from the source. By the time the signal reaches you it may be several milliseconds old (and thousands of microsenconds and millions of nanoseconds). We are so used to think of TV, whatever as an instantaneous broadcast medium that we forget that there are speed limits in the Universe. And you can't exceed them by just paying a ticket. Note that this was a best case scenario: using the speed of light to transfer the information and using the shortest path. In reality most waves won't travel as fast in the air, and will depend on atmospheric circumstances. >I have a 12-year-old Heathkit "Most Accurate Clock" that I assembled myself, >and had the foresight to install it with its computer interface option. >(receives 5, 10, or 15 MHz signals broadcast from Boulder, Colorado, >containing "exact" time.) > Just remember that the best you can get would be microseconds if you're in a 300 meter radius, or milliseconds on a 300 Km. And possibly nanoseconds at 0.3 m. Even then you need to know exactly (i.e. with an accuracy of between centimeters to a few Km depending on the timing you want) your position. And depending on the media you use, possibly the atmospheric conditions in between the emisor and your receptor. Then remains the cypherpunk part on all this: how can you trust the *signal* your receptor receives? How do you know no one is interferring it or sending an inaccurate or false one? So you need a GPS... And a timing source that can be trusted. You'd wantthe signal not to be tamperable or at least to be able to detect when it has been tampered. And that on a broadcast system. A system owned by someone who you may not trust (say a private TV channel, radio or satellite). So you may want to have several sources, and to be able to verify that the signals you receive all come from their respective sources. Yum! a nice problem to think about. One factor is that you wouldn't expect changes in public sources used by sensible systems since those could not pass unnoticed and might raise big protests. But you still have the MITM attack to consider... Oh well, it's too late now. See ya... jr

1 0

Re: Here's how you put your key on the keyservers...
by jim bell 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 07:39 AM 1/29/96 -0500, Ted Garrett wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >I got a message in response to a request I made to someone for their public >key. I wanted to check the signatures that they included with their posts >to cypherpunks, but their key was not on the keyservers. The key they >included was completely unsigned, and when I use it to validate their >previous posts as well as the message they sent which included the key, the >signatures come back as bad, the contents of the file changed. Names are >appropriately withheld (I hope). At this point, I think it would be appropriate to declare that I am the person Ted was communicating with, and the one he is referring to and (correctly, as I recall my own posts) quoting. I am, yes, a real newbie, and I appreciate the indirect lesson in "nettiquette" he is showing by not identifying my private email to him. I'm identifying myself for a number of reasons: 1. I REALLY am a newbie (at least to most of Internet, and common usage of PGP, etc.), and haven't learned much of the ways of Internet. (with a strange, short, early exception, which I will relate in another message if anybody has any interest in Internet history.) 2. I want to solve the problems Ted presumably correctly identified in my signing. (I use freebie Eudora, and WPGP, etc.) I only started signing my posts when I got a copy of WPGP by Gostl, and it made things much easier. 3. I did not want to make it difficult for him to fight off a potential MITM attack while, at the same time, complying with "nettiquette", especially seeing as how my key is not (yet) in any keyserver, which is obviously MY fault, not his! I want him to be able to point (and, repost, with my full permission) any messages allegedly from me that he receives by private email, so that others might check the signature too with their own software. This permission to him applies to any prior messages I've sent him, too, ideally so that anyone else can check the signature status against my sig. Ted may be right; there may be a MITM attack. More likely, it's a case of galloping NEWBIE-ITIS on my own part, sorry. Earlier, when I just began using WPGP to sign Eudora stuff, I was told that my signature didn't match. On the other hand, I was told by others that this is a common flaw of signing messages, having to do with line lengths. When I first started sending messages, I didn't use the "Wrap" selection of Eudora (under the EDIT selection), meaning that my lines were as long as the paragraphs were typed. Most people didn't seem to notice, I guess, because it took somebody a few weeks to eventually complain. After that, I RTFM'd and adopted the practice of WRAPping my paragraphs to limit their length to "reasonable" values. (although I would appreciate somebody explaining to me why this DAMN EUDORA can't seem to correctly re-wrap a paragraph after modification. Hell, Wordstar Version 3.0 for CP/M (shows you how long _I've_ been into computers!) reformatted paragraphs just fine back in 1982 on a 12.5 MHz Z-80 (ask me how I did this and I'll tell you a LONG story!) 3. Ted began to suspect a "MITM attack." While I'm a newbie, I'm well aware this is "man in the middle" and am aware of the potential (dangerous!) implications. Needless to say, I can't even say for certain that such an attack isn't happening. Yes, I am on no keyservers, yet, but I will try my best to follow his kind instructions and accomplish this feat. And yes, I am reminded that I need to sign my OWN public key, which (being a f______ newbie), I haven't even done yet! (This message will contain, however, BOTH my 1024-bit and 2047 bit public keys, unsigned, and I will sign the whole message with my 1024-bit key. I'd sign it with BOTH, but I don't know if WPGP will even do this. I'd sign a second copy with the 2047-bit key, except that would be wasting bandwidth. > As I understand the bcc: definition, only >I and the first smtp server this message hits should know who it's to. I >don't know if anyone else reading this mailing list needs this info, but >just in case... here's my reply to the message. > >At 10:03 PM 1/28/96 -0800, you wrote: >>Sorry, I'm a newbie to Internet, and also the Internet usage of PGP. I just >>participated in a local keysigning meeting, so maybe my key will find its >>way to a server. I wrote that. >Don't worry about being a 'newbie'. Everyone starts somewhere. However, >your key will usually not 'find its way' to a server without you >specifically sending it. Thanks; I sorta assumed that, but until recently my usage of PGP was between me and my friends who knew me by face and voice, and who have my keys from hand-carried floppy disks that I gave them myself. > The keyserver I usually use is accessed by sending >a mail message which fits the following format. As far as I know, all the >keyservers use this format to add or update keys in their databases. You >only have to send it to one keyserver, and it will propagate to all the >others. I have indented the text so that no handlers decide to interpret it >as a new message. Okay, thanks for the details. > >- - To: pgp-public-keys(a)pgp.iastate.edu >- - Subject: ADD >- - >- - -----BEGIN PGP PUBLIC KEY BLOCK----- >- - Version: 2.6.2 >- - >- - [key deleted to protect the innocent] >- - >- - -----END PGP PUBLIC KEY BLOCK----- > >>I'm sorry to have to admit that I don't even know how to do this! Newbie >>alert! Again, I wrote that. >If you don't admit you don't know something, nobody will usually tell you >how to do it. Also, you should sign your own key. That will make it harder >to forge, I think. Okay, up until now I've generally given out my key in messages, and signed the entire message with the key. > The reasons were spelled out in a couple of the web >pages I read, but I've forgotten them. It has something to do with either a >denial of service attack or a man in the middle attack, or both. The >command to do this is: Someday I'm gonna understand this stuff! > >pgp -ks 0xHEXKEYID > >Honestly, I've only just begun to use pgp myself. Also, you should add your >e-mail address to the user-id of your key. The command to do so is: > >pgp -ke 0xHEXKEYID > Again, much appreciated. I hate to RTFM. Lazy bum, I. >You will be asked if you wish to add a user id to the key. Say yes, and >give it your e-mail address. What this does is it allows people who are >using pgp-enabled mailers to directly encrypt messages to you without >choosing your key manually. > >The reason that I have not encrypted this message to you using the key you >provided is that when I extracted the key and re-checked your message, the >signature was no good. I've found that (using eudora) I must turn off the >word wrap feature of my mailer to allow for good signed messages out. Of >course, having said this, I'll probably not get a good signature on this >message. Let me know if it signs ok. I didn't check the signature of his message, admittedly. Guess I need to give him some feedback, huh? >Now, I have a question. Which attack(s) is/are a person vulnerable to when >distributing an unsigned public key in the open? Could this actually be a >complex man-in-the-middle attack? Am I paranoid? Unfortunately, the more I learn about encryption, the more "paranoid" I get! Of course, I have a few more reasons than most, but... [I deleted Ted Garrett's signature. My own will follow my own two public keys.] My 1024-bit key. - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAi1zvWcAAAEEAKmSqngLWK2N2gOJKPtjF9VCfSkXY+XUZBRCbbFU71uH/dLX C2Uq6wFS8alRgMc3rp90JnnJ/6eJqXwMjCunogwucWOaU7S/w+OwjOG9fUqsXIA6 2j25Wtjce65mbp0TKLAzwMb/P/Qq7BlclqhuKzfVBH7dIHnVAvqHVDBboB2dAAUR tBFKYW1lcyBEYWx0b24gQmVsbA== =G3LA - -----END PGP PUBLIC KEY BLOCK----- My 2047-bit key. - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQENAzDCFH4AAAEH/15sMvnnK1BIvLkxQsKwUHP7dKNFbKrQOtOoyLOFTk4/0Zlr gXkKw6NciDYaOKwW9dsIL3N3rjAlWtioQ/gg+5vMNoJOQXpp95mKBzpWYLeaB8MF Km6H/NGWISx5cz06NOGutWcaezO/S4xm8ay7W8HaZ4EmHQdXtSKIAL41PBQyyuhR wIKX+QwsAgKS1LALr9MuW7nXL6/h139QeNRAR+ubXyftoklFHC+HF+jcTTDuNjmU 4p7BEMp9cmYHh6WEYTZyOz5F8/8gtEbPA0IKsQH1LGdf+2APLqMdciuU8ALZA+ZM bbaBaxshqHbYfCQ8+ATCrBjsU0nO8RKjhSx91vkABRG0DUphbWVzIEQuIEJlbGw= =uncA - -----END PGP PUBLIC KEY BLOCK----- James Dalton Bell. Klaatu Burada Nikto Something is going to happen.... Something... Wonderful! -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMQ1PZ/qHVDBboB2dAQE+AAP+MP5hM2j1Z3z+7cdZ/U12qH/uu6Dq2NEP LgKJ8Nm0idN7oiBZpYD2zuT22mhsIhCJzzmC3XIBiyX1AP4voDqrIwgLmvPgogcp Cr9p75xi2/UqV1mrYIWeHG4KJc+/x5V4PxeYg5iz0jjnLKN1mzmnjPRDqAOaaBhK 08MMgOkqxFs= =jU9M -----END PGP SIGNATURE-----

1 0

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

Re: "Gentlemen do not read each other's mail"
by jim bell 17 Dec '03

17 Dec '03

At 02:15 PM 1/29/96 -0500, Alan Pugh wrote: >>It isn't clear to me that the Constitution grants "rights" to the government >>that aren't already possessed by the people themselves. Would that even be >>possible? "Powers" maybe, "rights," maybe not. > >the constitution is an amazingly consistant document internally. take a slow >read through it and you will see that you are absolutely correct. when >'people' are being referred to, the term used is 'rights'. when it is a >governmental organization (state or federal), the term used is always 'powers'. Thank you for verifying concurring. I haven't read the Constitution in a few years, so I was a bit hazy, but I think I managed to hit the nail reasonably well on the head.

1 0

<fwd> FV's crypted credit card "attack"
by vin＠shore.net 17 Dec '03

17 Dec '03

Date: Mon, 29 Jan 1996 15:43:53 -0500 Subject: IP: FV's position on Merc article Date: Mon, 29 Jan 1996 10:44:26 -0500 (EST) From: Nathaniel Borenstein <nsb(a)nsb.fv.com> ================ 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 Vin McLellan +The Privacy Guild+ <vin(a)shore.net> 53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*>

1 0

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

17 Dec '03

At 15.07 1996-01-29 -0500, Nathaniel Borenstein wrote: >NEVER TYPE YOUR CREDIT CARD NUMBER INTO A COMPUTER. This problem is greatly exagerated. The software simply won't be running in the average users machine. If the program propagates like a virus, it will soon be catched and killed by the anti-virus utilities that any responsible user is already running on a regular basis. If you have to start the program for it to do its magic, then just don't start it. Todays computer users should know that running software you don't trust is generally a bad idea. That's how you get a virus in the machine in the first place... Come on Nathaniel, admit it, it's a scam to sell FV's expensive services! matts

2 1

Re: [Fwd: Netscape, CAs, and Verisign]
by Peter Williams 17 Dec '03

17 Dec '03

>I'd like to see a less centralized CA that's tied into the existing system >of notaries. The idea is to make it necessary to spoof a notary in order >to spoof the CA. That won't make spoofing the CA impossible (nothing >will), but it will make spoofing the CA illegal. You might wish to look at the Apple DigiSign design. RSA DSI ran a CA under contract as a notary enrollment system for 2 years. The people from RSA DSI, now at Verisign, have a certain amount of experience with this system. I dont understand how you intend to make CA spoofing illegal. Who who perform the enforcement? (By illegal, I assume you mean that there is a criminal offence involved, rather than a tort.) > >A notary could apply to the CA for the right to work as an agent, for a >nominal fee (<$100/year). Only notaries could be agents. If a person >wants a certificate, they'd come in and present ID and a key to the >notary/agent. The person would have to present a form document stating >that he's requesting the cert. The notary would stamp the form and affix >a signature to the key which would enable it to be processed automatically >by the CA. This has been tried, and many certificates issued under a variant of this scheme. it seems likely that only an ABA-certified notary would be reasonaby secure from professional liabilities. Good efforts have been made to qualify what the professional procedures would be. > >Fees for the whole procedure ought to be less than $30. The CA ought to >operate off of the fees from the agents as a non-profit organization, and >the agents ought to keep the fees paid by the people requesting the >certificates. Notary fees might be best controlled by the notary, not the CA. Seems an unreasonable restriction of trade to price-fix, even at the low-end. > >Would any of the lawyers on the list be willing to comment on whether or >not it's possible or practical to tie a CA into the notary system? Does >anyone have any thoughts as to how difficult/risky spoofing my CA is >compared to spoofing Netscape or Verisign? There is indeed a large body of legal ramifications in this area. The best way to learn about it is to become a CA and do it. Risk taking is part of being in the CA business, however you operate it, even for free. > >I could put up a server and I think I know a laywer who would help me set >up a non-profit organiation on a shoestring, but I don't want to do it if >the plan is impractical. Running as a not-for-profit may not prevent general liability. You can give the service away for free and will still be liable for the mis-representations you or your agents make. There are DARPA reports written about the issue (though these do not usually constitute advice.) > >Morevover, although I don't think it's reasonable to expect Netscape to >agree to include a non-existent CA in their browsers sight unseen, at the >same time it doesn't seem smart to sink money into setting up the CA >without some indication from Netscape that they're willing to give the >idea good faith consideration. Navigator betas seem to already facilitate users configuring their own trust points in a manner rather similar to adding a key to your personal PGP keyring. IBM browsers allow formal configuration of trust points. CAs as a business and economic growth area are just happening. We have two declared companies; Verisign and GTE. I personally expect another 10-20 to declare soon. The large (phone company) networks seem to be where the current action is, followed by the large accounting firms. As a small software company, I personally back the other similarly small software companies making and selling organizational CA systems to help people manage their own community of interest as they see fit.

1 0

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