December 2003 - cypherpunks-legacy

Re: Wild Idea for RNG
by Herb Sutter 17 Dec '03

17 Dec '03

Warning: I'm no expert, my response is just a semi-informed opinion (emphasis on "semi-"). At 02:19 1995.09.27 -0400, Ray Cromwell wrote: >So, why not construct a turing machine with a large state transition >table, input a random program, and get a 1 or 0 bit depending on ^^^^^^ >whether it halts in X number of cycles. You could even get more >than 1 bit out of it by measuring how many cycles it takes to halt >(if it halts before X) and use the LSB. Is it as secure as >the halting problem? (intractable to devise an algorithm used >to predict a bit with more than 50% confidence if you knew the >state table?) Your randomness will depend on the prior randomness of your original input... and if you already have that, the TM won't give you any additional randomness (rather, this approach will just take all the randomness you give it and reduce it to 1 bit of randomness, losing all the rest). On the other hand, if the 'random' program is not already truly random, then you may well have patterns in the bits generated by the halting observation. For instance, if you use a known PRNG to get your "random" programs, then given the same seed you will end up with the same programs (and therefore the same resulting 'random' bits from the TM halting output)... which, in other words, gains you nothing AFAICS over simply using the PRNG's output directly, except of course that it exercises your CPU. :-) The attacker still only needs to figure out the seed. >Grab a picture of the current bitmap on your screen. Run it through >a good compression algorithm (say, an arithmetic/Q-coder or >one of the LZ schemes). Grab the LSB of every 4th byte or so. >If the screen is size 1024*768*8, that's 786432 bytes. Let's assume >a 10 to 1 compression ratio = 78643 bytes. Let's assume you take >1 bit from every 10 byte, that's 983 bits of entropy. > >The screen will often contain data like: > >random placement of icons and windows Not on my machine (or most others, I'd wager)! I thought about this, and whenever I'm running Netscape (for instance) my screen is probably identical over 50% of the time because I tend to have the same things open when I run a given program. Even in the general case, consider that most people have a preferred desktop layout (in Windows, they have ProgMan sitting in one place on the screen with usually the same groups visible/open)... not only will that piece of the screen bitmap not give you any randomness from one run to the next, but unless you go looking for "things that haven't changed since last time" your program won't even know what's reducing your randomness. >current time Better, but be careful how you use it; that's what Netscape thought too. :-) >current applications running, and the data in their windows > > >If Netscape was running for instance, part of the random bits >would come from the bitmap representation of the data in Netscape's >window which would depend on the URL being displayed. This sounds a bit better... except, of course, that when you initiate a secure session in Netscape with a specific party/server, your screen has a very good chance of looking the same each time you connect with that entity because it is the same URL. :-) Would someone who's more informed please correct my analysis? Thanks in advance, Herb ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Herb Sutter 2228 Urwin, Suite 102 voice (416) 618-0184 Connected Object Solutions Oakville ON Canada L6L 2T2 fax (905) 847-6019

1 0

NO weak links in DigiCash system!!!
by Marcel van der Peijl 17 Dec '03

17 Dec '03

> I have a couple of problems/complaints with your ecash project. > When I was sent my Acct ID and Passwd they were sent to me plain text > instead of being PGP-encrypted first. This means that some malicious > hacker could have intercepted the e-mail message and stolen the > free cyber-bucks you were so generous as to give me. Second, on the > WWW-page where one downloads the software it does not seem to do a secure > connection between my browser and your server (on netscape there is > a small key in the lower-left hand corner that is supposed to show when > one is securely connected to a secure server). So someone could sniff my > password from the transaction when I GET the software. Also When I'm > buying/selling things it would be smart for all parties involved to > be using PGP, and I think you should stress this point more in your page. > Otherwise this is another vulnerable point in your system IMHO. Let's get this straight before spreading more of these vicious rumours that can easily get misinterpreted. DigiCash is an R&D company developing ecash. We license out our technology to banks. We are running the trial, but only have limited resources to do so. This may result in long waiting time for accounts or no answer on a tech support mail. (We are of course trying to prevent this). In a real-money system, the password can of course not be sent out in plain mail. Either it has to be transferred out-of-band (phone, paper) or PGP'd. But that would require at least ten people answering the phones, sending snailmail, etc. We do not have the resources to do so, so we send out the password plain. A malicious hacker may snatch the password and open the account for you and steal your cb$100. This, however, is not related to the security of the transactions once you open the account! The password is only for starting up the account. And of course downloading on a secure server is not relevant. The software is the same for everyone! It is just not put out for public downloading because it would mean a hundred times more people asking for tech support. It would be more secure if we used different passwords for downloading and for opening the accounts but again, that would give a LOT more problems. PGP does not add any security in the payment system. Ecash is already secure. Feel free to ask us the questions before publicly posting. It will prevent misunderstandings and libel lawsuits. // Marcel van der Peijl, DigiCash bv, http://www.digicash.com/~bigmac/ // "If you had to tell the Whole Truth, you'd never shut up."

