Re: full-disk subversion standards released
Given such solutions, frameworks like what TCG is chartered to build are in fact good and useful. I don't think it's right to blame the tool (or the implementation details of a particular instance of a particular kind of tool) for the idiot carpenter. Given the charter of TCG, to produce DRM standards, it's pretty clear what activity their tool is designed to be used for. The theory that we should build good and useful tools capable of monopoly and totalitarianism, but use social mechanisms to prevent them from being used for that purpose, strikes me as naive. Had you not noticed obvious indications like the corruption of the Executive Branch by NSA, RIAA and MPAA (including the shiny new president), the concurrence of the Legislative Branch in that corruption, and the toothlessness of the States and the Judicial Branch in failing to actually reign in major federal constitutional violations? Yes, I'm analogizing DRM to wiretaps and jiggered voting machines. But isn't DRM like a wiretap deep inside your computer -- a foreign agent that spies on you and reports back whatever it chooses, against your will? Worse, it's like a man-in-the-middle attack, buried inside your computer. If Hollywood succeeded in injecting DRM into all our infrastructure, who among us would seriously believe the government would not muscle its way in and start also using the DRM capabilities against the citizens? The Four Horsemen of the Infopocalypse are alive and well. Are you one of those guys in *favor* of sex offenders being allowed free access to children on the Internet, buddy? It's so simple, everyone will just prove they aren't a sex offender before being granted access. It's just like getting on a plane. (TCG has excised all mention of DRM from recent publications -- but I have the original ones, which had DRM examples explaining the motivation for why they were doing this work. I'll append one such example, for those who can't readily search the archives back to 2003. Skip down to TCPA in the body below.) John Message-Id: 200312162153.hbglrods029...@new.toad.com To: Jerrold Leichter jerrold.leich...@smarts.com cc: cryptography@metzdowd.com, gnu Subject: Re: Difference between TCPA-Hardware and other forms of trust In-reply-to: pine.gso.4.58.0312151831570.3...@frame Date: Tue, 16 Dec 2003 13:53:24 -0800 From: John Gilmore g...@toad.com | means that some entity is supposed to trust the kernel (what else?). If | two entities, who do not completely trust each other, are supposed to both | trust such a kernel, something very very fishy is going on. Why? If I'm going to use a time-shared machine, I have to trust that the OS will keep me protected from other users of the machine. All the other users have the same demands. The owner of the machine has similar demands. I used to run a commercial time-sharing mainframe in the 1970's. Jerrold's wrong. The owner of the machine has desires (what he calls demands) different than those of the users. The users, for example, want to be charged fairly; the owner may not. We charged every user for their CPU time, but only for the fraction that they actually used. In a given second, we might charge eight users for different parts of that fraction. Suppose we charged those eight users amounts that added up to 1.3 seconds? How would they know? We'd increase our prices by 30%, in effect, by charging for 1.3 seconds of CPU for every one second that was really expended. Each user would just assume that they'd gotten a larger fraction of the CPU than they expected. If we were tricky enough, we'd do this in a way that never charged a single user for more than one second per second. Two users would then have to collude to notice that they together had been charged for more than a second per second. (Our CPU pricing was actually hard to manage as we shifted the load among different mainframes that ran different applications at different multiples of the speed of the previous mainframe. E.g. our Amdahl 470/V6 price for a CPU second might be 1.78x the price on an IBM 370/158. A user's bill might go up or down from running the same calculation on the same data, based on whether their instruction sequences ran more efficiently or less efficiently than average on the new CPU. And of course if our changed average price was slightly different than the actual CPU performance, this provided a way to cheat on our prices. Our CPU accounting also changed when we improved the OS's timer management, so it could record finer fractions of seconds. On average, this made the system fairer. But your application might suffer, if its pattern of context switches had been undercharged by the old algorithm.) The users had to trust us to keep our accounting and pricing fair. System security mechanisms that kept one user's files from access by another could not do this. It required actual trust, since the users didn't have access to the data required to check up on us
Re: full-disk subversion standards released
On Fri, Jan 30, 2009 at 03:37:22PM -0800, Taral wrote: On Fri, Jan 30, 2009 at 1:41 PM, Jonathan Thornburg jth...@astro.indiana.edu wrote: For open-source software encryption (be it swap-space, file-system, and/or full-disk), the answer is yes: I can assess the developers' reputations, I can read the source code, and/or I can take note of what other people say who've read the source code. Really? What about hardware backdoors? I'm thinking something like the old /bin/login backdoor that had compiler support, but in hardware. Plus: that's a lot of code to read! A single person can't hope to understand the tens of millions of lines of code that make up the software (and firmware, and hardware!) that they use every day on a single system. Note: that's not to say that open source doesn't have advantages over proprietary source. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: full-disk subversion standards released
On Fri, Jan 30, 2009 at 04:08:07PM -0800, John Gilmore wrote: The theory that we should build good and useful tools capable of monopoly and totalitarianism, but use social mechanisms to prevent them from being used for that purpose, strikes me as naive. Okay. In that case, please, explain to me why you are not opposed to the the manufacture and sale of digital computers. More gently: it seems to me that there is an only missing from your sentence above, or else it is almost by necessity a straw-man argument: it will, if consistently applied as you have stated it, hold against various tools I do not believe you actually oppose the manufacture or sale of, such as printing presses, guns, and door locks. Many of TCG's documents purport to specify mechanisms that are in fact generally useful for beneficial purposes, such as boot-time validation of software environments, secure storage of cryptographic keys, or low-bandwidth generation of good random numbers. Do you actually mean that such things should not be built, or only that you are suspicious of TCG's intent in building them? In text I've snipped, you claimed to describe TCG's charter. I must admit that I don't know if they even actually have such a document. But, on the other hand, they describe their own purpose like this (these are their actual words): The Trusted Computing Group (TCG) is a not-for-profit organization formed to develop, define, and promote open standards for hardware-enabled trusted computing and security technologies, including hardware building blocks and software interfaces, across multiple platforms, peripherals, and devices. TCG specifications will enable more secure computing environments without compromising functional integrity, privacy, or individual rights. The primary goal is to help users protect their information assets (data, passwords, keys, etc.) from compromise due to external software attack and physical theft. I happen to think that if those _stated_ goals were achieved, that would be a good thing, and that there are in fact hardware and software mechanisms that could help achieve them -- some of which TCG has made stabs at specifying, though they've generally missed the mark. Leaving aside your assertions about TCG's _actual_ goals -- which may be correct -- are you really of the position that what's described above, no matter who were to build it nor how well, would be only useful for monopoly and totalitarianism? Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Proof of Work - atmospheric carbon
At 10:40 AM 1/30/2009, Thomas Coppi wrote: Just out of curiosity, does anyone happen to know of any documented examples of a botnet being used for something more interesting than just sending spam or DDoS? There are good botnets and bad botnets. Good ones ask you if you want to join, bad ones don't. Good ones are typically things like s...@home, fold...@home, Great Internet Mersenne Prime Search, DES crackers, etc., and if you've got something good to do, people will help. People usually only set up the bad ones if they want to do something bad - it may be interesting the first time they do it, like a new flavor of DDOS, but it's not usually doing the world any favors. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Proof of Work - atmospheric carbon
John Levine writes: http://www.taugh.com/epostage.pdf I would also point out that nothing is preventing anyone from implementing their own epostage. Just send your email via a paypal Send Money, accompanied with whatever postage you feel is appropriate. No magic, no standards track epostage, no chicken-and-egg implementation problem, not even any crypto needed. Too boring to actually use, I guess. -- --my blog is athttp://blog.russnelson.com | Delegislation is a slippery Cloudmade supports http://openstreetmap.org/| slope to prosperity. 521 Pleasant Valley Rd. | +1 315-323-1241 | Fewer laws, more freedom. Potsdam, NY 13676-3213 | Sheepdog | (Not a GOP supporter). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: full-disk subversion standards released
John Gilmore g...@toad.com writes: The theory that we should build good and useful tools capable of monopoly and totalitarianism, but use social mechanisms to prevent them from being used for that purpose, strikes me as naive. There's another problem with this theory and that's the practical implementation issue. I've read through... well, at least skimmed through the elephantine bulk of the TCG specs, and also read related papers and publications and talked to people who've worked with the technology, to see how I could use it as a crypto plugin for my software (which already supports some pretty diverse stuff, smart cards, HSMs, the VIA Padlock engine, ARM security cores, Fortezza cards (I even have my own USG-allocated Fortezza ID :-), and in general pretty much anything out there that does crypto in any way, shape, or form). However after detailed study of the TCG specs and discussions with users I found that the only thing you can really do with this, or at least the bits likely to be implemented and supported and not full of bugs and incompatibilities, is DRM. In all the time I've worked with crypto devices I've never seen something so totally unsuited to general-purpose crypto use as a TPM. There really is only one thing it can reliably be used for and that's DRM. Now admittedly if you look really hard you may find a particular vendor who has a hit-and-miss attempt at implementing some bits of the spec that, if you cross your eyes and squint, is almost usable for general-purpose crypto use, but that's it. Even with the best intentions in the world, the only thing you can really usefully do with a TPM is DRM. (NB: This was a few years ago, maybe things have improved since then but I haven't seen any real indication of this. Oh, and I'm not going to get into the rathole of whether the whole attestation thing is DRM or not, if you think it isn't then please replace all occurrences of DRM in the above text with attestation). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: UCE - a simpler approach using just digital signing?
On Fri, Jan 30, 2009 at 01:47:23PM -0800, Ray Dillinger wrote: Each time Fred gives out his email address to a new sender, he creates a trust token for that sender. They must use it when they send him mail. That's basically what I'm using, just without the digital signature part: each person/organisation/website/whatever gets a different email address for communicating with me (qmail makes this easy to implement); mailing list and bugtracker addresses are filtered to accept only mail with the correct headers. It works much better than content filters, but it's basically limited to 1:1 communication (with a mailing list looking like a single entity as it forwards traffic both ways). Most importantly, it breaks for CC parties (*). Address lists on paper given out to a large number of participants are problematic as well (those utilizing paper lists are mostly non-tech-savvy - thus prone to attacks - and changing the address is hard due to the long update interval of the list). To get on-topic again: Another scheme (that could be combined with the above one to solve only the CC party problem) would be accepting only PGP mail and use a manually updated whitelist / web of trust of PGP keys. Unfortunately, PGP still isn't widespread enough to reject non-PGP mails and the ones not using it are often far more susceptible to address harvesting malware, limiting the usefulness of such a filter. (*) CC party: group discussion without predetermined participants (so no mailing list could be set up in advance) CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature
Re: Proof of Work - atmospheric carbon
On Fri, 30 Jan 2009 11:40:12 -0700
Thomas Coppi thisnuke...@gmail.com wrote:
On Wed, Jan 28, 2009 at 2:19 PM, John Levine jo...@iecc.com wrote:
Indeed. And don't forget that through the magic of botnets, the bad
guys have vastly more compute power available than the good guys.
Just out of curiosity, does anyone happen to know of any documented
examples of a botnet being used for something more interesting than
just sending spam or DDoS?
I asked Rob Thomas of Team Cymru this question (he and they study the
underground). Here is his answer, posted with permission:
Botnets are routinely used as:
1. Proxies (IRC, HTTP HTTPS)
2. To recover financial credentials, e.g. paypal, citibank, et al.
This was the original purpose of the PSNIFF code in some of the early
bots.
Here's a code snippet from the now venerable
rBot_rxbot_041504-dcom-priv-OPTIX_MASTERPASSWORD dating back several
years:
[ ... ]
// Scaled down distributed network raw packet sniffer (ala Carnivore)
//
// When activated, watches for botnet login strings, and
// reports them when found.
//
// The bots NIC must be configured for promiscuous mode (recieve
// all). Chances are this already done, if not, you can enable it
// by passing the SIO_RCVALL* DWORD option with a value of 1, to
// disable promiscuous mode pass with value 0.
//
// This won't work on Win9x bots since SIO_RCVALL needs raw
// socket support which only WinNT+ has.
[ ... ]
PSWORDS pswords[]={
{:.login,BOTP},
{:,login,BOTP},
{:!login,BOTP},
[ ... ]
{paypal,HTTPP},
{PAYPAL,HTTPP},
{paypal.com,HTTPP},
{PAYPAL.COM,HTTPP},
{Set-Cookie:,HTTPP},
{NULL,0}
};
[ ... ]
3. Remember they're called boats now, so anything is possible. Screen
captures are becoming increasingly popular.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: UCE - a simpler approach using just digital signing?
That's basically what I'm using, just without the digital signature part: each person/organisation/website/whatever gets a different email address for communicating with me (qmail makes this easy to implement) I do that too -- I bet half the people on this list do, and there's lots of free and commercial services like Yahoo and Spamex who will let you do it. But it's not much of a solution to spam because it requires significant manual work to maintain the addresses, and only deals with places where you individually give them the address to send mail to. Another scheme (that could be combined with the above one to solve only the CC party problem) would be accepting only PGP mail and use a manually updated white list This has the same fundamental problem as Zoemail and any other white list system. It's really easy to implement a white list. Unless your name is Paypal, the amount of mail forging your address is vanishingly small, and the utterly insecure From: line address works just fine for practical purposes. I use that to manage my 12 year old daughter's mail. But whitelists replace the spam problem with the equally intractable introduction problem, deciding whether to accept the first message from someone you don't know. People have been thinking about that for a long time (indeed, for millenia in contexts other than e-mail) and the snarky comments I made yesterday about wonderful anti-spam ideas apply here, too. The ASRG is still eager to hear from people who want to do just about anything related to spam other than hash over known-ineffective old ideas. See http://wiki.asrg.sp.am. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
