December 2003 - cypherpunks-legacy

Re: chaos cryptography
by tcmay＠got.net 17 Dec '03

17 Dec '03

>Hi all - saw this in New Scientist and thought you might be interested >(I guess it's more stenography than cryptography): ^^^^^^^^^^^ Yes, chaotic communication is preferred by secretaries around the world. They follow their dictates. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

Coercion-proof remailers (solved?)
by Mike Ingle 17 Dec '03

17 Dec '03

For a while I've been talking about the importance of a robust infrastructure for anonymity, including coercion-resistant remailers. Here is an approach that appears to eliminate the problem of after-the-fact coercion. Existing remailers chain messages by using a fixed public/secret key pair in each remailer. This leaves them open to after-the-fact compromise from the sender end. If you capture a message as the sender sends it, you can later get the key of the first remailer, and decrypt the first layer. You can then proceed on down the line to the recipient. This creates a motive for an attacker to coerce remailers, and it means the value of the remailers' keys continually increase as more messages are sent. Instead of using a fixed key, the sender can perform a Diffie-Hellman exchange with the recipient at each point in a message's passage. This eliminates the coercion problem, since there is no permanent key to steal, but allows a corrupt remailer to see where the message is going. If the first remailer is corrupt, the whole path is compromised. The next step is to make sure there is no first remailer. The sender S generates a message and header requesting mailing S to the recipient R. The sender splits it into two pieces using / \ a method that requires both pieces to recover any data. Then he 1 2 adds a header to each piece requesting remailing to remailer 3. \ / He sends one piece to remailer 1 and one piece to remailer 2. 3 The transmissions are protected by DH exchange and encryption. | Remailers 1 and 2 each send their pieces to remailer 3. These R transmissions are also protected by DH exchanges. Remailer 3 combines the two pieces, recovers the header requesting remailing to R, and sends the recovered message to R. This approach is secure against after-the-fact coercion or key theft, because there is no persistent key to recover. It is also secure against any one of the three remailers being corrupt. If 3 is corrupt, it sees both pieces as it combines them, and knows they came from 1 and 2, but does not know where 1 and 2 got them from. If 1 is corrupt, it knows that a message from S went to 3, but it has only half of the split message, so it can't find out where 3 sent it to. If any two of the three are corrupt, the path is exposed. It is possible to add more levels. This one uses seven remailers, /S\ and can survive any two being corrupt. Some questions I don't / | | \ know the answers to: What is the best possible arrangement of 1 2 3 4 remailers, so that the highest percentage of them have to be \ / \ / corrupt before the path is revealed? If any continuous line 5 6 from S to R is corrupt, the path is revealed. And if any two \ / remailers in a 'triangle' are corrupt, the whole triangle is 7 corrupt. For example, 1 and 2, 1 and 5, or 2 and 5. | Is there a better arrangement, reusing some remailers, that R allows the message to remain secure with a higher number of corrupt remailers in the path? Mike

2 1

Re: Fax encryption software
by James A. Donald 17 Dec '03

17 Dec '03

At 09:34 PM 9/26/95 -0700, Jonathan Blake wrote: > > I saw this article in alt.privacy. > > Anybody think the described encryption actually is worth > looking at. > > We are talking about a 72 bit engine that is more than > sufficiently strong for time sensitive general business purposes. Since David does not know the difference between CPU word width and an encryption algorithm, I think it is safe to ignore him. --------------------------------------------------------------------- | 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

Wild Idea for RNG
by Ray Cromwell 17 Dec '03

17 Dec '03

Ok, so I'm reading a message somewhere and I see a message about algorithmic information theory. Cryptography was recently on my mind and I thought of Chaitin's quote "arithmetic is random" 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?) Ok, so it's impractical. So how about this: 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 current time 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. -Ray

1 0

Hack Microsoft At Work Fax?
by Bill Stewart 17 Dec '03

17 Dec '03

