- cypherpunks-legacy - lists.cpunks.org

Need testing help
by Rich Salz 17 Dec '03

17 Dec '03

I need some help testing my rewrite of mixmaster. It is four separate programs (keygen, user-agent, queue process, daemon reception) writting in portable ANSI C (gcc -Wxxxx is silent). It does not include RSAREF, but has a sane makefile for it if you need. It uses autoconf. It has some bugs. If you're in the US, drop me a line. Is decrypt-only software okay to export? If so, then I have an export version, too. /r$

2 1

Re: New technology around the corner [slashdot.org] (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Wed, 18 Feb 1998 11:32:21 -0700 > From: Jim Burnes <jim.burnes(a)ssds.com> > Subject: Re: New technology around the corner [slashdot.org] > Does anyone else get the feeling that we are on the cusp of > serious exponential change in technology? I know its been > going exponential for a while, but now I'm really starting > to feel it. I have felt that way since the early 80's. The rate of technology multiplication and some of the truly weird technologies that people said wold never happen are happening. > 2. Flat Plastic Video Screens using Light Emitting Polymers "LEPs" > (Cambridge) Don't forget the fact that their test beds were done with *standard* ink-jet printers with a modified head assembly. > ObCrypto: Since polymer transistors seem to be necessary to implement > polymer memory, how does this effect computation speed? The polymer > transistors must be around 30-40nm and low power. How long until we > have Polymer PGA,PALS,CPUs? How fast will they be? Is it time to add > a few more bits to the public key? Are there any cipher attacks that > would benefit from obscenely large amounts of fast memory? Sorry if > this is a naive question to the theorists. These are some of the exact same questions that I'm trying to add numbers to myself... when we take the union of the computer, information processing, networking, bio-engineering, transportation, etc. industries the various predictions of Toffler and others seem woefuly short-sighted. ____________________________________________________________________ | | | When a man assumes a public trust, he should | | consider himself public property. | | | | Thomas Jefferson | | | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

Re: New technology around the corner [slashdot.org] (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Wed, 18 Feb 1998 11:16:15 -0800 > From: Tim May <tcmay(a)got.net> > Subject: Re: New technology around the corner [slashdot.org] > No, I don't think we're on any kind of cusp of a growth curve. If anything, > several things are slowing down. Stricly speaking I would agree, we are *past* the cusp and on the upward rush of the technology curve. > Beware the "press release." The items above are just a few of literally > thousands of such announcements. Exactly! Only look at what people are actualy *doing* and not what they are predicting. It's one of the reasons the vast majority of forwards in the technology forum I send here are about things that have succeeded. > Remember how "laser pantography" was going to revolutionize chip-making, > and even make "back yard fabs" possible? While the concept of a backyard fab has been pretty much blown out of the water what *has* come around and *wasn't* predicted is the growth of fab-less chip design companies. If you look at how these sorts of businesses have grown since the late 80's onward it is astounding some of the custom chips these firms are willing to design and get built through renting others spare fab bandwidth. > How about "silicon on sapphire" > and how it would obsolete Integrated Injection Logic? (You don't remember > I-squared L? Shame on you, as it was scheduled to put Intel out of business > by 1976). SoS technology was always predicted to win the game *if* the issues of thermal expansion between the Silicon and Sapphire could be resolved. Also, just as with Josephson Junction devices, other methods to achieve the same levels of predicted performance at less cost were devloped. There must be technologies that fail for there to be technologies to win. Simply pointing at the failed ones as an example of why it can't happen is a strategy that is doomed. There will always be some turk who has the self-confidence to say it can be done and then does it. > Or how about plastic cubes that can store terabytes. Or wafer scale > integration. Or e-beam addressed memory. Or neural networks. Or fuzzy logic. All of these technologies are out there. They haven't reached a point where they're mature for a variety of reasons. Let's look at Terabyte storage for a moment. Consider that the largest data bases on the planet are only a few *hundred* Terebytes and of them there are only a few 10's of thousands. Perhaps the reason the market hasn't taken off in this area is because the market isn't large enough. Give it another 5-10 years so that computers have become pervasive in schools, play, home, business, etc. (and no they are not pervasive now) and the market forces to drive new material releases on CD or other long-term media as the *primary* media (paper being so now) *and* there becomes a market for the re-release of past books and material then we'll begin to see a reason for each of us to be carrying around tera-bytes of data. Fuzzy logic and neural networks resolve your telephone switching issues, are used to locate natural resources, filter intelligence data for threads, etc. They're even used in coffee makers and micro-waves now. e-beam addressed memory is a looser, and anyone with a clue back them would have said so as well. Too power hungry, physicaly a bitch to haul around in your shirt pocket, etc. > ("Hey, Tim's being a negativist. My new rice cooker says it has fuzzy logic > in it.") See! > And then there's the whole universe of speculation about quantum computers, I *strongly* suggest folks follow the Quantum Coupled Architecture developments over the next two years or so. > DNA computers, nanotechnology, etc. These are new technologies that are only a decade or two old. Consider transisitors. The first FET transistor effects was discovered in the 30's but it wasn't until the 50's that we actualy managed to build a working BJT and several years after that till the FET based technology became feasible. And there have been some interesting advances in these fields. DES being cracked by a bio-logical computer a couple of years ago for example. The ARM technology as well as the ability to not only understand but manipulate the genetics and mechanics of nano-technology have only been around 5-10 years. These are new technologies that are at the 'terrible-two's' stages of development. It's clear they can do it, they just haven't figured out how. And in the process they're rambling around the house opening every cubbard and drawer dumping the contents out. > The fact is that R&D labs partly run on hype. And journalists are willing > to interview researchers to generate stories. Until it's a reality it's *always* hype. Asking the technology to prove it itself the first day is like asking a new born baby to talk or recite Shakespeare. It's unreasonably demanding and self-deluding. > A particularly interesting place to read about all the Latest and Greatest > technologies destined to replace silicon is "Electronic Engineering Times." You can see some pretty funny predictions in the Enquirer also... It's a good thing to have an open mind, just not so open it sloshes out on the ground. > But I don't get overly excited by announcements of new developments like > this. Perhaps following the industry for 25 years has made me jaded. >From the stories of your personality and the demonstrations I've seen you're a born cynic. The street finds its own uses for technology. William Gibson ____________________________________________________________________ | | | When a man assumes a public trust, he should | | consider himself public property. | | | | Thomas Jefferson | | | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 9:29 PM 01/29/96, zinc wrote: [...] >the point is not that this can be done, the point is that users need >tools that would check for programs like this running on their >system. is fv making a 'fix' available? i would imagine a 'fix' >would be a program that would look for tsr type programs (or inits on >a mac) that do this sort of thing. At first I was going to say there was no way to do this--a program can't be written to look at an arbitrary program as intput and determine if it does a certain semantic action (steals your key strokes). And I think this is true. However, on the MacOS at least, I believe that a key-capturing program would have probably have to patch a particular point (or one of a set of particular points) in the OS, and a program could probbably look at the OS in RAM (or wherever patches happen; in RAM I think) and make sure it hasn't been patched--it's the way MacOS 7.5.X looks straight out of the shrinkwrap, nothings been done to it. Or report that, indeed, that portion of the OS has been patched, and some program might be logging your keys. [Of course, some legitimate programs might patch these portions of the OS too--so you'd have to be careful not to have a hacked version of those legitimate programs that also captured your keys. zinc's next point is relevant here, of course.] Can anyone tell me for sure if this would indeed be feasible? >this is the sort of thing that crypto can help with. there should be >a site that PGP signs the programs available from their site. these >signed programs will have been testing on the appropriate system and >verified to be free of small malicious programs such as the one you >describe. alternatively, the author themselves could PGP sign the app >(this is already done) and this would be what users should d/l. True. But, remember, you've still got to trust the _author_ of the program. Commercial programs generally dont' have source available, so I'm basically trusting Steve Dorner not to have Eudora send a copy of all my messages to the NSA. Even if the sources were available, most people aren't going to want to (or be capable of) going through the source, so they're trusting other third parties who have said "yep, I looked at the source, and it's okay." And, while there are plenty of third party types to look at a program like PGP (although, actually, I can't identify any reliable third party crypto type, not on the PGP developement team, who I know has looked at the PGP source and pronounced it okay. Doesn't mean it hasn't happened, but it means realistically, users _don't_ rely on third party guarantees of security in the source. Or at least I don't, but how many of you out there know a reliable third party source that has given a seal of approval to PGP, and specifically rely on that knowledge to give you confidence in using PGP?)... umm, while there are plenty of third party types to look at PGP, there are surely millions of lines of commercial software produced every year, and I'm not sure where all these reliable third party types to look at the code are going to come from. In theory, having source available is good. In practice, you still end up trusting the designer not to do anything bad to you.

