December 2003 - cypherpunks-legacy

Re: another possible remailer attack
by anonymous＠miron.vip.best.com 17 Dec '03

17 Dec '03

Steve Reid writes: > > >> You want to know if Dimitri is the person regularly posting these > >> messages. So, you use your powers as ISP to block his access to all > >> remailers. If the public messages suddenly stop then you can be > >> reasonably certain that Dimitri was sending them. > > I'm not following something...just how to your "powers as ISP" affect a > > remailer in, say, Holland, or one for that matter on another ISP? (As a > > Packet filtering at the ISP's router. If Dimitri can't connect to a > remailer, he can't send anonymous messages. Sure there are a lot of hacks > that could be done (like have sendmail on another system send it to a > remailer) but such things could be detected and blocked by clever filters. I disagree, it's easy to bounce mail through ANY Internet-connected host running sendmail and thence to a remailer. In fact this mail was sent that way, I bounced it through sun.com before hitting a remailer. > In fact, the ISP could just claim to be "going down for maintenance" and > completely block Dimitri from the internet for a while. Only if the Backbone Cabal (there is no Cabal) is re-formed (and given special SuperPowers!) with the sole purpose of blocking Dimitri from posting to cypherpunks. > > Just as the Nazis could isolate spy transmitters by selectively > > turning off electricity to different neigborhoods, so, too, can various > > Isolating spy transmitters by selectively cutting power is exactly > alalogous to what I have suggested. The spy transmitters couldn't bounce their transmissions off of regular radio transmissions, could they? Buck Satan

2 1

Re: Why is cryptoanarchy irreversible?
by Sean Roach 17 Dec '03

17 Dec '03

>At 12:58 AM 11/8/1996, stewarts(a)ix.netcom.com wrote: >> Strong vs. weak crypto isn't the real issue - for most business use, >> weak crypto is obviously unacceptable, but strong crypto with GAK >> is ok as long as it doesn't interfere with use (and as long as the >> government bureaucrats don't sell too many keys.) To which, at 09:02 AM 11/8/96 -0800, Peter Hendrickson wrote: >We often say that the government is a security weak point and that >this makes GAK impractical. However, this is not true. If the >holders of the government keys were individually responsible for >their release, they would not be released very often. That is, >in order to use cryptography you must purchase an expensive >encryption license. That pays the salary of a certified "key >escrow agent" who is the only person who can decrypt your messages. >What stops him from revealing your keys to unauthorized parties? >It's his business. If that's not enough, you back it up with >criminal penalties for disclosure. And, hiring this person is >no different from hiring an employee for your company. > >There are already similar activities. Lawyers are nominally employees >of the state. Employees of Swiss banks can go to jail for violating >their secrecy laws. Then there is the meat-packing inspectors, I don't know if this should give piece of mind or instill new fear. The inspectors were put in there because the meat was rancid, the thing is, some of it still is if you listen to the critics. A partial fix at least. >At 12:58 AM 11/8/1996, stewarts(a)ix.netcom.com wrote: >> The government might be able to stop new Netscape versions from >> using strong crypto - threatening to confiscate the company's >> ill-gotten gains from aiding and abetting money launderers might help, >> and threatening to confiscate PCs that use unapproved crypto. >> But it's tough to use a widespread threat like that on popular >> software once it's out there. To which, at 09:02 AM 11/8/96 -0800, Peter Hendrickson wrote: >I agree, if the software is popular. But, if the fears of the GAKers >and the dreams of certain cypherpunks are real, such software will >not be popular. Another point is, if the government attacks Netscape for their strong crypto(which is pretty hard to get, I'm in Oklahoma and I couldn't get it because some server didn't know for sure that my server was in the United States or Canada), someone will probabally make an in-line plug-in for encrypted data, and this plug-in may affect more of the browser than the existing system, making it more dangerous to the governments schemes. Anyone know where the data is stored on how to write for Netscape?

2 1

Re: Why is cryptoanarchy irreversible?
by Sean Roach 17 Dec '03

17 Dec '03