2 2

FT on NsCPunxsters
by John Young 17 Dec '03

17 Dec '03

Financial Times, Sept 27, 1995 Cracks in the code Peter Martin calls for an easing of US restrictions on the export of encryption technology Encryption used to be a subject of interest only to spies and mathematicians. But the central role that the electronic transmission of information is playing in commerce and society make it now a technology of enormous practical relevance. Two recent stories out of many exemplify this trend. Citibank lost $400,000, it is alleged, to a Russian hacker who managed to crack its clients' passwords. The solution to this security problem: a new generation of encrypted passwords that are much harder to crack. And Netscape Navigator, the leading "browser" program for the Internet's fast-growing World Wide Web, has been shown to have flaws in its encryption routine. In theory at least, these make it possible for outsiders to read encrypted data sent over the net -- such as credit card numbers. Netscape acknowledges the problems and says it will have fixes available by today. Is this crucial technology vulnerable to determined attack by hackers and fraudsters? Before considering the question, remember that the introduction of any new technology highlights risks uncomplainingly borne for years. The safety precautions demanded of the Channel tunnel are one example, as compared with those required of traditional trains or ferries. Similarly, it is argued, people have been unhesitatingly using analogue mobile phones, reading credit card details over the telephone, and sending off faxes into the ether without any of the panic that now surrounds the issue of Internet security. The comparison is an instructive one, but not entirely fair. What worries Internet users is not so much that a determined enemy might target them for eavesdropping, or even that chance might put their credit card details in the hands of a dishonest person. Instead, they worry about the Internet's unstructured nature under which messages are passed from computer to computer across the world until they reach their final destination. In principle, this would allow a criminal to leave a "sniffer" program lurking, electronically, at one of the nodes, recognising credit card numbers as they passed by, and scooping them up for subsequent exploitation. People also fear an attack on the computers of merchants selling goods over the Internet -- each containing thousands of credit card numbers. The fear is thus not one of random theft but of systematic brigandage. Encryption is all that stops such fears paralysing electronic commerce before it has properly begun. It is therefore in the general public interest that effective encryption be widely available. The Netscape problem illustrates how easy it is for the inherent mathematical strengths of a modern encryption scheme to be overcome by an oversight in its supporting plumbing. One of the faults in Netscape's encryption, for example, stems from too predictable a method of generating the random numbers needed to make the scheme work. It also illustrates how, once a code-breaker's task is simplified by such a weakness, today's powerful networks of cheap computers make it quick to crack even the most sophisticated encryption schemes. The narrower the range of numbers through which the cracker's computers must sift in order to find a meaningful answer, the greater the probability of breaking the code within a useful amount of time. All the more reason, then, for non-Americans to view with dismay a US policy which restricts the international distribution of the most powerful forms of encryption. For national security reasons, the US insists that the version of Netscape sold outside North America must contain a weaker form of encryption than that available to Americans and Canadians. The international version is restricted to a 40-digit "key", while the North American version uses 128 digits. The longer the key, the greater the time and computing power required for the code to be cracked. In principle, given enough computing power, even a message encoded by a very long key could be cracked in time. In practice, however, the task of cracking many millions of messages to find one that is of interest makes messages secure as long as the key has enough digits. Amateur code-crackers claim to have broken the 40-digit version of the Netscape encryption scheme. Their claim is hard to verify. But there is no doubt of the weakness in the random-number generation procedure; Netscape has verified it. This fault is common to both North American and export versions of the program, so it does not result from the US government restrictions on key length. The occasion reminds us, however, that effective encryption is essential to the growth of electronic commerce. And it teaches us that simplifying the code-breaker's task -- by error in Netscape's case, by deliberate diktat in the case of the government restriction is an easy way to make transmissions vulnerable. There was never much justification for the US determination to weaken exported encryption products. There is less now. [End] --------- NYT, Sept 27, 1995 Russians Arrest 6 In Computer Thefts St. Petersburg, Russia, Sept 26 (AP) -- Russian police officers have arrested six more people in a $10 million computer theft from Citibank here, but the masterminds are said to remain at large. An officer in the organized crime division was quoted by the Itar-Tass news agency as saying that six people had been arrested in St. Petersburg on swindling charges stemming from the case involving Citibank, the chief unit of Citicorp. Weapons and tax-evaslon charges may also be filed. The police confiscated two computers and a number of computer diskettes, plus weapons and cash from the suspects. Bank and law-enforcement officials say a gang of thieves in St. Petersburg broke into Citlbank's electronic cash-management system scores ot times and transferred money into their own accounts. Several people have been arrested abroad and face charges in the United States, including Vladimir Levin, 28, reportedly the group's computer hacker. Citibank officials said they recovered all but $400,000 and upgraded the cash-management systems's electronic security after the theft. [End] --------- FT, Sept 21, 1995. Extradition in Citibank hacking case A British court yesterday approved the extradition to the US of Mr Vladimir Levin, the Russian science graduate accused of an attempted $10m (6.5m pounds) computer hacking fraud on Citibank. ... Mr Levin has been charged in the UK with offences under the Computer Misuse Act, forgery and false accounting. The US authorities are now drawing up similar charges to bring against him. Mr Levin is one of six people arrested over the alleged attempted fraud on Citibank. An FBI inquiry into the incident is continuing and it is believed that others are still being sought. When Mr Levin is returned to the US, he is likely to be closely questioned by the authorities, who are anxious to discover more of the technical details of the alleged attempted fraud. Mr Levin, who was arrested earlier this year travelling through Stansted airport in the UK, would appeal against the court's decision, his lawyers said. He has 14 days to lodge an appeal to the High Court in London. ... [End]

