- cypherpunks-legacy - lists.cpunks.org

CDR: RE: California bars free speech of those cutting deals on votes
by Trei, Peter 01 Nov '00

01 Nov '00

> ---------- > From: Ken Brown[SMTP:k.brown@ccs.bbk.ac.uk] > > The voters will be able to suss it out without a website. > [...] > The same has, I suspect, been true of 3rd parties in the USA. You can't > judge their strength by their vote because many of their votes because > they are nearly always a vote *against* whoever seems most likely to get > in. And because genuine supporters, knowing their preferred candidate > won't get in, may pragmatically vote for the contender they consider > least damaging. As Tim pointed out the other day. We're not doing this > for fun. If there is a chance of getting someone in who will do less > real damage, vote for them. In the absence of revolution, amelioration > at least ameliorates. [...] > Ken > I'd like to voice my agreement on this. Here in Massachusetts, the state is considered such a Democrat stronghold that we've seen almost zero campaigning by either major party (while this is usually considered a godsend, I'm starting to feel ignored :-). At the local level, Senator Ted Kennedy's seat is up for re-election, but Ted has such a lock on it that he isn't bothering to campaign. The state's Republicans have managed to self-destruct (their initial candidate withdrew, and Jack Robinson, the replacement who popped up at the last minute, has proved utterly without merit - the state party no longer supports him, and he's out of money). All indications are that Carla Howell, the Libertarian challenger for Kennedy's Senate seat, will handily out-poll the Republicans this year. As a result, my vote is immaterial to either major party, and I can happily vote my conscience without any fear that I'm helping throw the election to either Gush or Bore - both of whom I find utterly odious for intersecting sets of reasons. (Just in case you were wondering, I'm voting Libertarian). Peter Trei

1 0

CDR: optical computing on /.
by Jim Choate 01 Nov '00

01 Nov '00

An interesting article about 'decoherence free subspace' and how to use it to reduce the noise in QM computations. ____________________________________________________________________ He is able who thinks he is able. Buddha The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage(a)ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------

1 0

CDR: crypto
by Results＠TVEyes.com 01 Nov '00

01 Nov '00

Your keyword(s), crypto, was recently spoken on YTV during Kleo the Misfit Unicorn. Wednesday, Nov 1 2000 at 07:21 AM ......and don t forget about counting to ten i m not kidding dad i saw a unicorn talking to our bigfoot we re definitely two of a kind joey but i think our bigfoot find is enough for one trip dad are you sure you wanna give her to that crypto whatever place ...... For details, visit http://www.TVEyes.com/database/expand.asp?ln=2530645&Key=crypto Just follow the above link to keep your account active for this keyword. For total control of your keywords, go to http://www.tveyes.com/log_in.asp Get $200 in FREE Gasoline: no risk, no obligation! http://by.advertising.com/1/c/23066/7793// <a href="http://by.advertising.com/1/c/23066/7793//"> AOL users click here </a>

1 0

CDR: toner cartridges
by jacks＠webcity.ca 01 Nov '00

01 Nov '00

Your Toner Cartidge Discount Depot Special savings on Laser Printer and Fax Toner Cartridges. Savings on Canon Personal Copier Cartridges. Cartridges offered are Hewlett Packard,Canon,Lexmark,Apple and Epson compatible products. For more Information please call: 1-888-248-2015 For E-mail removal please call: 1-888-248-4930

1 0

CDR: Re: Visit a hacked site, loose your computers.
by mmotyka＠lsil.com 01 Nov '00

01 Nov '00

Wouldn't the time of the hack be pretty well known and wouldn't the RPI firewall logs be timestamped or am I naive? Is knowledge being used as evidence of guilt? Mike >Andres Salomon, a fairly clued in RPI student, heard on > IRC that the Yankees website had been hacked. He > checked it out, noted some well-known Red Hat > security holes, and came to the conclusion that > there had been a DNS redirect attack. Total time: > 5 minutes. > > The next day, the FBI raided his dorm room and > seized his computers (along with a copy of ORA's > DNS & BIND). > > Peter Trei >

2 1

CDR: Ho to KICK OUT Junkbusters users
by ichudov＠Algebra.Com 01 Nov '00

01 Nov '00

I have a website (www.algebra.com) that makes money from banners. I have a suspicion that a small percentage of my users uses Junkbusters proxy in order to avoid seeing my banners. I do not want to serve such users at all and I do not want them to use my bandwidth. Is there any way to detect a user of Junkbusters in a CGI/mod_perl script? Thanks - Igor.

13 22

CDR: toner cartridges
by jacks＠webcity.ca 01 Nov '00

01 Nov '00

Your Toner Cartidge Discount Depot Special savings on Laser Printer and Fax Toner Cartridges. Savings on Canon Personal Copier Cartridges. Cartridges offered are Hewlett Packard,Canon,Lexmark,Apple and Epson compatible products. For more Information please call: 1-888-248-2015 For E-mail removal please call: 1-888-248-4930

1 0

CDR: public keyrings
by bob bob2 01 Nov '00

01 Nov '00

if you have the url for an active public keyring site please forward it. thanks, bob dobs _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.

4 3

CDR: ZKS "Smart Privacy Policies"
by Adam Back 31 Oct '00

31 Oct '00

cypherpunk agent X wrote: > Here we get to the meat of the issue... the > item that NAI tried to force down our throats...Corporate Key Escrow.. > this time via key splitting... Shades of the NSA Key!! > > Sick em Adam!! This is referring to me right -- as I was involved in the big fight about NAI's corporate message key escrow proposal? Disclaimer: note I work for ZKS now, below are my personal opinions. It's not key escrow, and it's not building tools for key escrow. Greg wrote: > ZKS has been pretty aggressively and conspicuously hiring wild-eyed > cypherpunk types, who won't necessarily inspire a lot of confidence > or trust in accoutant and risk-manager types. Yeah but the company's goal should be to satisfy users that there is a reason to trust the solution, and ZKS has brand recognition for building "trust no-one" (or at least distributed trust) solutions. Tim wrote: > [...] >By building precisely the tools they and other governments would need >to implement such a system, you are making such a system more likely >to happen. I agree with this argument. I wrote up some GAK-resistant design principles during the NAI/PGP key escrow argument (http://www.cypherspace.org/~adam/grdesign/) in an attempt to get people thinking about the social implications of protocols they write -- and to show that actually crypto protocols are not neutral -- a protocol could even be deliberately designed to frustrate later imposition of GAK -- for example end-to-end forward secrecy. Not suprisingly trying to frustrate GAK typically increases the security of your protocol, because the GAK aspect is a kind of attack, which could be perpetrated by others. This is one of the conclusions of the 11 cryptographers report on the risks of key escrow (http://www.cdt.org/crypto/risks98/) Here's my personal take on the design of privacy systems. It's basically an elaboration of "trust no-one", and "write code not laws" (aka cypherpunks write code). The desired trust model for privacy in order of preferred solution: - best: don't reveal the information in the first place -- critically rexamine whether is it necessary to reveal the personal data in the first place - if it is necessary to do some processing on data, examine the users processing and storing their own profile (client side applications) - try to operate pseudonymously (persistent anonymous) - if you can't do that at least split the data up (think reply-blocks) -- this is what the "split-key" thing is talking about (more on this below). - if possible make the protocols publicly auditable (as in time-stamp servers where if a server lies the users get a signed transcript proving it cheated). - if you can't do that have ombudsmen and traditional auditing of processes. - government laws come into it in the sense that some governments have or are starting to try to regulate companies handling of data. The UK Data Protection Act would be one example, where companies are supposed to forget data. We've discussed in the past the demerits of government laws wrt "forgetting" data -- if there is a business need for the data, the data service will move off shore. Still some companies will try to comply. - only lastly rely on contract law. Even with contract law it's problematic -- you're asking the company to forget something. For contract law, even though private contracting is a nice way to approach it, in practice it may be pretty hard to prove the company broke a contract, and anyway it's always better to prevent than detect and then argue it out in court. It's all a bit vague to talk about this stuff without some concrete example -- the above is talking loosely about areas where the user would currently be asked to reveal some info to a company. There are other applications one could apply crypto to. Also bear in mind that currently often the situation is no privacy at all -- data mining, sharing, reselling data against claimed privacy policies, weak non-technical "privacy seals", etc. Technical steps to ensure the user doesn't have to trust the company privacy policy is a good thing -- if the privacy policy is implemented in the form of cryptographic prevention. If they have the code and the protocols and they can see that they aren't trusting the company because the data doesn't leave their own computer, or is given pseudonymously through a mix net is a good thing. Even if nothing else technical is possible, and they have to trust a few third parties not to collude and there is no way to conduct the business without revealing the info to someone, that's an improvement, as previously they would have trusted the company alone. Hence the subject line -- using crypto to make cryptographic prevention is analogous to Nick Szabo's "Smart Contracts". (http://www.best.com/~szabo/smart.contracts.2.html) Now specifically about "key-splitting" -- the press release includes that one odd semi-technical snippet kind of out-of-context and ambiguously. The context is a system which is pretty much a reply-block. So as Adam Shostack says: it's not key splitting, it's multiple layered encryption -- the onion skin analogy. But as I say IMO it's imbalanced and ambiguous to mention that one technical approach without explaining at all, and without mentioning any of numerous other approaches. Adam

1 0

CDR: ZKS "Smart Privacy Policies"
by Adam Back 31 Oct '00

31 Oct '00

[Sent this once from a dud address trying to work around a mail problem -- apologies for duplicates] cypherpunk agent X wrote: > Here we get to the meat of the issue... the > item that NAI tried to force down our throats...Corporate Key Escrow.. > this time via key splitting... Shades of the NSA Key!! > > Sick em Adam!! This is referring to me right -- as I was involved in the big fight about NAI's corporate message key escrow proposal? Disclaimer: note I work for ZKS now, below are my personal opinions. It's not key escrow, and it's not building tools for key escrow. Greg wrote: > ZKS has been pretty aggressively and conspicuously hiring wild-eyed > cypherpunk types, who won't necessarily inspire a lot of confidence > or trust in accoutant and risk-manager types. Yeah but the company's goal should be to satisfy users that there is a reason to trust the solution, and ZKS has brand recognition for building "trust no-one" (or at least distributed trust) solutions. Tim wrote: > [...] >By building precisely the tools they and other governments would need >to implement such a system, you are making such a system more likely >to happen. I agree with this argument. I wrote up some GAK-resistant design principles during the NAI/PGP key escrow argument (http://www.cypherspace.org/~adam/grdesign/) in an attempt to get people thinking about the social implications of protocols they write -- and to show that actually crypto protocols are not neutral -- a protocol could even be deliberately designed to frustrate later imposition of GAK -- for example end-to-end forward secrecy. Not suprisingly trying to frustrate GAK typically increases the security of your protocol, because the GAK aspect is a kind of attack, which could be perpetrated by others. This is one of the conclusions of the 11 cryptographers report on the risks of key escrow (http://www.cdt.org/crypto/risks98/) Here's my personal take on the design of privacy systems. It's basically an elaboration of "trust no-one", and "write code not laws" (aka cypherpunks write code). The desired trust model for privacy in order of preferred solution: - best: don't reveal the information in the first place -- critically rexamine whether is it necessary to reveal the personal data in the first place - if it is necessary to do some processing on data, examine the users processing and storing their own profile (client side applications) - try to operate pseudonymously (persistent anonymous) - if you can't do that at least split the data up (think reply-blocks) -- this is what the "split-key" thing is talking about (more on this below). - if possible make the protocols publicly auditable (as in time-stamp servers where if a server lies the users get a signed transcript proving it cheated). - if you can't do that have ombudsmen and traditional auditing of processes. - government laws come into it in the sense that some governments have or are starting to try to regulate companies handling of data. The UK Data Protection Act would be one example, where companies are supposed to forget data. We've discussed in the past the demerits of government laws wrt "forgetting" data -- if there is a business need for the data, the data service will move off shore. Still some companies will try to comply. - only lastly rely on contract law. Even with contract law it's problematic -- you're asking the company to forget something. For contract law, even though private contracting is a nice way to approach it, in practice it may be pretty hard to prove the company broke a contract, and anyway it's always better to prevent than detect and then argue it out in court. It's all a bit vague to talk about this stuff without some concrete example -- the above is talking loosely about areas where the user would currently be asked to reveal some info to a company. There are other applications one could apply crypto to. Also bear in mind that currently often the situation is no privacy at all -- data mining, sharing, reselling data against claimed privacy policies, weak non-technical "privacy seals", etc. Technical steps to ensure the user doesn't have to trust the company privacy policy is a good thing -- if the privacy policy is implemented in the form of cryptographic prevention. If they have the code and the protocols and they can see that they aren't trusting the company because the data doesn't leave their own computer, or is given pseudonymously through a mix net is a good thing. Even if nothing else technical is possible, and they have to trust a few third parties not to collude and there is no way to conduct the business without revealing the info to someone, that's an improvement, as previously they would have trusted the company alone. Hence the subject line -- using crypto to make cryptographic prevention is analogous to Nick Szabo's "Smart Contracts". (http://www.best.com/~szabo/smart.contracts.2.html) Now specifically about "key-splitting" -- the press release includes that one odd semi-technical snippet kind of out-of-context and ambiguously. The context is a system which is pretty much a reply-block. So as Adam Shostack says: it's not key splitting, it's multiple layered encryption -- the onion skin analogy. But as I say IMO it's imbalanced and ambiguous to mention that one technical approach without explaining at all, and without mentioning any of numerous other approaches. Adam

1 0