December 2003 - cypherpunks-legacy

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: 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

(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

RC2 source code
by Anonymous User 17 Dec '03

17 Dec '03

Reposted from sci.crypt: /**********************************************************************\ * 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. * \**********************************************************************/ #include <string.h> #include <assert.h> /**********************************************************************\ * Expand a variable-length user key (between 1 and 128 bytes) to a * * 64-short working rc2 key, of at most "bits" effective key bits. * * The effective key bits parameter looks like an export control hack. * * For normal use, it should always be set to 1024. For convenience, * * zero is accepted as an alias for 1024. * \**********************************************************************/ void rc2_keyschedule( unsigned short xkey[64], const unsigned char *key, unsigned len, unsigned bits ) { unsigned char x; unsigned i; /* 256-entry permutation table, probably derived somehow from pi */ static const unsigned char permute[256] = { 217,120,249,196, 25,221,181,237, 40,233,253,121, 74,160,216,157, 198,126, 55,131, 43,118, 83,142, 98, 76,100,136, 68,139,251,162, 23,154, 89,245,135,179, 79, 19, 97, 69,109,141, 9,129,125, 50, 189,143, 64,235,134,183,123, 11,240,149, 33, 34, 92,107, 78,130, 84,214,101,147,206, 96,178, 28,115, 86,192, 20,167,140,241,220, 18,117,202, 31, 59,190,228,209, 66, 61,212, 48,163, 60,182, 38, 111,191, 14,218, 70,105, 7, 87, 39,242, 29,155,188,148, 67, 3, 248, 17,199,246,144,239, 62,231, 6,195,213, 47,200,102, 30,215, 8,232,234,222,128, 82,238,247,132,170,114,172, 53, 77,106, 42, 150, 26,210,113, 90, 21, 73,116, 75,159,208, 94, 4, 24,164,236, 194,224, 65,110, 15, 81,203,204, 36,145,175, 80,161,244,112, 57, 153,124, 58,133, 35,184,180,122,252, 2, 54, 91, 37, 85,151, 49, 45, 93,250,152,227,138,146,174, 5,223, 41, 16,103,108,186,201, 211, 0,230,207,225,158,168, 44, 99, 22, 1, 63, 88,226,137,169, 13, 56, 52, 27,171, 51,255,176,187, 72, 12, 95,185,177,205, 46, 197,243,219, 71,229,165,156,119, 10,166, 32,104,254,127,193,173 }; assert(len > 0 && len <= 128); assert(bits <= 1024); if (!bits) bits = 1024; memcpy(xkey, key, len); /* Phase 1: Expand input key to 128 bytes */ if (len < 128) { i = 0; x = ((unsigned char *)xkey)[len-1]; do { x = permute[(x + ((unsigned char *)xkey)[i++]) & 255]; ((unsigned char *)xkey)[len++] = x; } while (len < 128); } /* Phase 2 - reduce effective key size to "bits" */ len = (bits+7) >> 3; i = 128-len; x = permute[((unsigned char *)xkey)[i] & (255 >> (7 & -bits))]; ((unsigned char *)xkey)[i] = x; while (i--) { x = permute[ x ^ ((unsigned char *)xkey)[i+len] ]; ((unsigned char *)xkey)[i] = x; } /* Phase 3 - copy to xkey in little-endian order */ i = 63; do { xkey[i] = ((unsigned char *)xkey)[2*i] + (((unsigned char *)xkey)[2*i+1] << 8); } while (i--); } /**********************************************************************\ * Encrypt an 8-byte block of plaintext using the given key. * \**********************************************************************/ void rc2_encrypt( const unsigned short xkey[64], const unsigned char *plain, unsigned char *cipher ) { unsigned x76, x54, x32, x10, i; x76 = (plain[7] << 8) + plain[6]; x54 = (plain[5] << 8) + plain[4]; x32 = (plain[3] << 8) + plain[2]; x10 = (plain[1] << 8) + plain[0]; for (i = 0; i < 16; i++) { x10 += (x32 & ~x76) + (x54 & x76) + xkey[4*i+0]; x10 = (x10 << 1) + (x10 >> 15 & 1); x32 += (x54 & ~x10) + (x76 & x10) + xkey[4*i+1]; x32 = (x32 << 2) + (x32 >> 14 & 3); x54 += (x76 & ~x32) + (x10 & x32) + xkey[4*i+2]; x54 = (x54 << 3) + (x54 >> 13 & 7); x76 += (x10 & ~x54) + (x32 & x54) + xkey[4*i+3]; x76 = (x76 << 5) + (x76 >> 11 & 31); if (i == 4 || i == 10) { x10 += xkey[x76 & 63]; x32 += xkey[x10 & 63]; x54 += xkey[x32 & 63]; x76 += xkey[x54 & 63]; } } cipher[0] = (unsigned char)x10; cipher[1] = (unsigned char)(x10 >> 8); cipher[2] = (unsigned char)x32; cipher[3] = (unsigned char)(x32 >> 8); cipher[4] = (unsigned char)x54; cipher[5] = (unsigned char)(x54 >> 8); cipher[6] = (unsigned char)x76; cipher[7] = (unsigned char)(x76 >> 8); } /**********************************************************************\ * Decrypt an 8-byte block of ciphertext using the given key. * \**********************************************************************/ void rc2_decrypt( const unsigned short xkey[64], unsigned char *plain, const unsigned char *cipher ) { unsigned x76, x54, x32, x10, i; x76 = (cipher[7] << 8) + cipher[6]; x54 = (cipher[5] << 8) + cipher[4]; x32 = (cipher[3] << 8) + cipher[2]; x10 = (cipher[1] << 8) + cipher[0]; i = 15; do { x76 &= 65535; x76 = (x76 << 11) + (x76 >> 5); x76 -= (x10 & ~x54) + (x32 & x54) + xkey[4*i+3]; x54 &= 65535; x54 = (x54 << 13) + (x54 >> 3); x54 -= (x76 & ~x32) + (x10 & x32) + xkey[4*i+2]; x32 &= 65535; x32 = (x32 << 14) + (x32 >> 2); x32 -= (x54 & ~x10) + (x76 & x10) + xkey[4*i+1]; x10 &= 65535; x10 = (x10 << 15) + (x10 >> 1); x10 -= (x32 & ~x76) + (x54 & x76) + xkey[4*i+0]; if (i == 5 || i == 11) { x76 -= xkey[x54 & 63]; x54 -= xkey[x32 & 63]; x32 -= xkey[x10 & 63]; x10 -= xkey[x76 & 63]; } } while (i--); plain[0] = (unsigned char)x10; plain[1] = (unsigned char)(x10 >> 8); plain[2] = (unsigned char)x32; plain[3] = (unsigned char)(x32 >> 8); plain[4] = (unsigned char)x54; plain[5] = (unsigned char)(x54 >> 8); plain[6] = (unsigned char)x76; plain[7] = (unsigned char)(x76 >> 8); }

3 2

Revisitting Blum-Macali "digital signatures"
by Paul E. Campbell 17 Dec '03

17 Dec '03

There was some discussion on Usenet a while back about doing "digital signatures" with the Blum-Macali public key method. Briefly, Blum-Macali relies on the BBS generator to generate a "one-time pad". And the pad can be reversed by taking repeated square roots on the random number seed (assuming you know the factorization) to get back to the starting seed. So, the author suggested that one calculate a digest of the message, call it D. Then the author suggested that one calculate D^(1/2), as per the Blum-Micali method. Then he goes on to do the signature check by checking whether or not D^2 == X^4 where X is the "signature". I understand that there is some sign ambiguity involved in calculating square roots mod B where B is a Blum integer (that causes 4 possible roots). And that's the source of ambiguity problems in Rabin digital signatures, but if the Blum-Micali public key method works, then this sign ambiguity shouldn't exist (because they define a SPECIFIC root to use), and the method can be simplified to simply calculating D^(1/2) and the check is simply D==X^2. What am I missing here?

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