At 09:02 AM 11/8/96 -0800, Peter Hendrickson wrote: >At 12:29 AM 11/8/1996, Jim McCoy wrote: >>Peter Hendrickson writes: >>[...] >>>> Get a warrant, search my system, find nothing but a bunch of applications >>>> and a collection of risque (but definitely legal) pictures which I exchange >>>> with a few friends. You may suspect that when the images are concatenated >>>> in a particular way the low-order bits form a stego filesystem but no one >>>> will be able to prove it in court. > >>> Are you concatenating these images by hand? If so, the level of entropy >>> is probably low enough to recover the information through brute force >>> methods or you are hiding a very small amount of information. > >> I hide the relatively small amount of data within a very large amount of >> data which makes it impossible to find. Data from analog sources, like >> the "real world" (images, sounds, etc) is noisy. This is a fact of life. >> Because this data is noisy I can hide information in the noise. As long >> as the information I am hiding maintains the same statistical properties >> of noise it is impossible to pull the information out of the data file unless >> you have the key. If I am paranoid enough I can make this key impossible >> to discover without a breakthrough in factoring. > >Where will you keep your secret key? Remember, when they go through your >house they bring 20 young graduates from MIT who are just dying to show >how clever they are and save the world at the same time. > >> This is the essence of steganography and the nature of signal and noise are >> fundemental principles of information theory. > >The concept of noise is not all that well defined, however. There is no >way to look at a signal and say "this is all noise." Sometimes physical >theories may lead you to believe that it is all noise. That is fine >for many applications, but when becomes less convinced of things if >the consequences are severe. > >>> If you are not doing it by hand, you own terrorist software and will pay >>> the price. > >> Ah yes, terrorist programs like cat and perl and operating systems like >> Linux which contain a loopback filesystem that I can hook a perl >> interpreter into at compile-time (which is enough for me to rewrite the >> program from scratch each time if necessary, unless things like math >> libraries are also outlawed on computers :) I think that the crypto >> concentration camps are going to be very crowded places. > >Can you elaborate on this? I am curious to know exactly what you are going >to keep in your head and what goes on the disk. Please post the Perl >code that you would type in from scratch every time. (Most of the message left for clarity) I would type dungeon at the prompt and Ctrl-Alt-6 at the first door. But that's just me. BTW. The hypothetical Steno program (Trojan Horse) that I wrote about earlier (and that this refers) could have its own source hidden in the opening screen of both the game and the bmp that I would use for my windows background. If anyone has access to the source of a soon to be released game, they could add this to it as an easter egg, thus, the author would be spreading a very powerful tool which would be advertized several months after it was released. If it were added to a program with references to cypherpunks or similar, it might even reach the (primary) target audience.

2 1

Why Cryptography is Harder than it Looks (LONG)
by Bruce Schneier 17 Dec '03

17 Dec '03

