Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

2003-12-18 Thread Pat Farrell
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

Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

2003-12-18 Thread Stefan Lucks
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

Quantum Crypto

2003-12-18 Thread Perry E . Metzger
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

FC'04: Call for Participation

2003-12-18 Thread Hinde ten Berge
Financial Cryptography '04 9-12 February 2004 Key West, Florida, USA Call for Participation Financial Cryptography is the premier international forum for education, exploration, and debate at the heart of one theme: Money and

Re: Difference between TCPA-Hardware and other forms of trust

2003-12-18 Thread John Gilmore
| 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

Re: example: secure computing kernel needed

2003-12-18 Thread David Wagner
Jerrold Leichter wrote: We've met the enemy, and he is us. *Any* secure computing kernel that can do the kinds of things we want out of secure computing kernels, can also do the kinds of things we *don't* want out of secure computing kernels. I don't understand why you say that. You can build

Re: Super-Encryption

2003-12-18 Thread Ben Laurie
[EMAIL PROTECTED] wrote: Quoting Ben Laurie [EMAIL PROTECTED]: Yes, but you could know all this from cipher2 and RSA of SHA1(message), so I still don't see what value is added by cipher1. Without cipher1, implying (iv1, RSA(SHA1(message) || key1)) it is impossible to determine the

Re: Super-Encryption

2003-12-18 Thread Amir Herzberg
Matt, in your note below you explained finally what you really want: a secure combination of encryption and signature. I explain below why your current scheme is insecure. There are simple secure designs. With Yitchak Gertner, a student, we recently proved security of one such practical

[Publicity-list]: DIMACS/PORTIA Workshop on Privacy-Preserving Data Mining

2003-12-18 Thread Linda Casals
* 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

Re: Super-Encryption

2003-12-18 Thread Amir Herzberg
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))

The RIAA Succeeds Where the CypherPunks Failed

2003-12-18 Thread John Gilmore
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