December 2003 - cypherpunks-legacy

RE: MD5 weakness ? [was Re: Netscape Log
by dmandl＠bear.com 17 Dec '03

17 Dec '03

> I have unsubscribed from this mailing list. Please remove my name from > your personal address lists. Thanks. > > ahg3 We heard you the first 15 times, Einstein. --D. -- ******************************************************************************* Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *******************************************************************************

1 0

Re: Netscape Logic Bomb detailed by IETF
by tomw＠orac.engr.sgi.com 17 Dec '03

17 Dec '03

In article <DGypKo.Isx(a)sgi.sgi.com>, sameer <sameer(a)c2.org> writes: >> I posted a list of MD5 checksums as a personal favor to various cypherpunks >> who asked for them, since I have access to the original bits. The official >> Netscape solution for checking your downloaded distribution will be >> announced later in the year. In the mean time anyone who is uncomfortable >> with downloading the bits from the net can always buy a copy. We will >> ship them the distribution on floppy. >> > That's quite lame.. (not on your part jeff, obviously, because > you posted the md5s) Netscape's responses in the past has been pretty > quick, but this is damn slow. I am disappointed. This isn't an easy problem. Personally, I'd rather have them get it right than get it done fast. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw(a)engr.sgi.com

1 0

(www-b) (fwd) Privacy Marketing
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Nick's on a roll now... Cheers, Bob Hettinga --- begin forwarded text From: szabo(a)netcom.com (Nick Szabo) Subject: Privacy Marketing To: philipw.nrd(a)cbo.gov (PHILIP WEBRE) Date: Wed, 25 Oct 1995 09:26:23 -0700 (PDT) Cc: www-buyinfo(a)allegra.att.com Mime-Version: 1.0 Most Internet businesses, especially the Web software and payment systems providers, are severely underestimating the market for privacy features that is out there. Consider: * A recent general survey showed that 83% of Americans are very concerned about their privacy on the "Information Superhighway". One can expect even stronger figures from European customers, which have more first-hand experience with private data, much of it originally compiled for innocuous reasons, being used for political repression. The vast majority of our customers are concerned about privacy. * Marketing surveys on privacy that are both detailed and accurate are hard to come by, because customers who care more about their privacy tend to dislike filling out detailed forms (even if they claim to be anonymous). * Over half the BBS, and potentially the Internet, online service market is in controversial services, where customers are even more concerned about privacy than average. * Privacy, once considered merely a political issue, is now being recognized for its more important aspect, as a market differentiator and value-add. Marketers correctly recognize that government "privacy regulations" mean much less privacy for businesses if it is to be enforced, and the voters no longer expect such laws to have any teeth in the face of modern technology. That hardly means that customers are not concerned about it, as the numbers show. The alternative to regulation is market solutions. Recognize that many customers do want privacy, give them what they want, and contrast yourself to your competitor. Making visible the ways your competitor is violating their customers' privacy will become a powerful marketing strategy. This strategy was used rather timidly, and inaccurately, by AT&T against MCI, where it nevertheless had great success. (Inaccurate because all major phone companies compile lists of who calls whom, and use them for marketing as well as billing -- MCI was simply being more honest about it). Used boldly and accurately, privacy marketing has vast potential to upset competitors who rely too much on marketing data and not enough on empathy with the human customer. For an idea of what such a marketing campaign might be like, imagine combining Apple "1984" Mac ads, one of the most effective campaigns in history, with the AT&T vs. MCI campaign, to sell products and services that in fact do protect customer privacy where the competition does not. * Most Americans do _not_ participate in frequent flier and similar customer tracking programs. Many who do participate don't realize the extent to which their lifestyle is tracked, since these actions are performed on remote databases, well hidden from the customer. If customers aren't concerned about their privacy, then why the need for all the distracting gimmicks and giveaways? Why not just promote these programs straightforwardly to the customer as "Customer Tracking Programs"? A competitor who can provide a privacy protecting solution can do just that, damaging these tracking programs severely. * It is ludicrous to argue that cash transactions, which leave no identified paper trail, provide no practical privacy. In fact they prevent detailed compilation of lifestyle habits, by (a) not depending on identity to settle the transaction, (b) making identity tracking, where it occurs, a visible, separate process, and (c) making it too expensive to track identity via the payment system itself, except in extreme, very rare cases. In practice, this means that cash customers don't get their lifestyles described in detail in remote databases, while non-confidential electronic payers increasingly do. Eventually this sharp difference in outcome will feed back to the customer, greatly increasing the demand for cash over non-confidential electronic payment. * A big challenge for vendors value-adding privacy is to accurately communicate these privacy features, through both the user interface and their marketing, while debunking fraudulent claims (such as calling non-confidential payment systems "cash") and exposing the privacy violating actions of their competitors. I conclude that privacy marketing will be an important value-add for Internet commerce. It will be a terrific way to gain market share at the expense of the competition -- or to lose much of your market share, if you find yourself on the wrong end of a privacy campaign. Nick Szabo szabo(a)netcom.com Consultant, Internet Commerce & Security IBM, Sequent, DigiCash, Agorics Nine years experience on the Internet --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

BSDC: Designing Systems for Electronic Commerce
by rah＠shipwright.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The Boston Society for Digital Commerce Presents Win Treese Open Market, Inc. Designing Systems for Electronic Commerce Tuesday, November 7, 1995 12 - 2 PM The Downtown Harvard Club of Boston One Federal Street, Boston, MA Win Treese is Director of Security and Advanced Technology for Open Market, Inc., a startup company building systems and software for electronic commerce on open networks. Before joining Open Market, he was a member of the research staff at the Cambridge Research Laboratory of Digital Equipment Corporation, where he worked on a variety of projects, including the design and implementation of Digital's Internet firewall system and the AudioFile network audio system. Win says: >"Electronic commerce" is a short name for a big topic. In this talk I >will describe Open Market's Transaction Management System and other >components that can be used in many different applications, such as >ordering of retail products for delivery, subscription access to >information, "pay-per-page" purchasing of information, and others. In >addition to payment, I will discuss other issues that arise in >commerce, such as customer service and content management. This meeting of the Boston Society for Digital Commerce will be held on Tuesday, November 7, 1995 from 12pm - 2pm at the Downtown Branch of the Harvard Club of Boston, One Federal Street. The price for lunch is $27.50. This price includes lunch, room rental, and the speaker's lunch. ;-). The Harvard Club *does* have a jacket and tie dress code. We need to receive a company check, or money order, (or if we *really* know you, a personal check) payable to "The Harvard Club of Boston", by Saturday, November 4 (that's one week from this Saturday), or you won't be on the list for lunch. Checks payable to anyone else but The Harvard Club of Boston will have to be sent back. Checks should be sent to Robert Hettinga, c/o The Shipwright Development Corporation, 44 Farquhar Street, Boston, Massachusetts, 02131. Again, they must be made payable to "The Harvard Club of Boston". If anyone has questions, or has a problem with these arrangements (We've had to work with a few glacial A/P departments ourselves, for instance), please let us know via e-mail, and we'll see if we can work something out. November's speaker will be Art Hutchinson of Northeast Consulting Resources, Inc. We are actively searching for future speakers. If you are in Boston on the first Tuesday of the month, and you would like to make a presentation to the Society, please send e-mail to the BSDC Program Commmittee care of Robert Hettinga, rah(a)shipwright.com . For more information about the Boston Society for Digital Commerce, send "info bsdc" in the body of a message to majordomo(a)ai.mit.edu . If you want to subscribe to the BSDC e-mail list, send "subscribe bsdc" in the body of a message to majordomo(a)ai.mit.edu . Looking forward to seeing you there! Cheers, Bob Hettinga Interim Moderator, The Boston Society for Digital Commerce -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMI5Iw/gyLN8bw6ZVAQF3FQP+LxoCbP4AoijIMobOVE1PzX066WrmvwMb pSaSpBP4F7/XJ0NP2EdKDZw24xpqxrvKm6j+FDzC3dDWcR3zlZPeEjvIGSFpNDW4 QJhGDlBfDo8LPAp9ua28CwxDSeyFmUZcMIjh7cgVOjCuG9Gegkn0jO3MihtrDb7U yki9gTYDaNw= =2VH9 -----END PGP SIGNATURE----- ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

