December 2003 - cypherpunks-legacy

Re: FV's Borenstein discovers keystroke capture programs! (pictures at 11!)
by Rich Salz 17 Dec '03

17 Dec '03

>The key is large-scale automated attacks, not one-time interceptions. Without proving you can deploy it's bullshit.

1 0

Re: [NOISE] Re: The Big Lie
by Robert A. Rosenberg 17 Dec '03

17 Dec '03

At 15:54 1/28/96, John F. Fricker wrote: >Besides in this day and age where Isreal is a nuclear arsenal run by nutty >rightwing warlords who in their right mind would dare belittle their >tragedies. When the world community has a double standard when it comes to treating Isreal's actions differently from any other country, those "warlords" might be justified in their actions. Can you name any other country that was a non-participant in a war, was attacked by one side, and was told by the other side that they could neither join that side nor retaliate for the attacks (I'm talking about Operation Desert Storm and the Scuds aimed at Isreal). Any other country would have been allowed to participate or allowed to declare war on the attacker (and send a few missiles over as an incentive to stop attacking a neutral party to the war). The US (and the others Participants) were scared shitless of allowing Isreal into the fight since, if let it, the war would have been over real fast and Sadam H. would have been pushing up daisies (The Isrealis have a habit of being able to take care of themselves with minimal "collateral damage" when their hands are not tied by the actions of other Governments telling them that they are not allowed to do what any other Government is allowed to do as a matter of normal policy when faced with aggression).

3 2

Vladimir: put up or shut up
by Raph Levien 17 Dec '03

17 Dec '03

Most of the recent cypherpunks traffic from Vladimir has been a reiteration of the position that discussing ITAR is bad because it discourages cypherpunks from releasing good crypto software. Well, here's one cypherpunks who recently released some software, and futhermore did so making significant (some might say extreme) concessions to the ITAR rules. I made the software available only on an export-restricted Web server, and asked explicitly several times for it not to be exported. If my timezone math works out right, it took about half an hour for it to be available on utopia. The ITAR did _nothing_ to stop, or even slow down, the reease of my software. Why is it, then, that we still don't have usable strong crypto tools? I'd say the reason is complex, much more so than could be explained by a simple conspiracy theory or even too much discussion of ITAR. The main reason is that it is very damned hard to write good crypto-enabled applications. Trust me, I know. I have done the best I could with the software I released, but I'm still quite frustrated with its limitations, especially with respect to nontechnical users. Ultimately, to create really good crypto-enabled applications, it's going to take money. And there's where ITAR is most effective. If the powers that be disapprove of your software, then there goes your foreign market. There go your government sales. There go those "strategic alliances" with the other companies in the market, because the pressure can be applied transitively too. ITAR is actually only a small part of the process. Still, free software has a lot of vitality left in it. It's still strong at blazing new trails in software design. Where it's weak (and this is what really counts now), is being usable, easy to learn, and easy to install. I think if we explicitly work towards these goals, there's hope for great free crypto-enabled applications. Hell, PGP came pretty close, and it's saddled with all kinds of lousy design decisions. But back to Vladimir: instead of whining at us about how our fear of the law is hurting the acievement of our goals, why don't _you_ write that killer crypto-app and distribute it to the world? Who's stopping you? Raph

