December 2003 - cypherpunks-legacy

Re: (Fwd) Gov't run anon servers
by Hal 17 Dec '03

17 Dec '03

From: mccoy(a)communities.com (Jim McCoy) > > Hal Finney writes: > [...] > > And even then the information is in memory. An attacker who could > >gain root privileges (and let's not pretend that the NSA can't do that) > >can dump memory and later comb it for the key information. > > > > "Security is economics" -E. Hughes > > The point is not to make a system which is absolutely, positively, no > doubt about it, secure against any attacker. If cypherpunks could do > this they would be working for defense contractors and others who make > certified systems. The objective is to make a system which is difficult > to attack, one which costs the attacker time/money. After securing > a host against the obvious attacks one can turn to the esoteric ones > such as you present: move the key to kernel memory and remove tools > for accessing or manipulating that area, run the memory-space encrypted > and do not let it dump the contents to disk, etc. Systems which > have been certified to high Orange book levels already exist, so there > are obviously solutions to the problems you present. The tools and > tricks of these systems just need to be migrated into systems which > people actually use. I was speaking of present conditions. If and when proven-secure Unix systems start being used as remailer servers on the net then it may be worthwhile having a larger key. The point is that there is no advantage in strengthening an element of the system which is not its weakest link. Factoring my remailer keys of 510 bits is not, I am sure, the easiest ways of finding the secret keys. > Then remember that remailers gain strength in numbers. The more > remailers you chain your message through the better your chances of > passing through a single node which is not compromised, at which > point your message has been "mixed." As long as it is easier for > someone to create new remailers than to break existing remailers > we are winning. It's not clear that this is the case, though, is it? What is the rate of creation of new remailers? It doesn't seem that high to me. We can't know how quickly they are being broken, but it is just a matter of getting root privileges on the remailer machine. From what I hear of the capabilities of experienced hacker/cracker types, it is very possible that remailers are being broken faster than they are being created. Of course, there is no way to know. > >My point remains that strong keys are pointless for remailers which run > >on Unix systems connected to the net. > > "Insisting on perfect security is for people who do not have the > balls to live in the real world" -paraphrased from M. Shaefer > > You give far too much credit to the potential attackers. One advantage > that unix systems connected to the net have over your hypothetical > PC at home is the advantage of persistence, what is the point of > running a remailer if it is never up, or only up when you need to use > it? Traffic analysis of that particular node becomes a pretty easy > task :) I meant that the home PC system would have an ongoing connection to the net, perhaps in the form of periodic uucp or POP connections. By using batching, traffic analysis would be no easier for such a system than for any other. > The unix hosts running remailers also have the advantage in > that they have been subjected to attack for quite a while now and > most of the obvious problems (and some of the non-obvious problems) > have been fixed. I am not sure what you mean by this. My experience is that new CERT advisories come out every few months which represent security holes big enough to steal remailer keys. The most recent one, out just a couple of weeks ago, is a bug in sendmail and maybe some other programs which could allow remote users to get root access if they have access to a DNS server: ftp://cert.org/pub/cert_advisories/CA-96.04.corrupt_info_from_servers Even if a remailer host operator is on the ball and fixes each one as it is announced, he still was vulnerable before the announcement was made. In many cases these bugs are found by hackers who exploit them for bad purposes before the good guys figure out what they are doing. Suppose a reasonably large prize of several hundred or a few thousand dollars were offered for someone who could break in and steal the key of some remailer on a net-connected Unix system. Wouldn't you agree that the prize would be claimed before too long? > A strong key on such a host is better than a weak key, so why not > make systems as strong as you can? The only way to have a completely > secure computer is to encase it in concrete, cut any network connections, > and drop it into the ocean; OTOH the only thing you have created in this > case is a fairly unique boat anchor. You are beginning to sound like > the people who claim that the NSA can crack any encryption system, not > because they have any proof but just because they extrapolate their > limited knowledge into the unknown and mix in a bit of paranoia. No, my point is that it doesn't really help to strengthen something which is not the weakest link in the chain. My rationale for having a short key is that it more accurately reflects my estimate of the degree of security provided by my remailer. Actually probably an even shorter length than 510 bits would be appropriate, maybe something more like 300 or 400 bits. Going to a 1000 bit key would probably mislead people into thinking that they only way an attacker could trace their message would be by using a zillion mips-years of computing power or something. > >Recall that my original comments were in connection with the claim that > >the government was running most of the remailers. As I said, I still > >think that is absurd when it would be so much easier to simply steal > >their keys. > > But the point is that it is _not_ easier to steal the keys. It is > much easier to put up a remailer than to attack an existing remailer, > this is why the remailer system is winning the battle of security > economics. By putting up its own remailers a potential attacker > probabalistically diminishes the number of systems which they must > break. > > jim Yes, I think I misstated my point here. My real point was that large keys are inappropriate. Maybe you are right that it is easier to start up a remailer than to break one. On the other hand, unless you also break the ones you don't run, you (as a LEA) are not in a position to accomplish your presumed goal, which is to track criminal messages to their source. So in practice I think they would try to break remailers, and again I am sure they will not do so by factoring keys, even for mine. It's also my personal impression that remailers are not mostly run by LEA's, just on the basis of the occasional postings I have seen by remailer operators here. Frankly I doubt that remailers are enough of a problem to be worth the effort on the part of a LEA to run one and deal with all of the hassles. But this may change in the future. Hal