CNN Interactive Internet privacy interview
by m5＠dev.tivoli.com 17 Dec '03

17 Dec '03

Probably triggered by the USA Today article. <URL:http://www.cnn.com/TECH/9510/computer_privacy/index.html> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Nobody's going to listen to you if you just | Mike McNally (m5(a)tivoli.com) | | stand there and flap your arms like a fish. | Tivoli Systems, Austin TX | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: airport security
by Peter Trei 17 Dec '03

17 Dec '03

Another data point: This week I flew TWA from Boston to St. Louis, then TW Express from St. Louis to Champaign, Ill, and back. I was asked for picture ID when boarding at Boston, but at no other time. I protested, and was told that my alternative was not to fly. Since I was travelling on business and my employer's dime, I did not want to risk missing the flight, so I complied. Peter Trei ptrei(a)acm.org

1 0

Mandatory ID in California?
by Ian Goldberg 17 Dec '03

17 Dec '03

>From "The Daily Californian", Wed., 25 October, 1995, page 3: <snip> "Police were called to the scene by an officer who passed Burton and smelled marijuana smoke, Phelps said. The officer believed it was coming from Burton's cigarette. "The officer issued a citation to Burton for smoking marijuana and requested to see identification. Burton refused to show identification and argued that smoking marijuana is legal in Berkeley, Phelps said. "The officer, in accordance with police policy, arrested Burton for refusing to properly identify himself." <snip> That last sentence seemed ominous to me... - Ian

