December 2003 - cypherpunks-legacy

Re: Automatic E-Mail
by Bill Stewart 17 Dec '03

17 Dec '03

[This isn't quite on topic, though you could stretch it to deal with remailers. Can the winsock remailer do this?] At 10:50 PM 9/18/95 GMT, Rick.Sciorra(a)hudson.lm.com wrote: >Does anyone know of an E-Mail package that will automatically connect >to the Internet and retreive mail at specific intervals? Sigh. Folks have gotten too used to PC-market email systems, which are generally braindamaged by having been around operating systems where you can't just run a listner program that waits for somebody to call you when they want to send you mail, which of course fits in very well with letting ISPs avoid having to make outgoing phone calls instead of just receiving, plus the market reluctance of many of them to forward mail for you to competing mail services and the client/server-orientation that makes peer-to-peer services harder to implement. Unix systems did this job just fine on PDP11/70s, which could support a dozen or two users on a machine with about the horsepower of a PC/AT. And Henry Spencer could do that on a /44 :-) Just about anything that does UUCP can be set to do that, if you've got an ISP who doesn't charge you lots extra for using UUCP. Most high-end terminal emulation packages have scripting languages that let you call up and do stuff, which you should be able to call from timer programs; you can probably even find a free Kermit version that will do it. I use Eudora Light with Trumpet to call Netcom's newbie-friendly Netcruiser service; when I hit the menu item for send or retrieve mail, it pops through all the layers and dials, and hangs up when it's done. If Commercial Eudora can't already do that automagically, it should - ask Qualcomm to add it to the next version... Alternatively, Winsock programming isn't really all that hard, and POP3 is a pretty simple protocol, so you could roll your own. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: MIME attachments and ranting.
by Bill Stewart 17 Dec '03

17 Dec '03

>> >Attachment Converted: D:\DOWNLOAD\MIME\RePGPfor.8 >> I, for one, don't need Mystery MIME Attachments cluttering up my drive. If >> it's worth saying, then *say* it. >I really don't know why any mailers call a monopart MIME message an >"attachment". Mail readers come in three basic flavors of unMIMEificationness: 1) Ignorance+bliss - the mailer doesn't know or care about MIME headers, and you can ignore them when you read them, and may be able to configure the reader not to bother you with most of them (e.g. BSD Mail.) 3) Intelligence - the mailer does something genuinely useful to help you read the attachment, like letting you pop up some appropriate reading tool. 2) Naive friendliness - the Sirius Cybernetics approach. "Your mail file has been tastefully shredded into little pieces and sprinkled around your disk drive. Thank you for making a humble mail system so _very_ happy." Free Eudora versions offer you several choices of tastefulness and shredditude, partly intended to provide artistic functionality and partly to encourage you to buy the commercial version which gives you a more flexible user interface for extensions like MIME. So buy it, or cope with it, or tell Eudora to use your RAMdisk for its attachments where they'll soon go away and not bother you. There's also another approach, typified by a vendor whose name will be omitted but they'd know who they were if they had a <perjorative deleted> clue.... 0) Downright hostile - Not only does it _pretend_ to be Intelligent, while only really doing the right thing with its own proprietary data formats*, though generally doing something reasonable with uuencoded documents with names that it understands, but it chokes and dies on messages that have even moderately large amounts of simple, basic, non-attachmentized _text_, and if you _do_ try to package text up to send to some poor sucker who's stuck with one of these <perjorative deleted> systems, it hands it to a brain-damaged user-friendly mouse-editor that _also_ chokes on more than 64KB of text.... [* where "the right thing" allows it to mindlessly run arbitrary code handed to it as macros in the proprietary data formats that the company encourages its users to use instead of real text....] #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: NYT on Netscape Crack
by Bill Stewart 17 Dec '03

17 Dec '03

> The New York Times, September 19, 1995, pp. A1, D21. > ...... > "The good news and the bad news of the Internet is that > when you put something up there, many more people can test > it," said Mike Homer, the vice president of marketing at > Netscape. "You also give yourself the opportunity of having > people point things out which you can fix quickly." That's a good, and realistic, attitude. > Netscape officials said today that they would strengthen > the system, by making it significantly harder to determine > the random number at the heart of their coding system. They > said they would no longer disclose what data would be used > to generate the random numbers. I do hope this is just John Markoff's simplification of what Netscape's folks said and not an endorsement of security-by-obscurity. I realize that some data does need to be kept around on disk or in the program, since obtaining a lot of random bits at the beginning of every transaction either requires annoying user interactions or takes too long to get decent quality, and certainly this data ought to be kept private by the algorithms involved. One concern I've had about the popular "crunch some bits repeatedly through MD5" approach to random number generation is that knowing one sample from the stream (e.g. by doing a transaction with the victim) gives you the rest of the stream. There's a way to improve that. let X(0) be some number you keep around from a previous session, modified by whatever hardware randomness is available, and seeded by user input the first time. let X(i) = MD5(X(i-1)) let Y(i) = hash(X(i)), where hash is something like MD5(key,X(i)) use Y(i) as the output random number. This eliminates the ability to determine X(i) or Y(i+1) as a function of Y(i), since the search space of X(i) is presumably too large to reverse (unlike the number of bits you can cheaply get in one session). Keeping some of the bits of Y(i) around to use in addition to the other key for the hash, or to key the MD5(X(i-1)) with, may be useful as well. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: Caribbean Internet Services? (fwd)
by Bill Stewart 17 Dec '03