WHY CRYPTOGRAPHY IS HARDER THAN IT LOOKS Bruce Schneier, Counterpane Systems ................................................................................ Copyright Nov 1996 by Bruce Schneier. All rights reserved. Permission is given to distribute this essay, providing that it is distributed in its entirety (including this copyright notice). For more information on Counterpane Systems's cryptography and security consulting, see http://www.counterpane.com. ................................................................................ >From e-mail to cellular communications, from secure Web access to digital cash, cryptography is an essential part of today's information systems. Cryptography helps provide accountability, fairness, accuracy, and confidentiality. It can prevent fraud in electronic commerce and assure the validity of financial transactions. It can prove your identity or protect your anonymity. It can keep vandals from altering your Web page and prevent industrial competitors from reading your confidential documents. And in the future, as commerce and communications continue to move to computer networks, cryptography will become more and more vital. But the cryptography now on the market doesn't provide the level of security it advertises. Most systems are not designed and implemented in concert with cryptographers, but by engineers who thought of cryptography as just another component. It's not. You can't make systems secure by tacking on cryptography as an afterthought. You have to know what you are doing every step of the way, from conception through installation. Billions of dollars are spent on computer security, and most of it is wasted on insecure products. After all, weak cryptography looks the same on the shelf as strong cryptography. Two e-mail encryption products may have almost the same user interface, yet one is secure while the other permits eavesdropping. A comparison chart may suggest that two programs have similar features, although one has gaping security holes that the other doesn't. An experienced cryptographer can tell the difference. So can a thief. Present-day computer security is a house of cards; it may stand for now, but it can't last. Many insecure products have not yet been broken because they are still in their infancy. But when these products are widely used, they will become tempting targets for criminals. The press will publicize the attacks, undermining public confidence in these systems. Ultimately, products will win or lose in the marketplace depending on the strength of their security. THREATS TO COMPUTER SYSTEMS Every form of commerce ever invented has been subject to fraud, from rigged scales in a farmers' market to counterfeit currency to phony invoices. Electronic commerce schemes will also face fraud, through forgery, misrepresentation, denial of service, and cheating. In fact, computerization makes the risks even greater, by allowing attacks that are impossible against non-automated systems. A thief can make a living skimming a penny from every Visa cardholder. You can't walk the streets wearing a mask of someone else's face, but in the digital world it is easy to impersonate others. Only strong cryptography can protect against these attacks. Privacy violations are another threat. Some attacks on privacy are targeted: a member of the press tries to read a public figure's e-mail, or a company tries to intercept a competitor's communications. Others are broad data-harvesting attacks, searching a sea of data for interesting information: a list of rich widows, AZT users, or people who view a particular Web page. Electronic vandalism is an increasingly serious problem. Computer vandals have already graffitied the CIA's web page, mail-bombed Internet providers, and canceled thousands of newsgroup messages. And of course, vandals and thieves routinely break into networked computer systems. When security safeguards aren't adequate, trespassers run little risk of getting caught. Attackers don't follow rules; they cheat. They can attack a system using techniques the designers never thought of. Art thieves have burgled homes by cutting through the walls with a chain saw. Home security systems, no matter how expensive and sophisticated, won't stand a chance against this attack. Computer thieves come through the walls too. They steal technical data, bribe insiders, modify software, and collude. They take advantage of technologies newer than the system, and even invent new mathematics to attack the system with. The odds favor the attacker. Bad guys have more to gain by examining a system than good guys. Defenders have to protect against every possible vulnerability, but an attacker only has to find one security flaw to compromise the whole system. WHAT CRYPTOGRAPHY CAN AND CAN'T DO No one can guarantee 100% security. But we can work toward 100% risk acceptance. Fraud exists in current commerce systems: cash can be counterfeited, checks altered, credit card numbers stolen. Yet these systems are still successful because the benefits and conveniences outweigh the losses. Privacy systems -- wall safes, door locks, curtains -- are not perfect, but they're often good enough. A good cryptographic system strikes a balance between what is possible and what is acceptable. Strong cryptography can withstand targeted attacks up to a point -- the point at which it becomes easier to get the information some other way. A computer encryption program, no matter how good, will not prevent an attacker from going through someone's garbage. But it can prevent data-harvesting attacks absolutely; no attacker can go through enough trash to find every AZT user in the country. And it can protect communications against non-invasive attacks: it's one thing to tap a phone line from the safety of the telephone central office, but quite another to break into someone's house to install a bug. The good news about cryptography is that we already have the algorithms and protocols we need to secure our systems. The bad news is that that was the easy part; implementing the protocols successfully requires considerable expertise. The areas of security that interact with people -- key management, human/computer interface security, access control -- often defy analysis. And the disciplines of public-key infrastructure, software security, computer security, network security, and tamper-resistant hardware design are very poorly understood. Companies often get the easy part wrong, and implement insecure algorithms and protocols. But even so, practical cryptography is rarely broken through the mathematics; other parts of systems are much easier to break. The best protocol ever invented can fall to an easy attack if no one pays attention to the more complex and subtle implementation issues. Netscape's security fell to a bug in the random-number generator. Flaws can be anywhere: the threat model, the system design, the software or hardware implementation, the system management. Security is a chain, and a single weak link can break the entire system. Fatal bugs may be far removed from the security portion of the software; a design decision that has nothing to do with security can nonetheless create a security flaw. Once you find a security flaw, you can fix it. But finding the flaws in a product can be incredibly difficult. Security is different from any other design requirement, because functionality does not equal quality. If a word processor prints successfully, you know that the print function works. Security is different; just because a safe recognizes the correct combination does not mean that its contents are secure from a safecracker. No amount of general beta testing will reveal a security flaw, and there's no test possible that can prove the absence of flaws. THREAT MODELS A good design starts with a threat model: what the system is designed to protect, from whom, and for how long. The threat model must take the entire system into account -- not just the data to be protected, but the people who will use the system and how they will use it. What motivates the attackers? Must attacks be prevented, or can they just be detected? If the worst happens and one of the fundamental security assumptions of a system is broken, what kind of disaster recovery is possible? The answers to these questions can't be standardized; they're different for every system. Too often, designers don't take the time to build accurate threat models or analyze the real risks. Threat models allow both product designers and consumers to determine what security measures they need. Does it makes sense to encrypt your hard drive if you don't put your files in a safe? How can someone inside the company defraud the commerce system? How much would it cost to defeat the tamper-resistance on the smart card? You can't design a secure system unless you understand what it has to be secure against. SYSTEM DESIGN Design work is the mainstay of the science of cryptography, and it is very specialized. Cryptography blends several areas of mathematics: number theory, complexity theory, information theory, probability theory, abstract algebra, and formal analysis, among others. Few can do the science properly, and a little knowledge is a dangerous thing: inexperienced cryptographers almost always design flawed systems. Good cryptographers know that nothing substitutes for extensive peer review and years of analysis. Quality systems use published and well-understood algorithms and protocols; using unpublished or unproven elements in a design is risky at best. Cryptographic system design is also an art. A designer must strike a balance between security and accessibility, anonymity and accountability, privacy and availability. Science alone cannot prove security; only experience, and the intuition born of experience, can help the cryptographer design secure systems and find flaws in existing designs. IMPLEMENTATION There is an enormous difference between a mathematical algorithm and its concrete implementation in hardware or software. Cryptographic system designs are fragile. Just because a protocol is logically secure doesn't mean it will stay secure when a designer starts defining message structures and passing bits around. Close isn't close enough; these systems must be implemented exactly, perfectly, or they will fail. A poorly-designed user interface can make a hard-drive encryption program completely insecure. A false reliance on tamper-resistant hardware can render an electronic commerce system all but useless. Since these mistakes aren't apparent in testing, they end up in finished products. Many flaws in implementation cannot be studied in the scientific literature because they are not technically interesting. That's why they crop up in product after product. Under pressure from budgets and deadlines, implementers use bad random-number generators, don't check properly for error conditions, and leave secret information in swap files. The only way to learn how to prevent these flaws is to make and break systems, again and again. CRYPTOGRAPHY FOR PEOPLE In the end, many security systems are broken by the people who use them. Most fraud against commerce systems is perpetrated by insiders. Honest users cause problems because they usually don't care about security. They want simplicity, convenience, and compatibility with existing (insecure) systems. They choose bad passwords, write them down, give friends and relatives their private keys, leave computers logged in, and so on. It's hard to sell door locks to people who don't want to be bothered with keys. A well-designed system must take people into account. Often the hardest part of cryptography is getting people to use it. It's hard to convince consumers that their financial privacy is important when they are willing to leave a detailed purchase record in exchange for one thousandth of a free trip to Hawaii. It's hard to build a system that provides strong authentication on top of systems that can be penetrated by knowing someone's mother's maiden name. Security is routinely bypassed by store clerks, senior executives, and anyone else who just needs to get the job done. Only when cryptography is designed with careful consideration of users' needs and then smoothly integrated, can it protect their systems, resources, and data. THE STATE OF SECURITY Right now, users have no good way of comparing secure systems. Computer magazines compare security products by listing their features, not by evaluating their security. Marketing literature makes claims that are just not true; a competing product that is more secure and more expensive will only fare worse in the market. People rely on the government to look out for their safety and security in areas where they lack the knowledge to make evaluations -- food packaging, aviation, medicine. But for cryptography, the U.S. government is doing just the opposite. When an airplane crashes, there are inquiries, analyses, and reports. Information is widely disseminated, and everyone learns from the failure. You can read a complete record of airline accidents from the beginning of commercial aviation. When a bank's electronic commerce system is breached and defrauded, it's usually covered up. If it does make the newspapers, details are omitted. No one analyzes the attack; no one learns from the mistake. The bank tries to patch things in secret, hoping that the public won't lose confidence in a system that deserves no confidence. In the long run, secrecy paves the way for more serious breaches. Laws are no substitute for engineering. The U.S. cellular phone industry has lobbied for protective laws, instead of spending the money to fix what should have been designed corectly the first time. It's no longer good enough to install security patches in response to attacks. Computer systems move too quickly; a security flaw can be described on the Internet and exploited by thousands. Today's systems must anticipate future attacks. Any comprehensive system -- whether for authenticated communications, secure data storage, or electronic commerce -- is likely to remain in use for five years or more. It must be able to withstand the future: smarter attackers, more computational power, and greater incentives to subvert a widespread system. There won't be time to upgrade them in the field. History has taught us: never underestimate the amount of money, time, and effort someone will expend to thwart a security system. It's always better to assume the worst. Assume your adversaries are better than they are. Assume science and technology will soon be able to do things they cannot yet. Give yourself a margin for error. Give yourself more security than you need today. When the unexpected happens, you'll be glad you did. ****************************************************************************** Bruce Schneier schneier(a)counterpane.com http://www.counterpane.com ******************************************************************************

