Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
At 07:02 PM 12/15/2003 -0500, Jerrold Leichter wrote: However, this advantage is there only because there are so few smart cards, and so few smart card enabled applications, around. A software only, networked smart card would solve the chicken and egg problem. One such solution is Tamper resistant method and apparatus, [Ellison], USPTO 6,073,237 (Do a patent number search at http://www.uspto.gov/patft/index.html) Carl invented this as an alternative to Smartcards back in the SET development days. Pat Pat Farrell [EMAIL PROTECTED] http://www.pfarrell.com - 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)
On Mon, 15 Dec 2003, Jerrold Leichter wrote: | This is quite an advantage of smart cards. However, this advantage is there only because there are so few smart cards, and so few smart card enabled applications, around. Strangely enough, Carl Ellison assumed that you would have at most one smart card, anyway. I'd rather think you are right, here. Really secure mail *should* use its own smart card. When I do banking, do I have to remove my mail smart card? Encryption of files on my PC should be based on a smart card. Do I have to pull that one out? Does that mean I can't look at my own records while I'm talking to my bank? If I can only have one smart card in my PC at a time, does that mean I can *never* cut and paste between my own records and my on-line bank statement? To access my files and my employer's email system, do I have to have to trust a single smart card to hold both sets of secrets? I agree with you: A good compromise between security and convenience is an issue, when you are changing between different smart cards. E.g., I could imagine using the smart card *once* when logging into my bank account, and then only needing it, perhaps, to authorise a money transfer. This is a difficult user interface issue, but something we should be able to solve. One problem of TCPA is the opposite user interface issue -- the user has lost control over what is going on. (And I believe that this originates much of the resistance against TCPA.) Ultimately, to be useful a trusted kernel has to be multi-purpose, for exactly the same reason we want a general-purpose PC, not a whole bunch of fixed- function appliances. Whether this multi-purpose kernel will be inside the PC, or a separate unit I can unplug and take with me, is a separate issue. Give the current model for PC's, a separate key is probably a better approach. Agreed! However, there are already experiments with PC in my pocket designs: A small box with the CPU, memory, and disk, which can be connect to a small screen to replace a palmtop, or into a unit with a big screen, a keyboard, etc., to become my desktop. Since that small box would have all my data, it might make sense for it to have the trusted kernel. (Of course, I probably want *some* part to be separate to render the box useless is stolen.) Agreed again! | There is nothing wrong with the idea of a trusted kernel, but trusted | 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. Actually, all users have to trust the owner (or rather the sysadmin). The key words are have to trust! As you wrote somewhere below: Part of the issue with TCPA is that the providers of the kernel that we are all supposed to trust blindly are also going to be among those who will use it heavily. Given who those producers are, that level of trust is unjustifiable. I entirely agree with you! | More than ten years ago, Chaum and Pedersen [...] |+---+ +-+ +---+ || Outside World | - | Your PC | - | TCPA-Observer | |+---+ +-+ +---+ | | TCPA mixes Your PC and the observer into one trusted kernel and is | thus open to abuse. I remember looking at this paper when it first appeared, but the details have long faded. It's an alternative mechanism for creating trust: Instead of trusting an open, independently-produced, verified implementation, it uses cryptography to construct walls around a proprietary, non-open implementation that you have no reason to trust. Please re-read the paper! First, it is not a mechanism for *creating* trust. It is rather a trust-avoidance mechanism! You are not trusting the observer at all, and you don't need to. The outsider is not trusting you or your PC at all, and she donesn't need to. Second, how on earth did you get the impression that Chaum/Pedersen is about proprietary non open implenentations? Nothing stops people from producing independent and verified implementations. As a matter of fact, since people can concentrate on writing independent and verified implementations for the sofware on Your PC, providing an independently produced and verified implementation woud be much much simpler than ever providing such an implementation for the TCPA hardware. Independent implementations of the observer's soft- and hardware are simpler than in the case of TCPA as well, but this is a minor issue. You don't need to trust the observer, so you don't care about independent and verified implementations. With a Chaum/Pedersen style scheme, the
Quantum Crypto
There have been more press releases about quantum crypto products lately. I will summarize my opinion simply -- even if they can do what is advertised, they aren't very useful. They only provide link security, and at extremely high cost. You can easily just run AES+HMAC on all the bits crossing a line and get what is for all practical purposes similar security, at a fraction of the price. The problem in security is not that we don't have crypto technologies that are good enough -- our algorithms are fine. Our real problem is in much more practical things like getting our software to high enough assurance levels, architectural flaws in our systems, etc. Thus, Quantum Crypto ends up being a very high priced way to solve problems that we don't have. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Publicity-list]: DIMACS/PORTIA Workshop on Privacy-Preserving Data Mining
* DIMACS/PORTIA Workshop on Privacy-Preserving Data Mining March 15 - 16, 2004 DIMACS Center, Rutgers University, Piscataway, NJ Organizers: Cynthia Dwork, Microsoft, dwork at microsoft.com Benny Pinkas, HP Labs, benny.pinkas at hp.com Rebecca Wright, Stevens Institute of Technology, rwright at cs.stevens-tech.edu Presented under the auspices of the Special Focus on Communication Security and Information Privacy, and the PORTIA project. This workshop and working group will bring together researchers and practitioners in cryptography, data mining, and other areas to discuss privacy-preserving data mining. The workshop sessions on March 15 and 16, 2004 will consist of invited talks and discussion. March 17, 2004 will be a working group of invited participants to identify and explore approaches that could serve as the basis for more sophisticated algorithms and implementations than presently exist, and to discuss directions for further research and collaboration. Both the workshop and working group will investigate the construction and exploitation of private databases, e.g. * Merging information from multiple data sets in a consistent, secure, efficient and privacy-preserving manner; * Sanitizing databases to permit privacy-preserving public study. In a wide variety of applications it would be useful to be able to gather information from several different data sets. The owners of these data sets may not be willing, or legally able, to share their complete data with each other. The ability to collaborate without revealing information could be instrumental in fostering inter-agency collaboration. Particular topics of interest include: * Secure multi-party computation. This is a very general and well-studied paradigm that unfortunately has not been used in practice so far. We will investigate ways to make it more efficient and encourage its deployment. * Statistical techniques such as data swapping, post-randomization, and perturbation. * Articulation of different notions and aspects of privacy. * Tradeoffs between privacy and accuracy. * Architectures that facilitate private queries by a (semi-trusted) third party. * Methods for handling different or incompatible formats, and erroneous data. We will investigate ideas from dimension reduction, clustering and searching strategy. ** Registration Fees: (Pre-registration deadline: March 8, 2004) Regular Rate Preregister before deadline $120/day After preregistration deadline $140/day Reduced Rate* Preregister before deadline $60/day After preregistration deadline $70/day Postdocs Preregister before deadline $10/day After preregistration deadline $15/day DIMACS Postdocs $0 Non-Local Graduate Undergraduate students Preregister before deadline $5/day After preregistration deadline $10/day Local Graduate Undergraduate students $0 (Rutgers Princeton) DIMACS partner institution employees** $0 DIMACS long-term visitors*** $0 Registration fee to be collected on site, cash, check, VISA/Mastercard accepted. Our funding agencies require that we charge a registration fee during the course of the workshop. Registration fees include participation in the workshop, all workshop materials, breakfast, lunch, breaks and any scheduled social events (if applicable). * College/University faculty and employees of nonprofit and government organizations will automatically receive the reduced rate. Other participants may apply for a reduction of fees. They should email their request for the reduced fee to the Workshop Coordinator at [EMAIL PROTECTED] Include your name, the Institution you work for, your job title and a brief explanation of your situation. All requests for reduced rates must be received before the pre-registration deadline. You will promptly be notified as to the decision about it. ** Fees for employees of DIMACS partner institutions are waived. DIMACS partner institutions are: Rutgers University, Princeton University, ATT Labs - Research, Bell Labs, NEC Laboratories America and Telcordia Technologies. Fees for employees of DIMACS affiliate members Avaya Labs, IBM Research and Microsoft Research are also waived. ***DIMACS long-term visitors who are in residence at DIMACS for two or more weeks inclusive of dates of workshop. * Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/Privacy/ **PLEASE BE SURE TO PRE-REGISTER EARLY** - The Cryptography Mailing List
Re: Super-Encryption
At 16:36 17/12/2003, Matt wrote: Ben, Amir, et.al. I see that cipher1 has no transparent value. Therefore, the XML-Encrypted message see ( http://www.w3.org/TR/xmlenc-core/ ) must transport (1) symmetric_IV (2) Sign_RSA_Receiver_PK(symmetric_Key) (3) cipher (4) Sign_RSA_Sender(SHA1(message)) This is still not very good. Comments: a. In (2) you obviously mean Encrypt_RSA not Sign_RSA b. In (4) you again send the hash of the plaintext in the clear. As I explained in my previous note, this is insecure, e.g. if plaintext is taken from a reasonably sized set (which is common), attacker can find the plaintext by hashing all the possible values. There are two fixes to this: sign the encrypted message and public key (which we proved secure for most PKCS including RSA) or encrypt the signed message (which may be vulnerable to Krawczyk/Bleichenbacher's attacks). c. Notice also (again as I wrote before...) that you don't achieve your stated goal of identifying the intended receiver. This is also solved if you sign the ciphertext and the receiver's public key, or simply sign the identity of the receiver. Anyway, I am repeating myself, so... Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Lectures: http://www.cs.biu.ac.il/~herzbea/book.html Homepage: http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The RIAA Succeeds Where the CypherPunks Failed
From: [EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 12:29 PM To: [EMAIL PROTECTED] Subject: [NEC] #2.12: The RIAA Succeeds Where the CypherPunks Failed NEC @ Shirky.com, a mailing list about Networks, Economics, and Culture Published periodically / #2.12 / December 17, 2003 Subscribe at http://shirky.com/nec.html Archived at http://shirky.com Social Software weblog at http://corante.com/many/ In this issue: - Introduction - Essay: The RIAA Succeeds Where the Cypherpunks Failed Also at http://www.shirky.com/writings/riaa_encryption.html - Worth Reading: - GrokLaw: MVP of the SCO Wars - Tom Coates Talks With A Slashdot Troller * Introduction === The end of another year. Thank you all for reading. See you in January. -clay * Essay == The RIAA Succeeds Where the Cypherpunks Failed http://www.shirky.com/writings/riaa_encryption.html For years, the US Government has been terrified of losing surveillance powers over digital communications generally, and one of their biggest fears has been broad public adoption of encryption. If the average user were to routinely encrypt their email, files, and instant messages, whole swaths of public communication currently available to law enforcement with a simple subpoena (at most) would become either unreadable, or readable only at huge expense. The first broad attempt by the Government to deflect general adoption of encryption came 10 years ago, in the form of the Clipper Chip [http://www.epic.org/crypto/clipper/]. The Clipper Chip was part of a proposal for a secure digital phone that would only work if the encryption keys were held in such a way that the Government could get to them. With a pair of Clipper phones, users could make phone calls secure from everyone except the Government. Though opposition to Clipper by civil liberties groups was swift and extreme [1] the thing that killed it was work by Matt Blaze, a Bell Labs security researcher, showing that the phone's wiretap capabilities could be easily defeated [2], allowing Clipper users to make calls that even the Government couldn't decrypt. (Ironically, ATT had designed the phones originally, and had a contract to sell them before Blaze sunk the project.) [2] http://cpsr.org/cpsr/privacy/crypto/clipper/clipper_nist_escrow_comments / [3] http://www.interesting-people.org/archives/interesting-people/199406/msg 6.html The Government's failure to get the Clipper implemented came at a heady time for advocates of digital privacy -- the NSA was losing control of cryptographic products, Phil Zimmerman had launched his Pretty Good Privacy (PGP) email program, and the Cypherpunks, a merry band of crypto-loving civil libertarians, were on the cover of [http://www.wired.com/wired/archive/1.02/crypto.rebels.html] the second issue of Wired. The floodgates were opening, leading to... ...pretty much nothing. Even after the death of Clipper and the launch of PGP, the Government discovered that for the most part, users didn't _want_ to encrypt their communications. The single biggest barrier to the spread of encryption has turned out to be not control but apathy. Though business users encrypt sensitive data to hide it from one another, the use of encryption to hide private communications from the Government has been limited mainly to techno-libertarians and a small criminal class. The reason for this is the obvious one: the average user has little to hide, and so hides little. As a result, 10 years on, e-mail is still sent as plain text, files are almost universally unsecured, and so on. The Cypherpunk fantasy of a culture that routinely hides both legal and illegal activities from the state has been defeated by a giant distributed veto. Until now. It may be time to dust off that old issue of Wired, because the RIAA is succeeding where 10 years of hectoring by the Cypherpunks failed. When shutting down Napster turned out to have all the containing effects of stomping on a tube of toothpaste, the RIAA switched to suing users directly. This strategy has worked much better than shutting down Napster did, convincing many users to stop using public file sharing systems, and to delete MP3s from their hard drives. However, to sue users, they had to serve a subpoena, and to do that, they had to get their identities from the user's internet service providers. Identifying those users has had a second effect, and that's to create a real-world version of the scenario that drove the invention of user-controlled encryption in the first place. Whitfield Diffie, inventor of public key encryption [http://www.webopedia.com/TERM/P/public_key_cryptography.html], the strategy that underlies most of today's cryptographic products, saw the problem as a version of Who will guard the guardians? In any system where a user's