I've been helping a client install Microsoft Windows for Workgroups, which comes with Microsoft At Work Fax. The fax software, in addition to doing normal stuff, lets you encrypt faxes with passwords or public-key encryption for sending to other people who use the same software. The manual has minimal technical information, so I don't know the algorithms it uses; it mostly talks about what GUI buttons to push. I was hoping the section on taking your software overseas would say something about Export Laws and International Arms Traffickin' (and creatin' a disturbance...) but all it said was how to set the international-direct-dialing phone codes so you can get your fax to go where you want. Because of that, I'm guessing it's something like RC4/40 and RSA-512 with some sort of user name as part of the public key field, but I'd like to know more, and I'm also guessing that they've got some sort of general export license permission from the Feds. The public-key system uses a public key file with "154 computer-generated characters", and recommends exchanging public keys by floppy disk. I don't know if that's 154*8 bits, or 154*6 or *4, or if there's a user-name string using up some of those characters; probably the latter since it's probably 512 bits because of export. I called the usually helpful Microsoft Technical Support phone number, and they were friendly and will try to get back to me, but this is way out of the scope of the kind of questions they're used to :-) And the stuff I could find from the Web page or ftp.microsoft.com on encryption had less than the manual, plus some stuff on password encryption, plus some stuff on their RAS remote network access stuff which apparently uses DES as well as standard PPP handshaking or Shiva handshaking. Does anybody have any more information? It'd be fun to hit up Microsoft for the next crack if it's weak enough; the fax stuff can also be sent by MSMail so there is eavesdropping potential. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

testab
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

testab

1 0

testab
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

testab

1 0

HP KEscrew
by John Young 17 Dec '03

17 Dec '03

The Wall Street Journal, Sept 27, 1995 Hewlett Lobbies for Its Encryption Plan That Would Satisfy Tough Export Rules By Don Clark Hewlett-Packard Co. is pushing an unusual plan to protect electronic transactions around the world without running afoul of U.S. export laws. The Palo Alto, Calif., computer maker said it has been lobbying government agencies for more than a year to gain support for its proposal, which uses a data-scrambling technology to protect transactions from tampering or theft of data. Strong encryption technologies ordinarily fall under tough export rules that limit technologies which could impede U.S. wire-tapping capabilities, a source of continuing friction between the government and high-technology companies. H-P, in a plan developed with the French company Gemplus SCA, wants to split the code-making technologies into two pieces that would be approved under different government standards. One device, which could fit in a standard computer, would contain a basic encryption capability that is designed to be broadly exported without the need to seek a separate export license for each foreign user. Would Help Industry That device, dubbed an encryption engine, would be useless without the addition of another tiny piece of hardware that contains a code-making formula set at a specific strength. The second device, called a policy card, would be separately reviewed by the U.S. State Department for each customer. Government agencies, including codebreakers at the National Security Agency, would still have a say over the strength of encryption exports. But customers could build commercial applications around the proposed encryption engine, knowing that it will work with any code-making formula that governments might adopt in the future. Now they run the risk that their work will become obsolete amid policy changes in Washington, D.C., and other countries. State Department officials weren't immediately available for comment. Stewart Baker, a former NSA general counsel who now practices law in Washington, D.C., termed the H-P plan a clever answer to the problem of shifting government policy. "There was a lot of skepticism when H-P first proposed it," said Lynn McNulty, a former encryption specialist at the National Institute of Standards and Technology. "But it looks to me that they are well on the way to the next step." H-P Confident of Approval Doug McGowan, an H-P manager involved with the project, said he expects to receive U.S. approval by next year to begin shipping the encryption engine freely to Western Europe and Canada. "We believe we will receive relaxed export controls," he said. H-P's plan fits some of the NSA's objectives. For one thing, its technology embeds encryption technology in microchips that can't easily be modified by computer hackers or terrorists. H-P's policy cards also could be adapted for a controversial Clinton administration proposal called key escrow, in which mathematical keys to break codes could be stored for later use by law enforcement or intelligence agencies, Mr. McGowan said. The plan complements a parallel H-P effort to develop a new generation of "smart" data cards to let consumers buy goods and services around the world electronically. Gemplus, a huge supplier of credit and debit cards in Europe, is supplying technology to that effort along with Informix Corp., a database software maker in Menlo Park, Calif. Jeff Hudson, an Informix vice president, said the partners' proposed cards could store money and a database worth of personal information, such as medical records. That approach could eliminate the need to connect to multiple companies or agencies to manage such information, since it would be stored on each card, the companies said. [End]

1 0

SSTarget
by John Young 17 Dec '03