1 0

Hegel
by Bob Bruen, MIT Lab for Nuclear Science 17 Dec '03

17 Dec '03

James Caldwell wrote: >On 25 Sep 95 at 0:06, Hroller Anonymous Remailer wrote: >It's called the Hegelian Diclectic(sp?) first postulated by William >Hegel (an ass) in Germany approx the 1600's as a method for social change >when none could otherwise be achieved. Just for a reality check, Georg Wilhelm Hegel (1770-1831), was not an ass, but rather a brilliant philospher, even if you do like his views. I am guessing you are refering to his "dialectic", which was simply an observation of the way history worked: Thesis <---> Antithesis | Synthesis The synthesis then becomes the new thesis and history moves. It was not proposed as a method of social change, but rather a description of how history moves. It is always better to some of idea of what you are talking about before you make such rash, critical statements. Sorry for the noise to the list. Bob

1 0

Re: Security Update news release
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> > > > Here is the press release we put out this morning regarding the fix > >for RNG seed and stack overflow problems. > > Do the new versions use PGP's randseed.bin? If Netscape even only looks at > data used to keep PGP secure, Netscape will be banned from my computer > and every computer I am responsible for. -- For good. That doesn't quite make sense. Netscape reading randseed.bin can have no effect on the security of PGP. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

2 1

Using sound cards to accelerate RSA?
by Simon Spero 17 Dec '03

17 Dec '03

Somebody mentioned the possibility of using the a/d stage of a sound card as a source of random bits, and that brought a thought back to mind: given that a lot of sound cards are now shipping with DSP chips on board, has anyone written any code that uses the cards DSP to accelerate RSA processing? Maybe there's a mass market market for a crypto-blaster- an RNG, 3 or 6 DES chips, and a DSP. It would make for a killer linux based SHTTP server... Simon

1 0

Re: Status of Netscape Bug Exploit (suggestions needed)
by Rev. Mark Grant 17 Dec '03

17 Dec '03

Couldn't you either create the address in a register, and then do an indirect jump through the register, or push it onto the stack and do a ret ? You could do something like mov ecx, address + 01010101 sub ecx, 01010101 jmp [ecx] I'm not certain of the format for BSDI assembler, but I presume that's possible. You could modify the value you add and subtract to make sure there are no netscape-invalid bytes in the compiled code. Mark

1 0

[ PROPOSED NEW STANDARD ] "I-like-encrypted-mail" tag
by Travis Corcoran 17 Dec '03

17 Dec '03