1 0

CTCP
by Rev. Mark Grant 17 Dec '03

17 Dec '03

If Maude X (the author of CTCP) is still on the list, can they contact me, as I've been playing with it in the last few days and have added new features and increased the RNG security somewhat. If they're not around I'll release an updated 'unofficial' version in a week or two. Mark

1 0

[NOISE] Re: BlackNet in "Hardware"
by Peter Trei 17 Dec '03

17 Dec '03

> I recollect that the Amiga had some gizmo--I think it was called > "MagicSack" or something like that--that let it run Macintosh programs, > sort of. It never really caught on, at least as an alternative to real > Macs. And I think something similar was available for DOS. This was all > several years back, before the Amiga faded out. > > Amiga users and former Amiga users can probably tell us more. > > --Tim May The Amiga 2000 had two sets of slots - one for amiga-specific cards, and one for PC cards. Some of these slots lined up, and you could slip in a 'Bridgeboard' which carried an Intel processor. It could access the PC slots, the amiga IO, and had it's own disk partitions. There were mechanisms for the two processors to exchange data as well. I *think* there was a similar MAC product as well, or at least a board which could carry MAC ROMs, and used the Amiga 68000 processor. So the answer is: yes, the Amiga could do that. It also had long filenames, thousands of colors, true preemptive multitasking, stereo sound, a DSP coprocessor,and many other neat features years before they were available on other consumer systems, as well as display quality and features still unavailable on any system even near its pricepoint. But - Commodore's marketing department couldn't sell ice in the Sahara. I'll stop now, or I'll start mourning for TOPS-20 as well... Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

1 0

Re: textbooks
by koontz＠MasPar.COM 17 Dec '03

17 Dec '03