1 0

your bogus post
by Paul Graham 17 Dec '03

17 Dec '03

We run an online mall. We had been planning eventually to offer the store owners the option of taking fv payment as well as credit card numbers. After reading your recent post to cypherpunks, which I would say is the most bogus post ever made on this bogus subject, we are determined *not* to use fv payment systems if we can possibly avoid it. That post was news to no one. The kind of attack you "discovered" has been known about for years, and is just not a serious threat. Your post was nothing but a calculated attempt to frighten end users, and get publicity for fv. A company capable of doing such irresponsible things is not one that we would trust with users' money. -- pg

3 2

Domain hijacking, InterNIC loopholes
by rishab＠dxm.org 17 Dec '03

17 Dec '03

While filling in details for modification of my domain (dxm.org) I realised that I haven't seen much written on domain hijacking. We all know about mail spoofing, which let's you pretend you're someone else. Mail spoofing is one-way - you can send, but not receive. This is the same with IP spoofing, where you pretend to be a trusted machine, but again you can send but not receive. Unlike IP spoofing, which can lead to major security breaks (you can become root on someone else's machine), domain hijacking is not so much a security issue as a commercial one. Domain hijacking uses loopholes in InterNIC domain registration procedures to completely take over a domain, allowing you to send and receive e-mail, and other traffic such as ftp/www. As I haven't seen this explained, and have seen no warnings for sysadmins, here goes: To do 'IP hijacking' (receive packets as well as send) you will need to modify routing tables all over the place, where you're not likely to have access. To do domain hijacking, you would need to modify DNS entries in several nameservers, to which again you're not likely to have privileged access. On the other hand, if you could associate an existing domain with a nameserver you _do_ control (root access on any machine connected to the Net is enough for this), your lack of access to the present nameservers would become irrelevant. So, 1. set up a nameserver on your machine, with address, cname or MX records as required for the victim domain address - victim.com. You can do fancy things with nslookup on victim.com's existing nameservers to find out what's required. Make sure the MX, address and cname records in your machine point to machines under your control. 2. send a modify domain mail to hostmaster(a)internic.net, with your machine as nameserver replacing any existing ones. The InterNIC has no authentication procedures for normal hostmaster requests, so your modification will get processed. 3. Ta DA! Wait for InterNIC to update its records and broadcast changes to other nameservers. From then on, a lookup for victim.com will go to ns.internic.net, find that ns.evil.org is the nameserver, and send all mail to @victim.com to victim.evil.org, route traffic to www.victim.com to www.evil.org, whatever you want. This is not a security risk? No. But, to quote a delightfully low-key document from InterNIC, "[such] an unauthorized update could lead a commercial organization to lose its presence on the Internet until that update is reversed." Ah. But that update will be reversed only when victim.com's sysadmins realise what's happened. If evil.org is clever enough, it will not halt the mail flow, but forward everything on to victim.com (after keeping a copy, of course). It could act as a proxy server to www.victim.com, accessing all URLs (using victim.com's real IP address) on demand and relaying them to browsers who are actually looking at www.evil.org. And so on. Unless victim.com's admins are particularly observant, they may not notice a thing. How many sysadmins out there do what victim.com could have done? I.e. run nslookup on victim.com regularly to check that the nameservers listed are as they should be, and if they're not, to immediately send a new update to InterNIC? Not many, I believe. On the other hand I know no case of domain hijacking actually taking place. But I don't know specific instances of WWW credit card fraud either. That delightful InterNIC document I mentioned is the draft paper on the InterNIC Guardian Object, first out in November 1995, latest version out earlier this month. It's an internal InterNIC proposal for a "Guardian Object" which would guard any other object (such as a domain name, or individual, or hostname, or even another guardian). It would allow a range of authentication methods, from none (very clever) and MAIL-FROM (easy to spoof) to CRYPT (1-way hash, like Unix passwd) and PGP (using public keys stored at InterNIC). All domain and other templates will be changed to work with guardians. The procedures in the original draft looked easy enough; the latest ones are formidable. Incidentally, this draft appeared two months after the InterNIC started charging. The wonders of the profit motive. Rishab ps. I'm not quite back on the Cypherpunks list yet, so please Cc responses you feel are important to me at rishab(a)dxm.org. pps. I quite forgot. The URL for the latest Guardian Object draft: ftp://rs.internic.net/policy/internic/internic-gen-1.txt