Summary: This message tosses out an idea for conveying within an { email | usenet } message the datum "the author of this message prefers to receive PGP encrypted communications" in a standard machine-readable form. Motivation: In the most recent version of my <a href="http://www.openmarket.com/personal/tjic/emacs.html"> mail-secure.el package </a> I included a feature that allows users to maintain a list of correspondants who prefer to receive encrypted mail. This list is then used by the package at email-send-time to see if a piece of email should be encrypted. I and others on this list include tags along the lines of "PGP encrypted mail preferred" in our .sigs. It occured to me that this could be automated: (1) a standard "I-like-encrypted-mail" tag could be defined (2) cryptography-capable mail tools could scan incoming messages for this tag and add the originators of any message containing the tag to a list (3) cryptography-capable mail tools could then use this list when sending (as mail-secure.el currently does). Possible Implementations: A couple of different methods occur to me to implement step #1: (a) a new header could be defined and added to messages (as per section 3 of <a href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1505.html"> RFC 1505 </a> ), along the lines of X-Rcv-Security-Prefered: PGP-Encryption (b) a certain keyword or phrase could be defined that could be inserted in the .sig block of a message. Ex: -- foo(a)bar.com PGP-Encrypted-Mail-Preferred I am tempted to suggest something either compatible with or in the spirit of <a href="http://www.eit.com/creations/s-http/draft-ietf-wts-shttp-00.txt"> SHTTP </a> negotiation blocks, but restrain myself from doing so because this (a) seems needlessly baroque for the information being conveyed (b) falsely implies that a negotiation is taking place, when in fact a mere advisory is being issues. Security concerns: A temporary denial-of-service/annoyance attack could be mounted by an adversary who issues one forged message from individual A with the "PGP-encrypted-mail prefered tag" present, and then puts a fake key on a keyserver. Anyone who uses a tag-aware mail-reading package and sees this message would send future mail to individual A encrypted in a manner that didn't allow A to read it. Please mail or post any thoughts on this proposal. Thanks, TJIC

1 0

Re: [NOISE] Re: Easter Eggs
by william＠interval.net 17 Dec '03

17 Dec '03

alano(a)teleport.com <Alan Olsen> ]: > obNetscapeHack: There is a feature called a "cookie file" in > Netscape that is ripe for exploitation as a security leak. If you > are using a Netscape server (and you may not even need that), you > can feed all sorts of information into it without the user's > knowlege. I have heard of one page that overloads the cookie file > until the machine runs out of drive space. I am sure that there > are other exploitable holes there... Any takers? Umm. The spec says that there is a maximum cookie size and a maximum number of cookies that should be sent. I'll be the last to claim that Netscape created a 'standards-compliant' product, but they have at least recognized that these things aren't supposed to be infinitely large. rfb(a)lehman.com <Rick Busdiecker> ]: > Yikes! That sounds really bad. Do you have any more information on > this? For example, can the server write to anything other than > $HOME/.netscape-cookies? If I write protect that file, but it's still > owned by me, will Netscape still modify it? The server can't write anything. Cookies are returned as HTTP response headers, which will either be: A) Ignored by a cookie-ignorant browser, or, B) Processed by a cookie-aware browser. In either case, the cookie cache reading/writing is done by the browser. If the browser is running as 'you' then it can access files that 'you' own. If you write protect it against yourself, then its likely that your user-agent (Netscape) running as 'you' can't write to that file. Cheers! w. archibald =

1 0

Re: Hack Microsoft?
by James A. Donald 17 Dec '03

17 Dec '03

At 10:33 AM 9/26/95 EDT, Dan Bailey wrote: >>For fun ways to hack NT, check out http://www.somar.com/security.html. >> Some of these are really laughable. You can use NT's LogonUser API >>call to repeatedly guess passwords until you hit it, since NT offers >>no way to limit number of login attempts. At 12:10 PM 9/26/95 -0400, RJ Harvey wrote: > I don't believe that's correct; under User Manager, select >the Account option under the Policies menu item; it lets you >select whether to lock-out the account after a given number >of invalid logon attempts, and to set the number. The main >problem here is that by default, I don't believe the 'lock out' >option is enabled Similarly there is an awful lot of other stuff that is left wide open by default, most notably important parts of the registry, in particular \HKEY_LOCAL_MACHINE\SOFTWARE Permissions on this are usually set to give every use write access, so that every user can install software. None of the installation programs reset their registry key to exclude write access by anyone other than the administrator or the person installing the program, as a result any user can muck with the environment of any program installed by any other user. As a result any user can force feed most programs strings which the program would ordinarily assume are internally generated, and can therefore be trusted. A low privilege user can muck with the internals of a program installed by a high privilege user. This of course is a bug in the installation programs, rather than a bug in the operating system, but it is an almost universal bug. (But before you Unix folk gloat, consider how few Unix programs *have* installation programs, also that Unix has no registry security problem because it has no registry.) --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0