2 1

Re: Federal Reserve Bank is ILLEGAL? [BOB DYLAN]
by Rich Graves 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- On Mon, 11 Nov 1996, Doug Renner wrote: > http://feustel.mixi.net/GOV/DEPTS/fedres.html > > Most list members would be very interested in the above link. Indeed. It's hilarious, especially the References section. Thanks! I think maybe you should take a look at the Noontide Press catalog. - -rich ObCopyrightViolation (not really on-topic, because Carto and Pierce were kicked out of the Birch Society, but it's funnier than, for example, <http://www.c2.net/~rich/nab9608-1.gif>): TALKIN' JOHN BIRCH PARANOID BLUES (Words and Music by Bob Dylan) 1970, 1973 Special Rider Music Well, I was feelin' sad and feelin' blue, I didn't know what in the world I was gonna do, Them Communists they wus comin' around, They wus in the air, They wus on the ground. They wouldn't gimme no peace. . . So I run down most hurriedly And joined up with the John Birch Society, I got me a secret membership card And started off a-walkin' down the road. Yee-hoo, I'm a real John Bircher now! Look out you Commies! Now we all agree with Hitlers' views, Although he killed six million Jews. It don't matter too much that he was a Fascist, At least you can't say he was a Communist! That's to say like if you got a cold you take a shot of malaria. Well, I wus lookin' everywhere for them gol-darned Reds. I got up in the mornin' 'n' looked under my bed, Looked in the sink, behind the door, Looked in the glove compartment of my car. Couldn't find 'em . . . I wus lookin' high an' low for them Reds everywhere, I wus lookin' in the sink an' underneath the chair. I looked way up my chimney hole, I even looked deep inside my toilet bowl. They got away . . . Well, I wus sittin' home alone an' started to sweat, Figured they wus in my T.V. set. Peeked behind the picture frame, Got a shock from my feet, hittin' right up in the brain. Them Reds caused it! I know they did . . . them hard-core ones. Well, I quit my job so I could work alone, Then I changed my name to Sherlock Holmes. Followed some clues from my detective bag And discovered they wus red stripes on the American flag! That ol' Betty Ross . . . Well, I investigated all the books in the library, Ninety percent of 'em gotta be burned away. I investigated all the people that I knowed, Ninety-eight percent of them gotta go. The other two percent are fellow Birchers . . . just like me. Now Eisenhower, he's a Russian spy, Lincoln, Jefferson and that Roosevelt guy. To my knowledge there's just one man That's really a true American: George Lincoln Rockwell. I know for a fact he hates Commies cus he picketed the movie Exodus. Well, I fin'ly started thinkin' straight When I run outa things to investigate. Couldn't imagine doin' anything else, So now I'm sittin' home investigatin' myself! Hope I don't find out anything . . . hmm, great God! -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBMofAP5NcNyVVy0jxAQEWUwH/VBpVAQeLio6vvqk4+Wku+y2zSETIqat8 KQso3BxkgV8mC3wiD7oC4YdJTnGIFnh5Zutt6po0wF/URkpda7zBcA== =r6Fl -----END PGP SIGNATURE-----