IP/FP and PC1 describe how to get from input bytes to L, R, C and D Blocks: The Initial Permutation The Initial Permuation (IP) is a description of how a byte wide interface is connected to a 64 bit block comprised of two 32 bit blocks (L and R). Consider a byte wide interface with the bits numbered 1-8. The event numbered bits go to the L Block and the odd numbered bits go to the R block. Note that the bit order is big endian, where bit 1 is most significant and bit 8 is least least significant. The input block is typically loaded as 8 successive byte loads: Port MSB7 Input (LR) Left Bit Bit Block (64 bits) Block (32 bits) 2------6-------58 50 42 34 26 18 10 2 1 2 3 4 5 6 7 8 4------4-------60 52 44 36 28 20 12 4 9 10 11 12 13 14 15 16 6------2-------62 54 46 38 30 22 14 6 17 18 19 20 21 22 23 24 8------0-------64 56 48 40 32 24 16 8 25 26 27 28 29 30 31 32 Right Block (32 bits) 1------7-------57 49 41 33 25 17 9 1 1 2 3 4 5 6 7 8 3------5-------59 51 43 35 27 19 11 3 9 10 11 12 13 14 15 16 5------3-------61 53 45 37 29 21 13 5 17 18 19 20 21 22 23 24 7------1-------63 55 47 39 31 23 15 7 25 26 27 28 29 30 31 32 Input Byte 8 7 6 5 4 3 2 1 The Final Permutation The Final Permutation (IP-1) provides the inverse, it standarizes the output of the R16L16 output block to a byte wide interface. The Output block is ordered Right then Left to allow complementary operation for subsequent decryption. Were one to perform an IP followed by IP-1 without any intervening round iteration operations, one would end up with odd and even bits swapped: Right Output (R16L16) Standard Port Block (32 bits) Block (64 bits) Bit Bit 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8---------6--------2 9 10 11 12 13 14 15 16 9 10 11 12 13 14 15 16---------4--------4 17 18 19 20 21 22 23 24 17 18 19 20 21 22 23 24---------2--------6 25 26 27 28 29 30 31 32 25 26 27 28 29 30 31 32---------0--------8 Left Block (32 bits) 1 2 3 4 5 6 7 8 33 34 35 36 37 38 39 40---------7--------1 9 10 11 12 13 14 15 16 41 42 43 44 45 46 47 48---------5--------3 17 18 19 20 21 22 23 24 49 50 51 52 53 54 55 56---------3--------5 25 26 27 28 29 30 31 32 57 58 59 60 61 62 63 64---------1--------7 Output Byte 8 7 6 5 4 3 2 1 >From FIPS Pub 46-2: Final Permuation IP-1: Output Byte 40 8 48 16 56 24 64 32 1 39 7 47 15 55 23 63 31 2 38 6 46 14 54 22 62 30 3 37 5 45 13 53 21 61 29 4 36 4 44 12 52 20 60 28 5 35 3 43 11 51 19 59 27 6 34 2 42 10 50 18 58 26 7 33 1 41 9 49 17 57 25 8 1 2 3 4 5 6 7 8 Port Bit 7 6 5 4 3 2 1 0 MSB7 Bits In the simplest hardware implementation of DES, the Left and Right blocks are comprised in hardware of four 8 bit register each. Each 8 bit register can be serially loaded (IP), serially unloaded (IP-1), or parallel output and parallel loaded (round interation). DES is an encryption algorithm originally required to be implemented in hardware, specified in 1977 - predating 16 or 32 bit microprocessor peripherals. Permuted Choice 1 PC1 performs a similar function loading the C and D 28 bit registers (comprised of three 8 bit bidirectional shift register and 1 4 bit bidirectional shift register, all with parallel outputs). The C and D registers can be serially loaded (shifting right), or serially shifted left or right in a closed ring for encryption or decryption. Port MSB7 Bits Bits Input (CD) C Block, 64 bits Block (28 bits) 1--------7------57 49 41 33 25 17 9 1 MS 1 2 3 4 5 6 7 8 2--------6------58 50 42 34 26 18 10 2 9 10 11 12 13 14 15 16 3--------5------59 51 43 35 27 19 11 3 17 18 19 20 21 22 23 24 4--------4------60 52 44 36 ----------- (C(28)) 25 26 27 28 D Block (28 bits) 7--------1------63 55 47 39 31 23 15 7 1 2 3 4 5 6 7 8 6--------2------62 54 46 38 30 22 14 6 9 10 11 12 13 14 15 16 5--------3------61 53 45 37 29 21 33 5 17 18 19 20 21 22 23 24 4-------(D(25)--------------28 20 12 4 25 26 27 28 8--------0------64 56 48 40 32 24 16 8 LS (parity) Input Byte 8 7 6 5 4 3 2 1 Note that bit 4 is used as input for both C and D. This implies that C(28) output is used as the serial input to D(25). The least significant bit is used for odd parity.

1 0