1 0

Re: (Fwd) Gov't run anon servers
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 1:08 PM 3/5/96 -0800, Jim McCoy wrote: >The point is not to make a system which is absolutely, positively, no >doubt about it, secure against any attacker. If cypherpunks could do >this they would be working for defense contractors and others who make >certified systems. The objective is to make a system which is difficult >to attack, one which costs the attacker time/money. ... It seems to me that one of the best ways to better protect the remailer system would be to regulary change the remailer keys. By destroying the old secret keys, you protect the remailer and its operator against rubber hose attacks aimed at decrypting recorded traffic. As a suggestion: Assume you change the keys every week. You post this week's key to a public keyserver, replacing last week's key. To allow continuous operation you remember both this week's and last week's secret keys and process messages encrypted under either. To validate these keys, you use a long-term key to sign them. Note that for the really paranoid, this long-term key can be kept at a separate site, and only used after e.g. voice verification of the new key's fingerprint. Regards - Bill ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

Re: Remailer Security
by David E. Smith 17 Dec '03

17 Dec '03

At 11:06 PM 3/4/96 -0500, jrochkin@cs wrote: >At 11:06 PM 03/04/96, lmccarth(a)cs.umass.edu wrote: >Um, there's no reason why your remailer's account needs to be logged into >interactively, is there? Seems like remailer ops should disable login to >remailer accounts, putting '*' into the password field in /etc/passwd, or >however unix lets you disable login (I know it does). If I want a remailer's key, I would probably try to go after root. Not only will it get me that key, but there's no telling what else might turn up in the meantime. If you can get access to any account on the system, odds are good you can give yourself root access anyway. It's almost a "freebie." >Obviously, the general security risk of someone gaining unauthorized access >to the remailer executable or data files is still there, and important to >keep in mind. But this would seem to be a fairly logical security measure. You could always do a custom-compile of PGP that never checks for a passphrase; it's compiled into the executable. That's only a trivial measure at best (heck, hex editors have been around since roughly the dawn of UNIX) but it's a place to start. I don't think it's possible to have too much security. dave ----- David E. Smith, c/o Southeast Missouri State University 1000 Towers Circle South MS 1210 Cape Girardeau MO 63701 dsmith(a)midwest.net, dave(a)nym.alias.net, PGP 0x961D2B09 (573)339-3814 http://www.midwest.net/scribers/dsmith/ "Reality is only for those lacking in true imagination."

1 0

Re: Bombings, Surveillance, and Free Societies
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

At 12:51 PM 3/4/96, Timothy C. May wrote: > Personally, while I feel sorry for the dead in Israel, I think anyone who > moves to a small desert state surrounded on all sides by Arabs who want > their land back is asking for trouble. I argue that the invading of countries, bombing of cities, starving of towns, burning of villages, hijacking of ships, and murdering torturing, beating and kidnapping of Arabs to be "asking for trouble." > Being an atheist, I treat all religious mystics as suspect. When a bunch of > people leave London and Chicago and Paris to live in the desert, surrounded > by sworn enemies with nuclear capabilities, I think whatever happens to > them is...."unsurprising." I disagree with you here; the only side with nuclear capabilities is Israel. We cannot keep having this mixture of Jews and Arabs. We have to stop the blurring. There has to be a separation, not just a technical closure. We have to decide on separation as a philosophy." - Yitzhak Rabin

