October 2000 - cypherpunks-legacy

CDR: Re: California bars free speech of those cutting deals ...
by Anonymous Remailer 01 Nov '00

01 Nov '00

>California has "shut down"--through a threatening letter--a site >which matches up folks who are willing to say theyll vote for Nader >in states where Gore is sure to win if other folks who had hoped to So now it is illegal to provide a public forum with specific capabilities. Is it also illegal for me to privately arrange this with a particular sheeHHHHvoter from the other state ? Gangs can legally call for voters to vote for them and not for the other gang, but voters themselves cannot talk to each other and make arrangements that they see fit. This is the official recognition of the brainwashing monopolies. Time to setup servers in Lybia and Iraq. Too bad their gangs are too stupid to do it themselves. Or maybe I am missing something.

3 2

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: 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

CALL for Papers: The Millennium Mac-Crypto Conference
by Vinnie Moscaritolo 31 Oct '00

31 Oct '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Take out your calendars, It's that time again folks. I am starting to put together the schedule for the Millennium Edition of the Mac Crypto/ Internet commerce workshop. The dates should be the week of Jan 29th, 2001. I have booked us space for that whole week, on the Apple Cupertino Campus . Henceforth, I am looking for folks to give talks, papers etc. This year's overall theme could cover "Security in a MacOS X world". I would like to see a number of talks related to how MacOS X changes the Macintosh threat model. In addition I would also like to see a few talks about lessons learned in the last few years about developing crypto related products. Maybe something about digital rights management or music. Digital cash talks are always welcome. I would like both technical and tutorial material. As usual I discourage simple marketing presentations without content, this is a technical group. Please try to keep the talks no more than 40 minutes with an additional 10 minutes allocated for for Q&A.. I suspect that there a a number of new people who have never been to a Mac Crypto. To get an idea about what this is all about take a look at the past three conference archives at http://www.vmeng.com/mc/ I will be posting a preliminary schedule, formal announcements and registration form in a month. In the meantime if you would like to give a talk, please send me the Title, Author's full name and email address and a small abstract I can post on the web-page. Once you have slides or possibly a pdf, please send me a copy I post or link to.. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 iQA/AwUBOf8/EtixAAkLPvBCEQIIfgCfR3RHnib58GqZ03fbb+m0Ngvw3nQAmwUl F1r76c977zboKxAIK+l6xw5C =0Tx+ -----END PGP SIGNATURE----- -- Vinnie Moscaritolo KF6WPJ ITCB-IMSH PGP: 3F903472C3AF622D5D918D9BD8B100090B3EF042 ------------------------------------------------------- --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

CALL for Papers: The Millennium Mac-Crypto Conference
by Vinnie Moscaritolo 31 Oct '00

31 Oct '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Take out your calendars, It's that time again folks. I am starting to put together the schedule for the Millennium Edition of the Mac Crypto/ Internet commerce workshop. The dates should be the week of Jan 29th, 2001. I have booked us space for that whole week, on the Apple Cupertino Campus . Henceforth, I am looking for folks to give talks, papers etc. This year's overall theme could cover "Security in a MacOS X world". I would like to see a number of talks related to how MacOS X changes the Macintosh threat model. In addition I would also like to see a few talks about lessons learned in the last few years about developing crypto related products. Maybe something about digital rights management or music. Digital cash talks are always welcome. I would like both technical and tutorial material. As usual I discourage simple marketing presentations without content, this is a technical group. Please try to keep the talks no more than 40 minutes with an additional 10 minutes allocated for for Q&A.. I suspect that there a a number of new people who have never been to a Mac Crypto. To get an idea about what this is all about take a look at the past three conference archives at http://www.vmeng.com/mc/ I will be posting a preliminary schedule, formal announcements and registration form in a month. In the meantime if you would like to give a talk, please send me the Title, Author's full name and email address and a small abstract I can post on the web-page. Once you have slides or possibly a pdf, please send me a copy I post or link to.. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 iQA/AwUBOf8/EtixAAkLPvBCEQIIfgCfR3RHnib58GqZ03fbb+m0Ngvw3nQAmwUl F1r76c977zboKxAIK+l6xw5C =0Tx+ -----END PGP SIGNATURE----- -- Vinnie Moscaritolo KF6WPJ ITCB-IMSH PGP: 3F903472C3AF622D5D918D9BD8B100090B3EF042 ------------------------------------------------------- --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

CALL for Papers: The Millennium Mac-Crypto Conference
by R. A. Hettinga 31 Oct '00

31 Oct '00

--- begin forwarded text

1 0

Bush & Gore On Crypto
by R. A. Hettinga 31 Oct '00

31 Oct '00

--- begin forwarded text

1 0