Re: Look, mommy, I'm a SECURITY EXPERT !
Morlock Elloi wrote: > http://www.ITsecurity.com/ > > The Encyclopedia of Computer Security > > (a complete one-source location for information security news, products, > whitepapers, events, definitions and much more) > > requires the use of JavaScript for navigation and display purposes. > > Please switch JavaScript on in your Browser and try again. > > This site has been optimised for Internet Explorer 5+. > (With Mozilla 1.1): TECS has a new Home Page for users of MSIE 5+. If you see this page, you should consider upgrading your Browser to IE5+.Visitors with IE5+ get a more interesting, dynamic and interactive experience, including breaking news, latest products and much more.
RE: RIAA: Feeling Burn of Ripped CDs
http://www.wired.com/news/print/0,1294,54773,00.html claims: "Shipments of CDs dropped 7 percent in the first six months of this year, a fact attributed to an increase in music downloads through file-trading services, according to a report issued Monday by the Recording Industry Association of America (RIAA). " Hmmm, that's interesting, gee, we were having a really great economy the first six months of this year. What, with the aftermath of the terrorist attacks, and the bursting of the dot com bubble, the fall of so many telecoms, and all the thousands upon thousands of layoffs.. I really can't see why people wouldn't be buying CD's in droves with all their disposable income... Gee, it must be the mp3 pirates, yeah, that's the ticket... yeah, it's that napster thing that did it... yeah, that's why the buttstreet boys and the other cocksucking boy and girl bands have had little cd sales, it's not because their music is overpromoted shit that's far less useful than the billions of giveaway AOL coaster cd's, who get less than a penny per sold album anyway and have such great incentive to put-out (tee hee) more of the same... No! It's because they're so popular that every gnutella poppin' teenage fiend who gets thousands of dollars a day in allowance decided to priate their precious unique, creative, and wonderful songs which never sound anything like, and deprive the poor RIAA executives! Oh, poor RIAA, their executives won't be able to support their cocaine habbits anymore, waaa, they'll have to go back to smoking ganja again, Oh, poor, poor bastards, no more personal jets and hookers^H^H^H^H^H^H^H personal massage therapists. Oh, the poor starving RIAA executives! My heart just bleeds for their plight! We must act now to stop the pirates. I know, I know, I'll call my congressman right now, and get all my friends to do the same! We must end this carnage right now! --Kaos-Keraunos-Kybernetos--- + ^ + :NSA got $20Bil/year |Passwords are like underwear. You don't /|\ \|/ :and didn't stop 9-11|share them, you don't hang them on your/\|/\ <--*-->:Instead of rewarding|monitor, or under your keyboard, you \/|\/ /|\ :their failures, we |don't email them, or put them on a web \|/ + v + :should get refunds! |site, and you must change them very often. [EMAIL PROTECTED] http://www.sunder.net
RE: RIAA: Feeling Burn of Ripped CDs
On Wed, 28 Aug 2002, Sunder wrote: > http://www.wired.com/news/print/0,1294,54773,00.html > > claims: > > "Shipments of CDs dropped 7 percent in the first six months of this year, > a fact attributed to an increase in music downloads through file-trading > services, according to a report issued Monday by the Recording Industry > Association of America (RIAA). " They had to produce a lie to counter Forrester Research and Jupiter Media Metrix' study (caveat, engage dekrauting device of choice before viewing): http://www.heise.de/newsticker/data/jk-14.08.02-005/ http://www.heise.de/newsticker/data/anw-05.05.02-003/
Re: right MTA for crypto support
On Wed, Aug 28, 2002 at 03:26:47PM +1200, Peter Gutmann wrote: > Eugen Leitl <[EMAIL PROTECTED]> writes: (actually, I wrote:) > >It's relatively easy to turn on TLS in sendmail. It's not secure against > >active attackers that can modify the data in the TCP stream but it's better > >than nothing. > > Actually it's better than any other mail security out there. See the slides > for my talk at Usenix Security > (http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix02_slides.pdf) for more > details (the StartTLS stuff is about halfway through). It depends on how you define "better". STARTTLS is defeated by Norton AV (silently!) and probably other programs... if not now, then soon. Mail is rarely stolen when in transit, it's much easier to steal it from the destination spool, and STARTTLS does nothing to protect stored mail. The authentication option is only used to authenticate roaming SMTP clients, and probably not often even then since distributing client certificates is hard and too many IT folks still think encrypted == secure. If you define "better" as "more secure", or even "secure against most classes of attackers", it's not better, it's a waste of CPU time. But if you define "better" as "secure against passive eavesdroppers" or as "increases the use of crypto", then it's better. What's needed is something that IS better for both definitions and is as easy to set up as STARTTLS... same thing that's been needed for the last 10 years. Eric
Re: Cryptographic privacy protection in TCPA
Carl Ellison suggested an alternate way that TCPA could work to allow for revoking virtualized TPMs without the privacy problems associated with the present systems, and the technical problems of the elaborate cryptographic methods. Consider first the simplest possible method, which is just to put a single signature key in each TPM and allow the TPM to use that to sign its messages on the net. This is reliable and allows TPM keys to be revoked, but it obviously offers no privacy. Every usage of a TPM key can be correlated as coming from a single system. TCPA fixed this by adding a trusted third party, the "Identity CA" who would be the only one to see the TPM key. But Carl offers a different solution. Instead of burning only one key into the TPM, burn several. Maybe even a hundred. And let these keys be shared with other TPMs. Each TPM has many keys, and each key has copies in many TPMs. Now let the TPMs use their various keys to identify themselves in transactions on the net. Because each key belongs to many different TPMs, and the set of TPMs varies for each key, this protects privacy. Any given usage of a key can be narrowed down only to a large set of TPMs that possess that key. If a key is misused, i.e. "scraped" out of the TPM and used to create a virtualized, rule-breaking software TPM, it can be revoked. This means that all the TPMs that share that one key lose the use of that key. But it doesn't matter much, because they each have many more they can use. Since it is expected that only a small percentage of TPMs will ever need their keys revoked, most TPMs should always have plenty of keys to use. One problem is that a virtualized TPM which loses one of its keys will still have others that it can use. Eventually those keys will also be recognized as being mis-used and be revoked as well. But it may take quite a while before all the keys on its list are exhausted. To fix this, Carl suggests that the TPM manufacturer keep a list of all the public keys that are in each TPM. Then when a particular TPM has some substantial fraction of its keys revoked, that would be a sign that the TPM itself had been virtualized and all the rest of the keys could be immediately revoked. The precise threshold for this would depend on the details of the system, the number of keys per TPM, the number of TPMs that share a key, the percentage of revoked keys, etc. But it should not be necessary to allow each TPM to go through its entire repertoire of keys, one at a time, before a virtualized TPM can be removed from the system. Carl indicated that he suggested this alternative early in the TCPA planning process, but it was not accepted. It does seem that while the system has advantages, in some ways it shares the problems of the alternatives. It provides privacy, but not complete privacy, not as much as the cryptographic schemes. And it provides security to the TPM issuers, but not complete security, not as much as the Privacy CA method. In this way it can be seen as a compromise. Often, compromise solutions are perceived more in terms of their disadvantages than their benefits.
Call For Papers, First International Security In Storage Workshop
Call for Papers First IEEE International Security In Storage Workshop December 11th, 2002 -- Greenbelt, Maryland, USA http://ieee-tfia.org/sisw2002 Sponsored by the IEEE Computer Society Task Force on Information Assurance and the IEEE Security In Storage Working Group The ability to create large shared storage systems in a secure manner is an area that has received little formal research or results. A comprehensive, systems approach to storage security is required if storage consolidation is to succeed. This workshop serves as an open forum to discuss storage threats, technologies, methodologies and deployment. The workshop seeks submissions from academia and industry presenting novel research on all theoretical and practical aspects of designing, building and managing secure storage systems; possible topics include, but are not limited to the following: - Cryptographic Algorithms for Storage - Cryptanalysis of Existing and Proposed Systems and Protocols - Key Management for Storage Novel Implementations - Attacks on Storage Area - Networks and Storage Systems - Insider Attack Countermeasures - Standardization Approaches - Deployment of Secure Storage Mechanisms - Defining and Defending Trust Boundaries in Storage - Security in Federated Systems - Relating Storage Security to System and Network Security - Security for Internet Storage Service Providers The goal of the workshop is to disseminate new research, and to bring together researchers and practitioners from both governmental and civilian areas. Accepted papers will be published by IEEE Press in a proceedings volume. Program Co-Chairs - James Hughes (StorageTek, USA) - Jack Cole (US Army Research Laboratory, USA) Program Committee - Donald Beaver (Seagate, USA) - Randal Burns (Johns Hopkins University, USA) - Richard Chow (USA) - Peter Haas (University of Stuttgart, Germany) - Yongdae Kim (University of Minnesota, USA) - Ben Kobler (NASA Goddard Space Flight Center, USA) - Fabio Maino (Andiamo Systems, USA) - Ethan Miller (University of California Santa Cruz, USA) - David McGrew (Cisco Systems, USA) - Andrew Odlyzko (University of Minnesota, USA) - Tatsuaki Okamoto (NTT, Japan) - Jean-Jacques Quisquater (Universite Catholique de Louvain, Belgium) - Pierangela Samarati (University of Milan, Italy) - Rodney Van Meter (Nokia, USA) Submissions Papers must list all authors and affiliations, begin with a title, a short abstract, a list of key words, and an introduction. The introduction should summarize the contributions of the paper at a level appropriate for a non-specialist reader. Papers may be submitted in ASCII text, PostScript, PDF, HTML, or Microsoft Word. Papers should be at most 15 pages in length including the bibliography, figures, and appendices (using 10pt body text and twocolumn layout). Authors are responsible for obtaining appropriate clearances. Authors of accepted papers will be asked to sign IEEEcopyright release forms. Final submissions must be in camera-ready PostScript or PDF. Authors of accepted papers must guarantee that their paper will be presented at the conference. Papers that duplicate work that any of the authors have or will publish elsewhere are acceptable for presentation at the workshop. However, only original papers will be considered for publication in the proceedings. Important Dates Paper due: October 11, 2002 Notification of acceptance: November 1, 2002 Final papers due: November 25, 2002 Workshop: December 11, 2002 Submissions and questions should be sent electronically to James Hughes <[EMAIL PROTECTED]> --