5 4

Re: Executing Encrypted Code
by ph＠netcom.com 17 Dec '03

17 Dec '03

At 7:43 AM 12/20/1996, Hal Finney wrote: >> The manufacturer is going to publish a list of ALL of the public keys? >> We're talking one key per chip, right? Isn't that an AWFUL lot of >> keys, like, in the millions range? > Probably an easier way would be for the chip manufacturer to issue a > key certificate (signature) on the chip keys. Then it is a trivial > matter for any software manufacturer to verify that a proferred chip > key is legit; just check the cert. Now why didn't I think of that! >>> One approach is for the manufacturer to authenticate software submitted >>> by approved vendors. The vendors are then tasked with encrypting it >>> for the correct processor. >> I'm not sure the "approved" bit would go over too well... one idea >> would be to license the compiler writers, who would build the >> encryption into compilers. It's still not horribly great, but >> better. > Hey, it's a free world, right? Some people only run authenticated > code from big companies; other people turn off the authentication > bit in the CPU and can run any old thing they stumble across on the net. > Everybody's happy. Maybe not everybody. My scheme would not let you turn off the authentication bit. That means that if somebody does find way to get at the secret key, they still can't run the code without doing something expensive with particular processors. Basically, this won't be worth the trouble. > The first group doesn't have to worry about viruses, > or at least they have somebody to sue if they see one, and the second > group gets to run all the freeware and PD code they can today. The second group would have to buy a different processor altogether, the way I proposed it. But, that does not seem unreasonable. One could even imagine systems which have a "free" processor and a decrypting processor. While they would have to have completely different instruction sets, they could be pin compatible. >> Right; the only reason I could see people using this would be for >> economical reasons. > Yes, I think this is a point often missed in these discussions. People > say, why would I want a CPU which will limit the software I can run, > something which will let a software maker give me a version of his > program which will only run on my CPU and which I have no ability to > share with others? What's in it for me? > The answer presumably is that the software manufacturer will sell software > with such limits for much less than he will sell unlimited software. That's > because software piracy is such a major problem, and this way he can be > protected against piracy from this copy of his program. So people with > these CPU's can buy their software a lot cheaper. I agree with all of this. Some people might be happier if they think of this as just another kind of agreement that people can make. Right now the software development agreement is weak because piracy is so easy. We rely a little bit on the law and a whole lot on the integrity of customers. Really, that isn't ideal. It would be nice if people could make strong agreements to write software. My judgement is that software piracy is less of a problem in the U.S. than it is elsewhere. My impression is that there are many other countries in the world where the whole "I should help pay for the development of this software because I am using it" idea just doesn't really show up on the screen. This processor would make it possible to sell software to the whole world without really worrying too much about how well each government enforces its laws or how ethical the people in foreign countries are. > Of course the big downside is that the track record of tamper resistant > hardware has not been too strong lately! If a system like this gets into > widespread use and somebody finds out that shooting X-rays at the chip > exposes its secret key, you've got a big problem. Processors are really only good for 3 years or so. The vendor is only betting that attacks won't become widespread in that time period. That is not a perfectly safe bet, but it isn't bad. The attacks can exist, but so long as they are expensive or hard to generalize to all processors, the software vendors are safe. Peter Hendrickson ph(a)netcom.com