17 Dec '03

The Wall Street Journal, Sept 27, 1995 Microsoft and Visa Expected to Unveil Internet Technology By a WSJ Staff Reporter New York -- Microsoft Corp. and Visa International are expected to disclose details today of their technology for protecting commerce on the lnternet. The software company and bank clearinghouse have been working since last November on a plan for protecting creditcard numbers and other financial data from crooks, a major obstacle to the widespread use of computer networks for buying goods and services. As the largest players in software and credit cards, Microsoft and Visa wield considerable clout among a crowd of companies vying to set electronic-security standards. Their proposed specifications, calied Secure Transaction Technology, or STT, is partly based on a data-encryption technology popularized by RSA Data Security Inc., a closely held company in Redwood City, Calif. Other key players in the Internet-security race include MasterCard International Inc., the other name in bank cards, and Netscape Communications Corp., a leader in Internet software that has suffered some highly publicized security lapses lately. MasterCard announced plans to collaborate with Visa on security technology in June, but isn't expected to take part in the latest Visa-Microsoft announcement. [End]

1 0

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

Re: Timothy C. May: Mini-mailbombs and Warning Letters
by Travis Corcoran 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Message-Signature-Date: Wed Sep 27 12:28:47 1995 > Date: Tue, 19 Sep 1995 10:57:32 -0700 > To: cypherpunks(a)toad.com > From: tcmay(a)got.net (Timothy C. May) > Subject: Mini-mailbombs and Warning Letters > > I've received a couple of "automatically generated" pieces of > e-amil which tell me that, in the generator's opinion, something is > wrong with my public key, or it could not be found at the keyserver > > As the saying goes, "Sigh." > > Being on a list with 700 subscribers, some of whom are running > increasingly sophisticated automatic checking agents, I foresee an > increase in these "warning letters" from their checking agents who > feel posts are not adequate in some way. As the author of the package in question, I would like to point out: (1) the email msg Tim refers to (hereafter refered to by me as "query-mail") was a request for information, not a warning (2) the query-mail did not refer to any inadequacy in the original posting. It explicitly refers to the fact that the original poster PGP signed a message, but did not make the public key to verify the message easilly available. (3) the query-mail was sent to an actual person only after several non-intrusive methods had failed. (4) checking right now, I find that the finger command does indeed fail to get a public key from Tim's address. (5) checking right now, I find that BAL's keyserver does indeed fail to give any key with the address "tcmay(a)got.net" (6) the query-mail is not a purely robotic spam: there is a human in the loop (7) the keyserver used by query-mail generator defaults, not to some arbitrary preference, but to BAL's keyserver, which is the most used server that I know of, and which (to the best of my knowledge) receives regular updates from several other keyservers. (8) given that "increasingly sophisticated automatic checking agents" can make it much easier for individuals to gather keys, check incoming messages, and sign or encrypt outgoing messages, it seems that such "agents" tend to increase the usage and acceptance of cryptography, which is a good thing for all concerned. A question: in a situation like this one, where an individual signed a message with a key then did not make a key with the return address of his message available either through his .plan, or a keysever (the two de facto standards), what next step -if any- do people think is more appropriate than sending mail to the individual asking them for a copy of the key ? > I'm dealing with it the same way I'm dealing with the few people > who have something in their MIME setup that triggers my mailer > (Eudora Pro 2.1) to treat their text as attachments. Namely, by > filtering them out. This is a fine anarchistic solution to the problem (and that's a compliment!), from your point of view (although, I hasten to point out, not quite as good as submitting a key with a valid address on it to a keyserver). If anyone else wishes to ignore requests for keys, the subject string to add to your email kill-file is "please send me your PGP public key" Because I do think that automating parts of the the encryption/signing/verification/decryption/key-retrieval process will make cryptography more wide-spread (in so far as there is not a backlash against this automation), I do not want to ignore the concerns of others. So...how would people do things differently if they were writing this sort of software? One idea proposed by Jiri Baum <jirib(a)cs.monash.edu.au> is to find the key ID used to sign the message, and then query the keyserver with this ID, as opposed to an email string. I'm not sure whether or not I like this idea (for security reasons), but that question is moot, as it seems to be impossible given the current keyservers. Any other suggestions or ideas? - -- TJIC (Travis J.I. Corcoran) http://www.openmarket.com/personal/tjic/ Member EFF, GOAL, NRA. opinions (TJIC) != opinions (employer (TJIC)) "Buy a rifle, encrypt your data, and wait for the Revolution!" PGP encrypted mail preferred. Ask me about mail-secure.el for emacs. -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: auto-signed by mail-secure.el v 0.998 using mailcrypt.el Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMGl7wIJYfGX+MQb5AQErpQP/XvoJ0QF4TEtPhJuxk5ifsUlXrl4RSvyP dFh1MkTQWl4/D+jFHI0MW+gyi2/EmzxEW+8zYUCLENBIq8H3QJgQDnQ9NRM3JiGU c9yd4EeE9bH8r+KppF5WfJfuE4hJ6YFRO0sdal0oJs3RfuF2ZIHoLoKPR5G97EGv dmWg2J784ZM= =xnv7 -----END PGP SIGNATURE-----