2 1

Re: His and Her Anarchies
by Dale Thorn 17 Dec '03

17 Dec '03

jbugden(a)smtplink.alis.ca wrote: > "Timothy C. May" <tcmay(a)got.net> wrote: > >Well, I think there clearly _is_ a gender gap on these sorts of issues. > Technologies that matter make daily life less obnoxious, and you can leverage > them all the time. The Net is going to start mattering in a significant way when > it relieves people of the burden of dealing with the garbage inherent in the > information flow of everyday life. The net is going to matter when I can rely on > it to store the information I now keep on disk, and the computer is a completely > transparent object. All the documents that are important to me are maintained by > the Net with sufficient reliability that I can unplug my computer and smash it > with a hammer without affecting anything. > Under this scenario, strong, reliable crypto becomes similar to electricity. The > entire infomration infrastructure is built on it, but hardly anyone gives it a > second thought. > What kind of people use the Net and what are their activities doing to the > country, the world, the culture? It may sound like a parochial issue that women > don't much like computers, but they don't, and the issue is a tremendously > important one. They're not attracted to this world, certainly not to the extent > that men are, and that's one of the reasons why it is such a spiritually > impoverished world. Most reasonable sophisticated men are happier in an > environment that included women. One of the problems with the computer society > is that not only is it an almost all-male society, but it's part of a little-boy > society, part of an ongoing infantilization of the society over the past half > century. Most heterosexual men claim to like women, but the claim is dubious on the part of a large percentage of men, since they really like to mostly do "boy things", i.e., follow sports, ride motorcycles, listen to "boy music", etc., rather than hang out with women as just friends. I think if people were really honest, they'd admit that, by and large, men like men and women like women. Simple enough, eh?