3 2

Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 9:29 PM 01/29/96, zinc wrote: [...] >the point is not that this can be done, the point is that users need >tools that would check for programs like this running on their >system. is fv making a 'fix' available? i would imagine a 'fix' >would be a program that would look for tsr type programs (or inits on >a mac) that do this sort of thing. At first I was going to say there was no way to do this--a program can't be written to look at an arbitrary program as intput and determine if it does a certain semantic action (steals your key strokes). And I think this is true. However, on the MacOS at least, I believe that a key-capturing program would have probably have to patch a particular point (or one of a set of particular points) in the OS, and a program could probbably look at the OS in RAM (or wherever patches happen; in RAM I think) and make sure it hasn't been patched--it's the way MacOS 7.5.X looks straight out of the shrinkwrap, nothings been done to it. Or report that, indeed, that portion of the OS has been patched, and some program might be logging your keys. [Of course, some legitimate programs might patch these portions of the OS too--so you'd have to be careful not to have a hacked version of those legitimate programs that also captured your keys. zinc's next point is relevant here, of course.] Can anyone tell me for sure if this would indeed be feasible? >this is the sort of thing that crypto can help with. there should be >a site that PGP signs the programs available from their site. these >signed programs will have been testing on the appropriate system and >verified to be free of small malicious programs such as the one you >describe. alternatively, the author themselves could PGP sign the app >(this is already done) and this would be what users should d/l. True. But, remember, you've still got to trust the _author_ of the program. Commercial programs generally dont' have source available, so I'm basically trusting Steve Dorner not to have Eudora send a copy of all my messages to the NSA. Even if the sources were available, most people aren't going to want to (or be capable of) going through the source, so they're trusting other third parties who have said "yep, I looked at the source, and it's okay." And, while there are plenty of third party types to look at a program like PGP (although, actually, I can't identify any reliable third party crypto type, not on the PGP developement team, who I know has looked at the PGP source and pronounced it okay. Doesn't mean it hasn't happened, but it means realistically, users _don't_ rely on third party guarantees of security in the source. Or at least I don't, but how many of you out there know a reliable third party source that has given a seal of approval to PGP, and specifically rely on that knowledge to give you confidence in using PGP?)... umm, while there are plenty of third party types to look at PGP, there are surely millions of lines of commercial software produced every year, and I'm not sure where all these reliable third party types to look at the code are going to come from. In theory, having source available is good. In practice, you still end up trusting the designer not to do anything bad to you.

1 0

your bogus post
by Paul Graham 17 Dec '03

17 Dec '03

We run an online mall. We had been planning eventually to offer the store owners the option of taking fv payment as well as credit card numbers. After reading your recent post to cypherpunks, which I would say is the most bogus post ever made on this bogus subject, we are determined *not* to use fv payment systems if we can possibly avoid it. That post was news to no one. The kind of attack you "discovered" has been known about for years, and is just not a serious threat. Your post was nothing but a calculated attempt to frighten end users, and get publicity for fv. A company capable of doing such irresponsible things is not one that we would trust with users' money. -- pg

3 2

Re: Security First Network Bank, FSB. The World's 1st Internet
by David Neal 17 Dec '03

17 Dec '03

> Date: Thu, 25 Jan 1996 17:50:16 -0500 > To: cypherpunks(a)toad.com > From: "Joseph M. Reagle Jr." <reagle(a)rpcp.mit.edu> > Subject: Security First Network Bank, FSB. The World's 1st Internet Bank > Just got something in the post today asking for me to set up an account with > them... > > - Daily reconciled bank statement and checkbook register; All transactions are > logged for you. - No min balance - 20 free electronic bill payments per > month... - ATM at Honor and Cirus.. - 200 free paper checks... - plenty of > pre-stamped deposit envolopes - FDIC insured accounts (in case anyone ever > steals my password..) - Wired Funds.. > Mis-features - Uses Public key crypto but web pages do not mention PGP, says keys may come in mail on floppy; how to fingerprint key? - Online only based system Drawbacks include system downtime means being unable to access your 'checkbook' No extraction features for those of us who use true double entry accounting systems, much less Quicken or even spreadsheets. - Bill paying system Four day lead on bills to be paid (can you say float?) Laser-printed statement sent to payee for 'verfication' will be subject to payees security restrictions which may consist of tossing it unshredded into the trash. - No chaum-like digital money provisions. Although it is a step in the right direction, I won't be happy until the bank accepts e-mail directives for generating chaumian cash or instant EFT payments via messages encrypted against PGP keys. Lets face it FINCEN already knows all about your income sources if they are at all bank based (i.e. excluding barter and cash), but at least I can have my check EFT'd, encrypt a PGP transaction to send all my money to Seychelles, and pay bills from that Offshore bank that really does respect my privacy. This would at least make discerning that my foley's bill is $120 a month more difficult since FINCEN would now have to have cooperation from the payee.

1 0

Credit cards: No keystrokes, no capture.
by sasha1＠netcom.com 17 Dec '03

17 Dec '03

What if I offer my customers a little GUI interface where they would click numeric buttons instead of typing the numbers? If the card number input screen changes window dimensions as well as size and positioning of the buttons, capturing mouse movements won't give you much either. Or randomly generate a set of digit buttons and let the user drag them into a 16-digit bar. Am I missing something here? ----------------------------------------------------------- | Alexander Chislenko | sasha1(a)netcom.com | Cambridge, MA | | Home page: http://www.lucifer.com/~sasha/home.html | -----------------------------------------------------------

1 0

Re: Your "urgent" alert
by John Schofield 17 Dec '03

17 Dec '03

John Schofield said: >> I will never use First Virtual. You should be ashamed of yourself. Nathaniel Borenstein said: >Why? For pointing out a devastating potential attack that the bankers >bearing the risk were unaware of? It would have been grossly >irresponsible to keep it secret. You are fear-mongering. You point out the details of an attack that was *NEVER* secret. It is transparently an attempt to build First Virtual's market share. This "new" technique will undoubtedly steal SOME credit-card numbers, but it can be dealt with the same way people *NOW* deal with trojan horses and viruses. It involves no new ideas, no new technologies, and no new problems. Again, you're trying to undermine your competetors and build market share for yourself by misleading novices. The same people who you claim are too clueless to understand "cut and paste." You should be ashamed of yourself. Go steal candy from babies. John ______________________________________________________________________________ John Schofield -- If all else fails, try contacting me at ac086(a)lafn.org. PGP Public Key available by e-mailing PGPKEY(a)sprawl.ktb.net.

1 0

Re: Lotus Notes
by Charlie_Kaufman/Iris.IRIS＠iris.com 17 Dec '03

17 Dec '03

My previous posting seems to have been truncated (at least by the time it got back to me - please forgive me if it's a duplicate). The following is the attachment that should have been there... --Charlie Kaufman (charlie_kaufman(a)iris.com) PGP fingerprint: 29 6F 4B E2 56 FF 36 2F AB 49 DF DF B9 4C BE E1 p.s. re: the fact that it's 64 bits rather than 128. That was the limit on key size of the crypto software we licensed from a third party. That crypto software also limited us to 760 bit RSA keys. We intend to push those numbers up in the future in the domestic version, but have some real world issues around backwards compatibility with our installed base. I don't know whether we will be allowed to go over 64 bits in the exportable version; since we couldn't do it anyway, there was no point in pushing this round. Lotus Backgrounder Differential Workfactor Cryptography Abstract: This document describes the technical approach behind the exportable strong cryptography included in Lotus Notes Release 4 (International Edition). Current U.S. export regulations generally prohibit the export of cryptographic software that uses keys larger than 40 bits, but advances in processor technology make 40 bit keys breakable by exhaustive search practical for a growing collection of potential attackers. In a novel scheme we sometimes refer to as 64/40, we provide the cryptographic strength of 64 bit keys against most attackers while to comply with export regulations we make the workfactor for breaking the system equivalent to only 40 bits for the U.S. government. We do that by encrypting 24 of the 64 bits under a public RSA key provided by the U.S. government and binding the encrypted partial key to the encrypted data. Background: As we,re all painfully aware, the U.S. government continues to maintain that cryptography should be classified and controlled as a munition of war. There is a long historical basis for this - some of cryptography,s finest hours have been during the wars of the past. And while some would argue that export controls are a sham because many foreign governments impose no such restrictions and we participate in an international marketplace, by one very important measure export controls have been a success: no mass-deployed worldwide cryptography has emerged and most general communications is still in cleartext. But while the government has been successfully defending its ability to spy, trouble has been brewing. Criminals don,t recognise borders -- there,s only one wild and wooly network. Crackers are able to attack targets halfway around the world with no fear of prosecution. Smart people in Eastern Europe crack financial systems in New York. Everywhere you look, bright clever people are breaking into communication systems, industrial control systems, transportation systems, health care systems, anything and everything that,s controlled by networked computers. This is not a theoretical problem, or just a problem with clever people stealing money from banks; it,s a clear and present danger that,s a direct result of the fact that we,ve moved into the information age without adequately securing our global information systems. Lotus Notes has been a pioneer in providing transparent strong RSA-based cryptography in its product offering. It went to great lengths to provide the strongest protection legally permissable. There is an International Edition that complies with export regulations and a domestic edition that does not (called the North American Edition because it is legally available in the U.S. and Canada). In the International Edition, users use two RSA key pairs -- one used to protect data integrity and authentication and another (shorter) one to protect data confidentiality because only data confidentiality key sizes are regulated by export controls. Full interoperability between the North American and International Editions is achieved by having the two ends negotiate down to the largest key size that both ends support. This design came at no small cost, but it was the only way we could deliver the best security possible to each of our customers given the existing regulatory climate. Differential Workfactor Cryptography is another innovation in the direction of giving our customers the best security possible. At the same time, we continue to oppose the regulations that make the complexity necessary. How it works: The idea behind Differential Workfactor Cryptography is simple; whenever a bulk data key is created, a 64 bit random number is chosen. If the use of that key is one involving data confidentiality and the International Edition of Notes, 24 of the bits are encrypted under a public RSA key that was provided to us by the U.S. government and the result - called a Workfactor Reduction Field - is bound into the encrypted data. There is no Workfactor Reduction Field in data used only by the North American Edition of Notes, and there is none for keys that are not used for data confidentiality (e.g. those used for authentication). If an attacker wanted to break into a Notes system based on information obtained by eavesdropping, he would have to exhaustively search a 64 bit key space. Even the U.S. government would face this workfactor because there is no Workfactor Reduction Field in keys used for authentication. An attacker who wanted to read an encrypted document that was either read from a server or eavesdropped from the wire would face a 64 bit workfactor. But if the U.S. government needed to decrypt such a document, it could obtain 24 of the bits using its private key and the Workfactor Reduction Field and then exhaustively search a 40 bit key space. Tamper resistance: You might wonder what,s to prevent someone from deleting the Workfactor Reduction Field from a document or the setup protocol of a network connection. This is similar to the problem faced in the Clipper design to assure that the LEAF field was not removed from a conversation. In a software-only implementation, it is not possible to prevent tampering entirely. The best a software implementation can do in terms of tamper resistance is to make it impossible to remove the Workfactor Reduction Field without modifying both the source of the data and the destination. This can be done by having the destination check for the presence of the Workfactor Reduction Field and refuse to decrypt the data if it is not there or not correct. The destination can,t decrypt the Workfactor Reduction Field to check it, but knowing the bulk data key and the government public key, it can regenerate the WRF and compare the result with the supplied value. RSA has the convenient property that the same value encrypted twice produces the same result. It would be somewhat more complex (but still possible) to duplicate this functionality with other public key algorithms. [Note: for this to work, the random pad that was used in creating the WRF must be delivered to the recipient of the message. For it to be secure, it must be delivered encrypted since a clever attacker who knew the pad could do 2^24 trial encryptions to get 24 bits of the key and then do 2^40 trial decryptions to recover the rest.]

1 0

Re: FV's Borenstein discovers keystroke capture programs!
by Jeremy Mineweaser 17 Dec '03

17 Dec '03

At 09:53 AM 1/30/96 -0500, nsb(a)nsb.fv.com wrote: >> ... likely, you store the card numbers on a computer. And no doubt, >> someone or something enters those numbers into a database. >> You have just violated your own cardinal rule. > >Nope, afraid not. We keep the credit card numbers on a non-Internet >computer. Let me restate your cardinal rule, direct from your "alert": >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. How about we here it again, just because it's so well thought out: >NEVER TYPE YOUR CREDIT CARD NUMBER INTO A COMPUTER. Now, the fact that your customer database of credit card numbers is not directly available via the Internet does not make it cease to be a computer. Regardless of its networkability, it is still a computer. Do you suggest, then, that computers cannot exist without networks? >As to how the credit card numbers are entered: they are entered at >account setup time via a telephone call. And just *where* do they get entered? Into a computer. And *how* are they entered? Via a keyboard. What was that? You guys enter credit card numbers via the keyboard? But YOU CAN'T DO THAT! IT'S NOT SAFE! If I can't trust myself to keep my credit card number secure, why should I trust your minimum-wage data entry employees? >Believe me, we've thought a LOT about this. I believe that you thought more about writing your glorified keyboard sniffer than you did deciding how to announce your discovery to the public. --- Jeremy Mineweaser | GCS/E d->-- s:- a--- C++(+++)$ ULC++(++++)>$ P+>++$ j.mineweaser(a)ieee.org | L+>++ E-(---) W++ N+ !o-- K+>++ w+(++++) O- M-- | V-(--) PS+(--) PE++ Y++>$ PGP++>+++$ t+() 5 X+ R+() *ai*vr*vx*crypto* | tv(+) b++>+++ DI+(++) D+ G++ e>+++ h-() r-@ !y-

1 0