1 0

It's Wednesday
by Duncan Frissell 17 Dec '03

17 Dec '03

Do you know where your new Netscape is?

3 3

Re: Another Netscape Bug (and possible security hole)
by donlonm＠ccmail.mcclellan.af.mil 17 Dec '03

17 Dec '03

Ray, You wrote: >I've found a Netscape bug which I suspect is a buffer overflow and >may have the potential for serious damage. If it is an overflow bug, >then it may be possible to infect every computer which accesses a web >page with Netscape. Is there any way to avoid/prevent this problem by changing options in NetScape? Thanks, Mike D.

3 2

Microsoft & new Internet Security specs
by Harry S. Hawk 17 Dec '03

17 Dec '03

http://www.prnewswire.com/cnoc/story/569463/18018 > [Company News on Call] [Return to Company Listing] > [Return to Headlines] > > MICROSOFT PUBLISHES SPECIFICATIONS DESIGNED TO HELP > IMPROVE SECURITY ON THE INTERNET > > ATLANTA, Sept. 27 /PRNewswire/ -- Microsoft Corp. (Nasdaq: MSFT) > today announced the publication of two specifications that address key > Internet security issues. Software designed with these specifications > will enable developers to incorporate improved security technology into > their applications, giving businesses and consumers confidence that > their transactions and communications will be secure. > The two specifications -- Secure Transaction Technology (STT) and > Private Communication Technology (PCT) -- were published today on the > Internet. To help encourage widespread adoption of STT and PCT, > Microsoft is making the specifications available at no charge to all > software developers, businesses, card brands and financial institutions > that want to create STT-compliant and PCT-compliant applications. Both > can be found on the Microsoft home page (http//:www.microsoft.com). > "We set out a year ago to build STT, a security system that meets > the strict requirements of the payment-card industry. STT's design uses > sophisticated cryptographic techniques to help protect and authenticate > consumers, merchants and financial institutions that use bank cards to > conduct business on the Internet," said Craig Mundie, senior vice > president of the consumer systems division at Microsoft. "After doing > so, we felt we could also apply our expertise to the Internet's need for > general-purpose security. PCT builds upon Secure Sockets Layer by > incorporating strong authentication and other technologies we developed > for STT." > STT, jointly developed with Visa International, is supported by the > Internet Shopping Network, RSA Data Security Inc. and Spyglass Inc. The > PCT specification is supported by Cylink Corp., FTP Software Inc., > Internet Shopping Network, NetManage Inc., OpenMarket Inc., Spyglass > Inc. and Starwave Corp. > "We cannot afford to have doubt cast over the ability to conduct > business on the Internet," said Marc Miller, executive vice president of > marketing and business development for Spyglass Inc. "We applaud > Microsoft for approaching the security issue as it should be approached > -- in an open forum within the Internet community. Our whole business > model is based on partnerships. We're happy to be working with > Microsoft to provide an open, specifications-based solution to help > ensure the viability of this exciting new medium." > The Secure Transaction Technology specification, jointly developed > by Microsoft and Visa, is designed to provide a secure method for > handling credit-card transactions across private and public networks. > By providing a technology that can be completely integrated with the > current bank-card system, STT will serve as a reliable payment system > for software providers to incorporate into their products. STT also > preserves the branded transaction relationships that merchants and > financial institutions have with their customers. > The Private Communication Technology specification is designed to > secure general-purpose business and personal communications on the > Internet. PCT includes features such as privacy, authentication and > mutual identification. As a secure communications technology, PCT > builds on the earlier advances embodied in Secure Sockets Layer (SSL). > PCT enhances SSL by separating authentication from encryption. This > means that PCT allows applications to use authentication that is > significantly stronger than the 40-bit key limit for encryption allowed > by the U.S. government for export. > "The Internet Shopping Network is committed to providing the most > secure online shopping environment possible," said Boris Putanec, vice > president of engineering for the Internet Shopping Network. "STT > delivers one of the highest levels of security and authentication for > shopping transactions, boosting electronic commerce." > Microsoft plans to incorporate both STT and PCT into its own > products, such as the Microsoft(R) Internet Explorer 2.0, which ships > with the Window(R) operating system, and is encouraging other software > developers to do the same. > The specifications released by Microsoft include use of encryption > capabilities based on technology from RSA Data Security Inc. > Founded in 1975, Microsoft is the worldwide leader in software for > personal computers. The company offers a wide range of products and > services for business and personal use, each designed with the mission > of making it easier and more enjoyable for people to take advantage of > the full power of personal computing every day. > Microsoft is either a registered trademark or trademark in the > United States and/or other countries.