1 0

Anonymous Web Browsing
by A. Padgett Peterson P.E. Information Security 17 Dec '03

17 Dec '03

Realy two questions - will treat each in order > I have followed the ongoing discussion on PGP security, remailers >and the like. I am wondering if the current trend with interactive Web >browsing, Java, etc, is not going to create a privacy problem every bit as >significant as insecure e-mail. As these "applets" become more >sophisticated are we not going to have to face up to the issue of dynamic >links to web sites that gather a lot of info from your computer as you >interact with it? It is possible to design a "prophylactic" environment that would control the interaction between your web browser and the PC. As was determined with FV's keystroke monitor, it only worked because nothing prevented it, not because nothing could prevent it. Such links can be prevented from gathering information but I suspect it would be more creative to feed it information that you would like others to believe. > My question is this: Would it be possible to create a web site that >would function along the same lines as remailers do? Something that would >allow a person to browse anonymously. This is a different question. By nature, web transactions are interactive which means that both sides must know how to reach each other. You could set up a limited proxy and load it with the preferred information but I suspect it would be easier to just send $20 and a requested username/password to a local provider for a PPP account. Would not be "anonymous" but if done carefully, the provider would not have to know who was using the account. In the case of my local provider, no proof of my identity was ever required and the entire set-up was done over the telephone (and I was not at home at the time). Did not try to hide my identity but could have. Warmly, Padgett

1 0

Square pegs in round holes
by A. Padgett Peterson P.E. Information Security 17 Dec '03

17 Dec '03

>Bob must find out whether Alice has declared (commited) her interest >in him, if and only if he has declared (commited) his interest in her. >Before he does so, he can at most know that a girl is interested in him. >Another description: Bob and Alice can have a date if they both commit >to each other. If only one commits, nobody will ever find out about it. >- T is the trusted third party. Well if we *must* use D-H that is a way, but why do that ? Instead of using a binary assymetric key, why not a triple ? (Just because I do not know of any does not mean that one does not exist). Consider a function such that Alice has a key such that given a message M, when encrypted by Alice may be manipulated by T such that Bob can decrypt it. Similarly, Bob has a key that when manipulated by T' can be read by Alice. Assymetric but not binary. The advantage here is that while "T" is trusted by both, he/she/it/other is not able to read either message, rather acts as a catalyst. Such a mechanism could be as indicated or could be circular e.q. a cipher such that A can generate a message readable by T who can generate a message redable by B who can generate one readable by A. True you could do this with three pairs of keys distributed alternatively so that a single person can only write left and read right. As to why you would want such a curiosity, consider a corporation with 80,000 mailboxes. It would be desirable for each person to be able to send E-Mail to any other person but not desirable for each person to have to hold all 80,000 keys. Given a triple (tertiary ?) function each individual would only need their receive key and a "post office" transmit key. On sending a message, it would be encrypted with a session key and the session key encrypted with the post office key. The post office would have all 80,000 receive functions but through the assymetic keying would only be able to convert the session key to something each intended recipient could decode but not be able to decode the message itself. This would meet both criteria (not key escrow but that is under "management") D-H is wonderful but has difficulties with scalability. If such a function existed (has anyone looked ?) it would solve the problem. "The exercise is left to the student" Warmly, Padgett

1 0

Re: FW: Communications Decency Act (hee-hee)
by jf_avon＠citenet.net 17 Dec '03

17 Dec '03

tcmay wrote: >Welcome to the Fourth Reich. Read _The_Ominous_Parallels_ by Leonard Peikoff JFA **** OLD KEY: USE ONLY FOR VERIFYING SIGNATURES **** 1024 bits Key ID:57214AED 1995/10/04 Jean-Francois Avon <jf_avon(a)citenet.net> 84 96 76 AE EB 7C AB 15 88 47 87 B0 18 31 74 9F