1 0

Re: WebTV a "munition"
by Pablo Calamera 17 Dec '03

17 Dec '03

>>Date: Fri, 08 Nov 1996 17:16:00 -0800 >>From: Tom Weinstein <tomw(a)netscape.com> >>Organization: Netscape Communications, Inc. >>MIME-Version: 1.0 >>To: cypherpunks(a)toad.com >>Subject: Re: WebTV a "munition" >>Sender: owner-cypherpunks(a)toad.com >>Precedence: bulk >> >>Rich Graves wrote: >>> >>> Eric Murray wrote: >>> > >>> > Page 3 of the San Jose Mercury News has a small blurb >>> > about WebTV's browser/set-top box that "uses >>> > computer-security technology so powerful that the >>> > government is classifying it as a weapon >>> > that will require a special export license before >>> > it can be sold overseas".[...] >>> > shouldn't be too difficult. If they didn't use the "export" >>> > level SSL CipherTypes, then what're they up to? Are they >>> > fighting crypto export laws (for which they should be congratulated >>> > and supported) or are they just looking for free publicity? >>> >>> Based on the lack of public policy pronouncements from the WebTV >>> folks, I would answer C) They're clueless. I'm not sure that >>> management even understood, or wanted to understand, that they'd have >>> an export problem. >>> See http://www.webtv.net/ >> >>Since Pablo Calamera works there, they can't be too clueless. >> >>-- >>You should only break rules of style if you can | Tom Weinstein >>coherently explain what you gain by so doing. | tomw(a)netscape.com >> To clarify a bit, we're not talking about SSL here. Also, some how it was infered by some readers of the article that we were astonished about the munitions classification of our product. We were not. Oh... and yes, we are not the least bit clueless (thanks Tom). Below is a company statement we released: The WebTV Network is currently using a 128 bit encryption system that gives our U.S. subscribers the most sophisticated security protection of any online service today. It is our intent to offer our customers the most secure environment for transactions and transmission with their WebTV Network service. Our units, sold by Sony and Philips, include a sticker that states that the product is not to be exported outside of the United States. However, the government restriction does not prevent us from exporting our product outside of the United States. WebTV Networks has always intended to announce its expansion plans in early 1997, providing global communication using either 40 bits, now authorized by the government, or 56 bits which Bill Clinton recently endorsed. Pablo ----------------------------------------- | Pablo Calamera | Security Architect | WebTV Networks, Inc. http://webtv.net/ | 305 Lytton Avenue | Palo Alto, CA 94301 | . . . . . . . . . . . . . . . . . . . . | mailto:pablo@corp.webtv.net | voice:(415) 614-2749 -----------------------------------------