1 0

Re: Timothy C. May: Mini-mailbombs and Warning Letters
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 4:28 PM 9/27/95, Travis Corcoran wrote: >As the author of the package in question, I would like to point out: > >(1) the email msg Tim refers to (hereafter refered to by me as "query-mail") > was a request for information, not a warning I've received several of these, not just the one Travis sent. I don't sign my messages, never have, so I see no way this "agent" Travis ran could find such a signed message from me.m (It's conceivable he found an old--really old--message with a faked-up sig, as perhaps for a demonstration or spoof I was doing, but I'm skeptical. In any case, I suspect only an "automated searcher" could find the one or two messages that may look like this. If Travis produces the message here, I'm sure this will be what the situation is.) >(4) checking right now, I find that the finger command does indeed > fail to get a public key from Tim's address. > >(5) checking right now, I find that BAL's keyserver does indeed fail > to give any key with the address "tcmay(a)got.net" Like I said, I don't sign messages. My PGP 2.0 key was signed at the second CP meeting and, they tell me, submitted on the original MIT ring. "tcmay(a)netcom.com" was my e-mail address at that time. >A question: in a situation like this one, where an individual signed a >message with a key then did not make a key with the return address of >his message available either through his .plan, or a keysever (the two >de facto standards), what next step -if any- do people think is more >appropriate than sending mail to the individual asking them for a copy >of the key ? Ignore it. Why hassle people who have no plan or finger configurations? (I don't have a shell account.) Besides, people who really want to communicate with me with PGP simply ask for it. If you don't like this, fine. But don't robo-interrogate and send robo-warnings. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1

Re: macworld crypto articles
by Steve Bryan 17 Dec '03

17 Dec '03

>> In article <4444rl$nrh(a)life.ai.mit.edu> Chen writes: >> > It's truly a deplorable state of affairs. >> >> For the next version, include PGP free with every version of Quicken, >> and have Quicken just "call" PGP. >> >> Of course, users can encrypt their files now with PGP. Is there an >> Intuit bboard where someone could post instructions? > >This is a good idea. I'll bring it up with the appropriate people. > >Right now, we only have some cheesy forums going on Compuserve and >Prodigy; however, keep your eyes peeled. We have other stuff in the >works. PGP is probably too unweildy for the non-hobbyist to comfortably use. I don't know if anyone else has suggested it but I'd strongly encourage Intuit to make CryptDisk for the Mac easily available. I use it to maintain an encrypted partition for my financial data and the user interface is quite simple. I believe the DOS equivalent is SecureDisk. +---------------------------------------------------------------------- |Steve Bryan Internet: sbryan(a)gofast.net |Sexton Software CompuServe: 76545,527 |Minneapolis, MN Fax: (612) 929-1799 |PGP key fingerprint: B4 C6 E2 A6 5F 87 57 7D E1 8C A6 9B A9 BE 96 CB +----------------------------------------------------------------------

2 1