17 Dec '03

Tim wrote: >>> I suspect "Caribbean Data Havens" and "Internet Sites" are further off than >>> they were a few months ago. The governments of the affected islands will have to make some tradeoffs - do they allow providers of these services to operate freely, bringing in new telecomm facilities so they can get the revenues from (let's keep the Minnesota AG happy) gambling and other private-communications trade, or do they leave their telecomm monopolies in place, so they can get the telecomm revenues which get into government coffers more quickly? Is there enough market to convince them to open up, which will attract more services? How much does being first matter? #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Quick ITAR question....
by descarte＠mcqueen.com 17 Dec '03

17 Dec '03

I've just about finished the perl SSLeay implementation and I was musing about how I would manage to do one for SSLref also....... Here's the situation: I'm in Britain, but I have access to a machine which I wll develop on in the States. Can I develop Net::SSLref on this machine? My feeling is, no, since I'm not a US citizen ( does this matter with ITAR? ). Similarly, it could be construed that the characters constituting the source code are crossing the Atlantic to my machine here, albeit not being stored. Conversely, I'm not reading *all* the code, so I couldn't necessarily build SSLref from this action ( a parallel may be the export of 1/723 of PGP in a .sig! ) Any comments would be much appreciated. Thanks. -- Alligator Descartes | PGP Key available on request. descarte(a)mcqueen.com | http://www.mcqueen.com/hermetica

1 0

Re: taxonomies of 'real money' and e-cash
by P.J. Ponder 17 Dec '03

17 Dec '03

On the 18th, Tim May wrote: > > I wasn't saying they are all on the same footing, or are all separate and > compartmentalizable things. Clearly some of them are just slightly > different "flavors" of other things. I listed a bunch of them not as a > taxonomy or ontology, but as an illustration that there are many kinds of > financial dealings, many kinds of roles played. > > That the real world has so many flavors of financial things could of course > be due to inertia and ignorance, partly. But there are also different > functionalities, and costs. Fitting the different needs, the different > roles of the players. I won't go on and on, as my last post on this I think > hit the main points, but consider how many flavors we have just of > "checks": the "ordinary" checks we write, counter checks, dual-endorser > checks, traveller's checks, and so on. (If you are arguing that only > "digital cash" is a real issue, and all other constructs are "small matters > of programming," then we disagree profoundly.) My mistake then. You obviously have in mind some things much more subtle and more logically removed from money, or currency, or even liquidity than what I thought you were referring to. I'm going back to reading the list in the mornings. --PJ . . . . > --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

Errors in Applied Cryptography, 2nd Edition
by Bruce Schneier 17 Dec '03

17 Dec '03

I have taken a three stage approach to reducing the number of errors in the second edition: 1. Correct the errors from the first edition. 2. Ensure that I don't create any new errors while writing the new material for the second edition. 3. Make sure that additional errors don't creep in during the production of the second edition. In order.... I have done a lot more than incorporate all the corrections from the errata into the second edition. Minor things, too trivial to make the errata list, were also corrected. The first edition was translated into French, and the translator sent me hundreds of queries: things that were unclear, ambiguous, or erroneous. All of those queries resulted in changes to the second-edition manuscript. I was a lot more careful adding new material, reading it over several times to ensure accuracy. And a lot of other people read the chapters over, too. For the first edition, I asked about a dozen people to proofread the manuscript for me. Most people read the first chapters carefully, and then petered out somewhere in the middle. This time I asked about seventy people to each read a chapter (or two)--a chapter within their area of expertise. Each chapter was edited by at least two people, often more. Additionally, two people were paid to read the entire book for accuracy and comprehensibility. I learned a lot about the publishing process during the production of the first edition. For the first edition, I had no control of any of the production decisions. The copyeditor added errors to the manuscript. Some computer idiot lost all of my italics, boldface, superscripting, and subscripting while translating my files from my word processor to their page layout program. The proofreader didn't catch errors that the production people added. I had almost no time to review the manuscript at any of the stages. This time around I was able to choose my own copyeditor, proofreader, and indexer. In fact, there were two separate rounds of copyediting with two different copyeditors. The proofreader is not only the most meticulous proofreader I know, but someone who knows enough math to catch errors in the equations. I verified all file translations myself. And I reviewed the copyedited manuscript twice, and two separate passes of page proofs. I'm not stupid enough to state that the book is 100% error-free, but I am confident that there are far fewer errors in the second edition than there were in the first. I was embarrassed at some of the errors in the first edition, and I put a lot of effort into making sure it doesn't happen again. Bruce ************************************************************************** * Bruce Schneier * Counterpane Systems For a good prime, call 391581 * 2^216193 - 1 * schneier(a)counterpane.com **************************************************************************

1 0

Re: NYT on Netscape Crack
by Duncan Frissell 17 Dec '03

17 Dec '03

At 11:00 PM 9/18/95 -0400, John Young wrote: > The New York Times, September 19, 1995, pp. A1, D21. > > > Security Flaw Is Discovered In Software Used in Shopping > > By John Markoff On the Front Page, *above* the fold. Perhaps John was trying to make up for being scooped by the WSJ on the SSL Crack story. DCF "The key to the age may be this, or that, or the other, as the young orators describe; the key to all ages is-Imbecility; imbecility in the vast majority of men, at all times, and, even in heroes, in all but certain eminent moments; victims of gravity, custom, and fear." -- Ralph Waldo Emerson

1 0

Re: NYT on Netscape Crack
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

Eric Young <eay(a)au.oz.mincom> writes: > I will defend Netscapes code on the point about the RNG even though > I have not seen any. I assume the Netscape code is quite large and > each release would have to pass various fuctionality tests. How can > you test that the RND seeding is wrong? You have to actually look > at the code, the number coming out are still random. As of last > week I was told by Mike_Spreitzer.PARC(a)xerox.com that the random > number generator seed routine in my DES library was only copying in > 4 bytes of passed data instead of 8. Given des_cblock data;, it was > > memcpy(init,data,sizeof(data)); > > it should have been > > memcpy(init,data,sizeof(des_cblock)); > > Rather hard to notice unless you know that des_cblock is passed as a > pointer and even this can be compiler dependent. Sure that's hard to notice, but what you describe was an accident, ie the code wasn't working as you thought it was. The netscape one by the sound of it, and the earlier posts of the reverse-engineered ran no code, was working to spec, it was just a dumb spec. I felt sorry for netscape when they got chosen as the example of an ITAR crippled app to break, the breakers intention obviously being to tar ITAR, but some of the bad publicity rubbing off on netscape, who were obviously fully aware of the weakness of 40 bit keys. This one tho' sounds very much like due to sloppy design which is inexcusable, especially given that they are going around selling the 128 bit RC4 browser to people who may have been relying on it, at it's word, and presume the rest of the cryptographic system was up to suitable standard to match 128 bit keys. aka what's the point having 128 bit keys if you use a 32 bit, or 40 bit or 48 bit seed, which can be further narrowed with non-root access to the machine, and even with external info leaked by the machine. > The moral of the story I suppose is to be > paranoid about checking routines relating to RNG. Well that is a valid, and very good moral, but the netscape story is a different story I think, as they knew what their code was doing, and somehow didn't think it was a problem, or didn't even pause to consider the ran no generation security. Reckon any bad publicity they get out of this one is entirely their own fault. The moral in netscapes story is that closed systems are bad news. These things ideally need open review. And of course designing things with the expectation that they are secure with the *given* that the full algorithm is known. Real shame because the rest of the software is very innovative compared to other browsers, and apparently good quality. Also may be a set back for net commerce, which is bad news. Adam -- Munitions-T home page: http://www.obscura.com/~shirt/ #!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL $m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa 2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*',$_)while read(STDIN,$m,($w=2*$d-1+length($n)&~1)/2)

2 1

Time release crypto
by keelings＠wu1.wl.aecl.ca 17 Dec '03

17 Dec '03

Incoming from Stephen D. Williams: > > What minimal requirements would be needed to support encrypted packets/files > that a holder could only decrypt after a certain date/time? > (Time Escrow?) How do you expect the system to reliably tell accurate time? What's to stop anyone from just resetting the clock to get at what they want? As always, physical access to the system breaks all security. -- "Remember, obsolescence (Win95) isn't an accident; it's an art form!" keelings(a)wu1.wl.aecl.ca s. keeling, aecl - whiteshell labs

1 0