1 0

Re: (Fwd) Gov't run anon servers
by tallpaul＠pipeline.com 17 Dec '03

17 Dec '03

On Mar 04, 1996 15:11:43, 'tcmay(a)got.net (Timothy C. May)' wrote: > >At a Cypherpunks meeting a couple of years ago we spent some time >brainstorming this. It seemed plausible that a small outfit could make such >"remailer boxes" and sell them cheaply. (Hardware prices have plunged even >further.) > I had written on similar things over the past few months, on the "$20 Mixmaster" post. New hardware drives with replaceable media in the 100+ Mb range has developed. The Syquest 135 Mb drive, featured in the latest issue of _PC Mag_ can, with the parallel port version, reportedly boot. This means one can have the drive that weighs about two pounds and a $20 disk, place another OS on the disk, and have a very portable remailer system. I viewed the whole thing as more geared to the amateur market, whereby jr. high school students and the like could set up their own remailers, known only to a "small circle of friends." T.C. May's theory of the commercial "mom and pop" version is just as valid. One major way to "increase the noise level" is to greatly increase the number of remailer, especially small ones that may come and go based on little more than word of mouth advertising. Imagine two scenarios. In scenario one, the are two or three large xerox stores in a city. All advertise in the yellow pages and are known throughout the city as the place you go to have your xeroxing done. They all do a tremendous volumn of business. In scenario two, there are an enormous number of small stores with xerox machines, large numbers of home offices with the machines, and large numbers of people with word-of-mouth knowledge of friends with machines to use. What society is easier to crackdown on? --tallpaul PS: A week or two ago, someone posted a notice of anon remailers under Windows that was in alpha test and due in beta in about a month. Same thing. Same benefit.

1 0

FW: Communications Decency Act (hee-hee)
by blanc 17 Dec '03

17 Dec '03

Had to share this funny bit with y'all...... .. Blanc ---------- From: William Pickard[SMTP:bpickard@pickard-murphy.com] Sent: Sunday, March 03, 1996 6:07 PM To: Mark Anderson Subject: Communications Decency Act Scott Adams, the author of Dilbert, contributes this to the debate: Communications Decency Act -------------------------- The government of the United States has passed a law which makes it a crime to transmit indecent materials over the Internet. As a citizen of this great country I plan to fully comply with that law. >From now on, whenever I get the urge to use an offensive word in e-mail I will substitute the name of an offensive politician. I urge you to do the same. The beauty of this approach is that they can't easily ban these new naughty words without changing their own names. I know I could get in trouble for suggesting such a thing, but I don't give a flying Clinton what they think. And if they don't like it they can come over here and kiss my Gingrich. William Pickard bpickard(a)pickard-murphy.com Pickard & Murphy, Inc. Telephone (206) 323-5979 3213 East Alder Street FAX (206) 860-4877 Seattle, Washington 98122-6314

1 0

Re: Is there any work on entropy-lowering schemes?
by Bill Stewart 17 Dec '03

17 Dec '03

At 07:46 PM 3/1/96 -0500, Mutant Rob <wlkngowl(a)unix.asb.com> wrote: >I'm wondering if anyone has done any work on schemes to lower the >entropy of a given stream. Why? Save you've got message M encrypted >with a good cipher, but you're worried that it can be detected because >even with stego, the entropy is a lot higher than normal 'random' data >flowing through a network. Peter Wayner's work on Mimic Functions does just this sort of thing. You can describe a grammar, feed it random bits, and generate output that has the right statistics and can be reversed to get the original bits. His paper was on cs.cornell.edu a few years ago; don't know where to find it now. AltaVista yields a reference to the paper in Cryptologia, and the Cyphernomicon has the following: - "They encode a secret message inside a harmless looking ASCII text file. This is one of the very few times the UNIX tools "lex" and "yacc" have been used in cryptography, as far as I know. Peter Wayner, "Mimic Functions", CRYPTOLOGIA Volume 16, Number 3, pp. 193-214, July 1992.[Michael Johnson, sci.crypt, 1994-09-05] (When I read the Cryptologia reference on my browser, I don't get the ligature in the middle of "Huffman coding"; YMMV. :-)

2 1