1 0

Re: News & Truth
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

Jefferson: >At a very early period in my life I determined never to put a sentence into >any newspaper. I have religously adhered to the resolution through my life >and have great reason to be contented with it. Were I to undertake to answer >the calumnies of the newspapers it would be more than my time and twenty >aids could effect. For, while I should be answering one, twenty new ones >would be invented. I have thought it better to trust to the justice of my >countrymen that they would judge me by what they see of my conduct on the >stage where they have placed me. a friend of mine is studying Hamilton vs. Jefferson. it turns out Hamilton loved newspapers and would write frequently under his own name, or under a variety of pseudonyms. one biographer states he assumed the personality of each as he wrote under them. I think Jefferson was at ill advantage in the face of Hamilton's tactics. >No Government ought to be without censors; and when the press is free, no >one ever will. Nature has given to man no other means of sifting out the >truth either in religion, law or politics. I think it as honorable to the >government neither to know nor notice its sycophants or censors as it would >be undignified and criminal to pamper the former and persecute the latter. this is pretty hard to parse until one understands that an old form of the word "censor", as I understand it, meant "to criticize". so "censor" as a noun and verb should be replaced with "critic" and "criticize" for the modern translation.

1 0

Re: Security First Network Bank, FSB. The World's 1st Internet
by David Neal 17 Dec '03