2 1

two bogus messages to this list
by ichudov＠algebra.com 17 Dec '03

17 Dec '03

I did not write the two messages below. I did have a small party yesterday, probably some of my guests did that... - Igor. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ >From cypherpunks-errors(a)toad.com Mon Nov 11 06:35:19 1996 Return-Path: <cypherpunks-errors(a)toad.com> Received: (from root@localhost) by manifold.algebra.com (8.8.2/8.8.2) with UUCP id GAA16814 for ichudov(a)algebra.com; Mon, 11 Nov 1996 06:34:44 -0600 Received: from toad.com (toad.com [140.174.2.1]) by www.video-collage.com (8.8.0/8.8.0) with ESMTP id CAA20037 for <ichudov(a)algebra.com>; Mon, 11 Nov 1996 02:34:30 -0500 (EST) Received: (from majordom@localhost) by toad.com (8.7.5/8.7.3) id VAA01399 for cypherpunks-outgoing; Sun, 10 Nov 1996 21:49:52 -0800 (PST) Received: from www.video-collage.com (www.video-collage.com [199.232.240.107]) by toad.com (8.7.5/8.7.3) with ESMTP id VAA01394 for <cypherpunks(a)toad.com>; Sun, 10 Nov 1996 21:49:47 -0800 (PST) Received: (from uucp@localhost) by www.video-collage.com (8.8.0/8.8.0) with UUCP id AAA19874 for cypherpunks(a)toad.com; Mon, 11 Nov 1996 00:51:53 -0500 (EST) Received: (from ichudov@localhost) by manifold.algebra.com (8.8.2/8.8.2) id XAA15989 for cypherpunks(a)toad.com; Sun, 10 Nov 1996 23:47:00 -0600 Date: Sun, 10 Nov 1996 23:47:00 -0600 From: "Igor Chudov @ home" <ichudov(a)algebra.com> Message-Id: <199611110547.XAA15989(a)manifold.algebra.com> Subject: FUCK ME HARD Sender: owner-cypherpunks(a)toad.com Precedence: bulk Status: O FUCK NME HARD >From cypherpunks-errors(a)toad.com Mon Nov 11 00:35:29 1996 Return-Path: <cypherpunks-errors(a)toad.com> Received: (from root@localhost) by manifold.algebra.com (8.8.2/8.8.2) with UUCP id AAA16188 for ichudov(a)algebra.com; Mon, 11 Nov 1996 00:35:24 -0600 Received: from toad.com (toad.com [140.174.2.1]) by www.video-collage.com (8.8.0/8.8.0) with ESMTP id BAA19940 for <ichudov(a)algebra.com>; Mon, 11 Nov 1996 01:37:38 -0500 (EST) Received: (from majordom@localhost) by toad.com (8.7.5/8.7.3) id VAA00961 for cypherpunks-outgoing; Sun, 10 Nov 1996 21:03:06 -0800 (PST) Received: from www.video-collage.com (www.video-collage.com [199.232.240.107]) by toad.com (8.7.5/8.7.3) with ESMTP id VAA00956 for <cypherpunks(a)toad.com>; Sun, 10 Nov 1996 21:03:03 -0800 (PST) Received: (from uucp@localhost) by www.video-collage.com (8.8.0/8.8.0) with UUCP id AAA19793 for cypherpunks(a)toad.com; Mon, 11 Nov 1996 00:05:09 -0500 (EST) Received: (from ichudov@localhost) by manifold.algebra.com (8.8.2/8.8.2) id WAA15563 for cypherpunks(a)toad.com; Sun, 10 Nov 1996 22:36:03 -0600 Date: Sun, 10 Nov 1996 22:36:03 -0600 From: "Igor Chudov @ home" <ichudov(a)algebra.com> Message-Id: <199611110436.WAA15563(a)manifold.algebra.com> Sender: owner-cypherpunks(a)toad.com Precedence: bulk Status: RO manifold::~==>premail -t cypherpunks(a)toad.com Chain: haystack;jam Subject: I urgently need a lot of money. Please share your money-making secrets, I am in a desperate need for cash.

