Re: [camram-spam] Re: Microsoft publicly announces Penny Black PoW postage project
At 7:46 PM + 12/30/03, Richard Clayton wrote: where does our esteemed moderator get _his_ stamps from ? A whitelist for my friends, etc... Whitelist [EMAIL PROTECTED] Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] 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' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [camram-spam] Re: Microsoft publicly announces Penny Black PoW postage project
At 07:46 PM 12/30/2003 +, Richard Clayton [EMAIL PROTECTED] wrote: [what about mailing lists] Obviously you'd have to whitelist anybody's list you're joining if you don't want your spam filters to robo-discard it. moan I never understand why people think spam is a technical problem :( let alone a cryptographic one :-( /moan The reason it's partly a cryptographic problem is forgeries. Once everybody starts whitelisting, spammers are going to start forging headers to pretend to come from big mailing lists and popular machines and authors, so now you'll not only need to whitelist Dave Farber or Declan McCullough if you read their lists, or Bob Hettinga if you're Tim (:-), you'll need to verify the signature so that you can discard the forgeries that pretend to be from them. You'll also see spammers increasingly _joining_ large mailing lists, so that they can get around members-only features. At least one large mailing list farm on which I've joined a list used a Turing-test GIF to make automated list joining difficult, and Yahoo limits the number of Yahoogroups you can join in a day, but that's the kind of job which you hire groups of Indians or other English-speaking third-world-wagers to do for you. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [ISN] Oh Dan Geer, where art thou?
Hi All, I hope that those who talk aloud ,especially against the powerful survive. Else the technology which was supposed to give democracy the boost - Internet would be crushed -by the forces who believe that voices of dissent should be silenced. To add to the injury would be the death of open source and may be the opennes that allowed the computers to develop into what they are now. Anish ===A student in search of nothing ...they call it a PhD -Original Message- From: R. A. Hettinga [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Tue, 30 Dec 2003 12:47:57 -0500 Subject: [ISN] Oh Dan Geer, where art thou? --- begin forwarded text Date: Tue, 30 Dec 2003 09:30:58 -0600 (CST) From: InfoSec News [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [ISN] Oh Dan Geer, where art thou? Sender: [EMAIL PROTECTED] Reply-To: InfoSec News [EMAIL PROTECTED] Status: http://napps.nwfusion.com/weblogs/security/003879.html By Ellen Messmer Network World Fusion 12/22/03 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: hiding attestation from the consumer
There isn't really any security benefit obtained by hiding the content of the attestation _from the party providing it_! This statement reveals confusion between the parties. There are at least three parties involved in an attestation: * The DRM'd product vendor (somewhere on the net) * The consumer (sitting at their PC) * The PC hardware and software vendors (building attestation in) There are strong reasons to hide the content of the attestation -- or even its mere existence -- from the consumer party. If consumers knew their PCs were spying on them and letting vendors say, Sorry, our server is down today not because the server is down, but because the consumer's PC is blacklisted, then consumers would be upset. It's a much simpler customer relations problem if it just doesn't happen to work, without the consumer ever finding out that they live in a redlined neighborhood and it will NEVER work for them. It's really easy to infer that DRM problems are going to be deliberately inscrutable. You don't see DRM vendors advertising the restrictions on their products. These restrictions aren't in boldface in the table of contents. They're hidden deep in the guts of the manual, if they appear at all. (In the list of error messages is where you usually find 'em, with a very brief mention.) It's the consumer's fault, or their ISP's fault, or somebody else's, if the site doesn't work for you. If your DAT recorder won't record, you must have cabled it up wrong. If your HDTV won't work, you ran it through your VCR by mistake. And if your music site won't download to you, you must have installed your software wrong, or there's a firewall problem, or your codecs are incompatible, or something. When the entire goal is to covertly change consumer behavior, by making things that are utterly legal simply NOT WORK, plain language about the restrictions has no place. Consumer problems caused by DRM are seldom advertised, documented, or reported as the DRM's fault. You can get a similar effect merely by turning off cookies and JavaScript today. (You *do* use a browser that has simple switches to turn these off, right? Mozilla is your friend, and it runs on your platform.) Web sites will start to fail at random, in inscrutable ways. Only about 1% of them will tell you This site requires JavaScript -- and of those that do, only about a quarter of them actually do require it. John Gilmore - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
David Wagner writes: So it seems that third-party-directed remote attestation is really where the controversy is. Owner-directed remote attestation doesn't have these policy tradeoffs. Finally, I'll come back to the topic you raised by noting that your example application is one that could be supported with owner-directed remote attestation. You don't need third-party-directed remote attestation to support your desired use of remote attestation. So, TCPA or Palladium could easily fall back to only owner-directed attestation (not third-party-attestation), and you'd still be able to verify the software running on your own servers without incurring new risks of DRM, software lock-in, or whatever. I should mention that Seth Schoen's paper on Trusted Computing anticipates many of these points and is well worth reading. His notion of owner override basically converts third-party-directed attestation into owner-directed attestation, and thereby avoids the policy risks that so many have brought up. If you haven't already read his paper, I highly recommend it. http://www.eff.org/Infra/trusted_computing/20031001_tc.php Thanks for the kind words. Nikita Borisov has proposed an alternative to Owner Override which Ka-Ping Yee has called Owner Gets Key, and which is probably the same as what you're discussing. Most TC vendors have entered into this with some awareness of the risks. For example, the TCPA whitepaper that John Gilmore mentioned here earlier specifically contemplates punishing people for using disapproved software, without considering exactly why it is that people would want to put themselves into a position where they could be punished for doing that (given that they can't now!). (In deference to Unlimited Freedom's observations, it is not logically impossible that people would ever want to put themselves into that position; the TCPA whitepaper just didn't consider why they would.) As a result, I have not had any TC vendor express much interest in Owner Override or Owner Gets Key. Some of them correctly pointed out that there are interesting user interface problems associated with making this usable yet resistant to social engineering attacks. There might be paternalistic reasons for not wanting to give end-users the attestation keys, if you simply don't trust that they will use them safely. (But there's probably no technical way to have our cake and eat it too: if you want to do paternalistic security, you can probably then abuse it; if you want to give the owner total control, you can't prevent the owner from falling victim to social engineering.) Still, the lack of a totally obvious secure UI hasn't stopped research from taking place in related areas. For example, Microsoft is reportedly still trying to figure out how to make clear to people whether the source of a particular UI element is the program they think it is, and how to handle the installation of NGSCB trusted computing agents. Secure UI is full of thorny problems. I've recently been concerned about one problem with the Owner Override or Owner Gets Key approaches. This is the question of whether they are particularly vulnerable to a man-in-the-middle attack. Suppose that I own a computer with the TCG TPM FOO and you are a server operator, and you and I trust each other and believe that we have aligned interests. (One example is the case where you are a bank and we both want to be sure that I am using a pristine, unaltered computing environment in order to access my account. Neither of us will benefit if I can be tricked into making bogus transactions.) An attacker Mallory owns a computer with the TCG TPM BAR. We assume that Mallory has already compromised my computer (because our ability to detect when Mallory does that is the whole reason we're using attestation in the first place). Mallory replaces my web browser (or financial software) with a web browser that he has modified to send queries to him instead of to you, and to contain a root CA certificate that makes it trust a root CA that Mallory controls. (Alternatively, he's just made the new web browser ignore the results of SSL certificate validation entirely, though that might be easier to detect.) Now when I go to your web site, my connection is redirected to Mallory's computer, which proxies it and initiates a connection to you. You ask for an attestation as a condition of accessing your service. Since I have no particular reason to lie to you (I believe that your reason for requesting the attestation is aligned with my interest), I direct my computer to give you an attestation reflecting the actual state of FOO's PCR values. This attestation is generated and reflects a signature by foo on a set of PCR values that show the results of Mallory's tampering. But Mallory does _not_ pass this attestation along to you. Instead, Mallory uses Owner Override or Owner Gets Key to generate a new attestation reflecting the original set of PCR
Re: why penny black etc. are not very useful
Perry E. Metzger wrote: In my opinion, the various hashcash-to-stop-spam style schemes are not very useful, because spammers now routinely use automation to break into vast numbers of home computers and use them to send their spam. They're not paying for CPU time or other resources, so they won't care if it takes more effort to send. No amount of research into interesting methods to force people to spend CPU time to send mail will injure the spammers. If you set the price to 1 minute of CPU, and spammers own 10% of all machines on the 'net, then the average machine can only receive 144 spams per day. That's a significant improvement on my situation. Plus I'd've thought that having 100% CPU utilisation all the time might attract attention. But maybe not. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [camram-spam] Re: Microsoft publicly announces Penny Black PoW postage project
On Tue, 30 Dec 2003, Bill Stewart wrote: At 07:46 PM 12/30/2003 +, Richard Clayton [EMAIL PROTECTED] wrote: [what about mailing lists] Obviously you'd have to whitelist anybody's list you're joining if you don't want your spam filters to robo-discard it. moan I never understand why people think spam is a technical problem :( let alone a cryptographic one :-( /moan It has always been mostly a technical problem, and only partially a social problem. The reason it's partly a cryptographic problem is forgeries. Once everybody starts whitelisting, spammers are going to start forging headers to pretend to come from big mailing lists and popular machines and authors, so now you'll not only need to whitelist Dave Farber or Declan McCullough if you read their lists, or Bob Hettinga if you're Tim (:-), you'll need to verify the signature so that you can discard the forgeries that pretend to be from them. I had to change my (admittedly simple) whitelisting recently, when spammers started using the same domain name we do business under, or the name of partners. You'll also see spammers increasingly _joining_ large mailing lists, so that they can get around members-only features. At least one large mailing list farm on which I've joined a list used a Turing-test GIF to make automated list joining difficult, and Yahoo limits the number of Yahoogroups you can join in a day, but that's the kind of job which you hire groups of Indians or other English-speaking third-world-wagers to do for you. Yep. Spam rates have been creeping up on Debian lists, lately. Another list I'm on having to do with Oracle has been having similar problems. Who is a meaningful member? That's a tough question, if you don't charge, and if you do, you miss quite a bit, thus lowering the value. Commons, tragedy, etc. -j -- Jamie Lawrence[EMAIL PROTECTED] Those who make peaceful revolution impossible will make violent revolution inevitable. -John F. Kennedy - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: why penny black etc. are not very useful
At 11:12 AM + 12/31/03, Ben Laurie wrote: Perry E. Metzger wrote: In my opinion, the various hashcash-to-stop-spam style schemes are not very useful, because spammers now routinely use automation to break into vast numbers of home computers and use them to send their spam. They're not paying for CPU time or other resources, so they won't care if it takes more effort to send. No amount of research into interesting methods to force people to spend CPU time to send mail will injure the spammers. If you set the price to 1 minute of CPU, and spammers own 10% of all machines on the 'net, then the average machine can only receive 144 spams per day. That's a significant improvement on my situation. Plus I'd've thought that having 100% CPU utilisation all the time might attract attention. But maybe not. Cheers, Ben. There is something else one can do that might help. The hashcash stamp algorithm can be designed to provide a strong, constant signature to virus detectors. For example, in my HEKS-1 algorithm, I populate a large array with pseudo random words. It would be easy enough to have some fraction (say 1/8th or 1/16th) of those words be a special constant (or one of a few special constants). There would be no way for the spammer to avoid exhibiting the same constants while generating stamps without incurring a severe computational penalty. So any stamp generation activity would be easy to detect. Since the signature would never change, the detection software could be built into the operating system (or even the CPU itself). Legitimate stamp generation would have to be distinguished, perhaps by code signing or some Touring test. A sufficiently clever virus writer with root access might be able commandeer the legitimate stamp generator. If this happens, periodic required updates of the hashcash software can be issued that thwart viruses in the field. Also a large number of countermeasure variants can be generated, making it hard for the virus to recognize them all. This reverses the tactical advantage normally enjoyed by virus writers. Illegitimate stamp generators are forced to present a fixed target while legitimate programs and counter measures can continuously morpf. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: why penny black etc. are not very useful
On Wed, 31 Dec 2003, Arnold G. Reinhold wrote: Legitimate stamp generation would have to be distinguished, perhaps by code signing or some Touring test. A sufficiently clever virus writer with root access might be able commandeer the legitimate stamp generator. If this happens, periodic required updates of the hashcash software can be issued that thwart viruses in the field. Also a large number of countermeasure variants can be generated, making it hard for the virus to recognize them all. This reverses the tactical advantage normally enjoyed by virus writers. Illegitimate stamp generators are forced to present a fixed target while legitimate programs and counter measures can continuously morpf. Wildly unrealistic IMHO. I would predict that email transmission *will* remain essentially free. Spam detection software will be deployed more broadly, and spammers who use trojaned machines will at some point in the not too distant future (when the DAs wake up to this widespread criminal activity) be successfully prosecuted. Of the ~75 messages inbound message recipients a day on the gateways I manage, 40% are rejected by RBL lists and private blacklists/content checks. 5% of the remainder is caught as spam by a commercial anti-spam content filter. The filter's detection rate against this RBL pre-screened sample is ~90%, the false positive rate is less than 0.01%. So we get rid of ~99.5% of spam with no hash-cash. This is good enough. I am not about to implement any CPU burning stamp generators any time soon. The recent Microsoft and Yahoo announcements get a lot of publicity, but I am skeptical that they will ever be widely adopted. It is reasonable to note that Microsoft sells a lot of the clients (Outlook OE), so they have a better chance of getting their technology adopted, but even Microsoft has a hard time getting users to upgrade from Windows 98/Office 97 which continue to perform well enough for most users (security flaws and all). -- Victor Duchovni IT Security, Morgan Stanley - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [camram-spam] Re: Microsoft publicly announces Penny Black PoW postage project
Richard Clayton wrote: and in these schemes, where does our esteemed moderator get _his_ stamps from ? remember that not all bulk email is spam by any means... or do we end up with whitelists all over the place and the focus of attacks moves to the ingress to the mailing lists :( He uses the stamp that you generated. Each subscruber adds [EMAIL PROTECTED] as an address they receive mail at. Done. Trivial. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]