17 Dec '03

> Date: Thu, 25 Jan 1996 17:50:16 -0500 > To: cypherpunks(a)toad.com > From: "Joseph M. Reagle Jr." <reagle(a)rpcp.mit.edu> > Subject: Security First Network Bank, FSB. The World's 1st Internet Bank > Just got something in the post today asking for me to set up an account with > them... > > - Daily reconciled bank statement and checkbook register; All transactions are > logged for you. - No min balance - 20 free electronic bill payments per > month... - ATM at Honor and Cirus.. - 200 free paper checks... - plenty of > pre-stamped deposit envolopes - FDIC insured accounts (in case anyone ever > steals my password..) - Wired Funds.. > Mis-features - Uses Public key crypto but web pages do not mention PGP, says keys may come in mail on floppy; how to fingerprint key? - Online only based system Drawbacks include system downtime means being unable to access your 'checkbook' No extraction features for those of us who use true double entry accounting systems, much less Quicken or even spreadsheets. - Bill paying system Four day lead on bills to be paid (can you say float?) Laser-printed statement sent to payee for 'verfication' will be subject to payees security restrictions which may consist of tossing it unshredded into the trash. - No chaum-like digital money provisions. Although it is a step in the right direction, I won't be happy until the bank accepts e-mail directives for generating chaumian cash or instant EFT payments via messages encrypted against PGP keys. Lets face it FINCEN already knows all about your income sources if they are at all bank based (i.e. excluding barter and cash), but at least I can have my check EFT'd, encrypt a PGP transaction to send all my money to Seychelles, and pay bills from that Offshore bank that really does respect my privacy. This would at least make discerning that my foley's bill is $120 a month more difficult since FINCEN would now have to have cooperation from the payee.

1 0

Re: Websites and trademarks at odds [CNN]
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

the article states that it is difficult for consumers to find companies when trademarks are not equivalent to web site addresses. solution: a "trademark directory" web page-- say, www.trademark.com. it gives the official web site of all companies in the world. yahoo is close to this but not quite. an opportunity for a budding entrepreneur. it would clearly be a very high-traffic site, ripe with advertising possibilities. added benefit: it might cut down on the animosity going on over web site addresses, "poaching", and lawsuits over ownership.

1 0