5 5

Re: Rarity: Crypto question enclosed
by David K. Merriman 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: mianigand(a)outlook.net, cypherpunks(a)toad.com Date: Mon Nov 11 12:31:25 1996 > > My simple question is regarding key/certificate distribution: > > > > Is there any particular reason that such can't be > accomplished via > > on-line lists, and made available via a service on a port, using > standard > > (textual) commands, like mail and such are now? > > It's possible to have a key-server listen on a port and accept > requests, then it would > fork a process, process the result, and return an answer set. > > But how many CPU cycles would it take for a machine to process a > request, ie going through > 1000 of keys? I am not exactly sure, it took a long while on my > pentium. > > In my opinion, if I were to run a key server as a service, with > clients connecting and requesting a key > it shouldn't take more than a minute to get a responce. > Agreed - a proper search algorithm should yield an answer in a few seconds, at most. > > The things that come to mind are a 'client' request for a > key, a > > 'client' submission of a key, an external host requesting a key > exchange, > > and the host itself requesting a key exchange with another system > (only > > new/changed keys being swapped). > > Had the exact same idea, but came up with an interesting concept. When > a person submits a key, a PGP process is spawned yeilding the > following information 1.) The name (peponmc(a)cris.com) 2.) The real > name (Michael Peponis) 3.) The key size 4.) Creation date of the key > 5.) Key finger print > > This information, along with the acutal key would be inserted into a > SQL Database table > > With a structure similar to this ... <deletia> ... The reason I brought the idea up here was in the hope that others on the CP list could help work out the fussy details of the protocol: what info would need to be included for what types of exchanges, what port(s) would be good to work with, etc. Platform/implementation would be subject to considerable variation - but the idea would survive (hopefully :-) > > It's not that hard, it's performance that's more of an issue. The > beauty of my approch would be that initially, there would be alot of > "Add" requests, resulting in many PGP processes running on the box, > but eventually, they would tapper off. Again, implementation on any particular platform using any particular OS would be up to the afficionados of said platforms/OS's. I'm more interested in the CP list coming up with the protocol/standards. Dave -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMoasIsVrTvyYOzAZAQEkTAP+JQtMdr5x+Wz4s6SXchgA4ow3+P9WLpzs JpjXRbNeHspJ2btlAe4pSgRqSp9oygqJ6Nxpa6DFOC4uB6sl3NaOw8tzcVVJm8GN +QsGP3KBoeTtRh1xE5yUsFoWmGWSqtDLLhu7bU34TaryLBU/Hvj2mOQXqwXhQlvE FhE5VETJJ2o= =LG7t -----END PGP SIGNATURE-----

2 1

ENT_ice
by John Young 17 Dec '03

17 Dec '03

11-11-96. WaPo Page One: "Preventing Terrorism: Where to Draw the Line? With Militias, U.S. Adopts Preemptive Strategy" This strategy requires aggressive and potentially controversial tactics as investigators infiltrate groups and bring charges on the basis of allegedly criminal plans that are conceived but not carried out. Federal agencies are more willing to launch investigations when people talk about committing violent acts, and investigators are more prone to use ordinary citizens as informants. According to legal experts, the mere discussion of a crime, no matter how fanciful it may be, can constitute a criminal conspiracy. "The classic example is that you are guilty of a crime if you conspire with someone else to stick pins in a voodoo doll in the belief that your enemy will fall dead," said Albert Alschuler, a law professor at the University of Chicago. ----- http://jya.com/entice.txt (13 kb) ENT_ice

5 4