Re: Dell to Add Security Chip to PCs
On Wed, Feb 02, 2005 at 05:30:33PM +0100, Erwann ABALEA wrote: Please stop relaying FUD. You have full control over your PC, even if this Please stop relaying pro-DRM pabulum. The only reason for Nagscab is restricting the user's rights to his own files. Of course there are other reasons for having crypto compartments in your machine, but the reason Dell/IBM is rolling them out is not that. one is equiped with a TCPA chip. See the TCPA chip as a hardware security module integrated into your PC. An API exists to use it, and one if the functions of this API is 'take ownership', which has the effect of erasing it and regenerating new internal keys. Really? How interesting. Please tell us more. -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpVsHbUYu02H.pgp Description: PGP signature
Re: Dell to Add Security Chip to PCs
On Wed, 2 Feb 2005, Dan Kaminsky wrote: Uh, you *really* have no idea how much the black hat community is looking forward to TCPA. For example, Office is going to have core components running inside a protected environment totally immune to antivirus. How? TCPA is only a cryptographic device, and some BIOS code, nothing else. Does the coming of TCPA chips eliminate the bugs, buffer overflows, stack overflows, or any other way to execute arbitrary code? If yes, isn't that a wonderful thing? Obviously it doesn't (eliminate bugs and so on). Since these components are going to be managing cryptographic operations, the well defined API exposed from within the sandbox will have arbitrary content going in, and opaque content coming out. Malware goes in (there's not a executable environment created that can't be exploited), sets up shop, has no need to be stealthy due to the complete blockage of AV monitors and cleaners, and does what it wants to the plaintext and ciphertext (alters content, changes keys) before emitting it back out the opaque outbound interface. I use cryptographic devices everyday, and TCPA is not different than the present situation. No better, no worse. -- Erwann ABALEA [EMAIL PROTECTED] - RSA PGP Key ID: 0x2D0EABD5 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you help develop crypto anti-spoofing/phishing tool ?
Daniel Carosone responded to me: We develop TrustBar, a simple extension to FireFox ( Mozilla), that displays the name and logo of SSL protected sites, as well as of the CA (so users can notice the use of untrusted CA). Other merits of the idea aside, if the user knows the CA is untrusted, what's it doing in the browser's trust path? Unfortunately, users are not aware of what is a CA, and can't recognize trusted CAs. This fact is pretty obvious, but I've also validated it by appropriate user surveys (initial results already appear in the paper, see at my site http://AmirHerzberg.com; and I already have additional supporting results). However, by exposing the brand (identity, logo) of the CA, and using simple terms (`identified by`) rather than jargon (CA), we allow users to identify suspect certifications, and we allow CAs to establish their brand - which, imho, is a good thing. I find it almost a professional insult, that people go for non-crypto identification mechanisms to prevent spoofing and phishing. I mean, if we can't sell crypto for this purpose, this - imho - is a real failure. Best, Amir Herzberg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
DIMACS Workshop on Theft in E-Commerce: Content, Identity, and Service
CALL FOR PARTICIPATION** * DIMACS Workshop on Theft in E-Commerce: Content, Identity, and Service April 14 - 15, 2005 DIMACS Center, Rutgers University, Piscataway, NJ Organizers: Drew Dean, SRI International, [EMAIL PROTECTED] Markus Jakobsson, Indiana University, [EMAIL PROTECTED] Presented under the auspices of the Special Focus on Communication Security and Information Privacy. On April 14-15, 2005, we will hold a DIMACS workshop at Rutgers University, NJ, on the topic of Theft in E-Commerce. This will include but not be limited to theft of content, of identity, and of service. While theft is an old problem, the automated nature of e-commerce introduces new opportunities for traditional forms of theft, as well as entirely new forms of theft. The centrality of computation makes these threats a part of computer security. This is an area of research where we are seeing a lot of activity, and where we believe there is a great potential for valuable research contributions. While our primary interest is in defenses against theft, we are also interested in novel attacks and real data about attacks, as the defenders need to know what to defend against. For more information about the workshop location, organization, and the program (once finalized), please see: http://dimacs.rutgers.edu/Workshops/Intellectual/ We are soliciting contributions in these areas, for both long and short presentations (approx 30 minutes vs 10 minutes.) There are no proceedings, but we request that presentation material is submitted to the organizers at the time of the workshop, allowing it to be posted on the DIMACS webpage. In order to propose a talk, please contact one of the organizers, Markus Jakobsson ([EMAIL PROTECTED]) or Drew Dean ([EMAIL PROTECTED]) with a title and a short abstract by February 28, 2005 that allows us to determine whether your proposed talk will fit within the scope of the workshop. Please refer to the information on the webpage above for workshop registration, hotel reservation and travel information, and information on how to apply for financial support for those in need of this. There will be a limited number of scholarships to defray travel costs, with priority given to students and speakers who can not receive funding to attend. The workshop is sponsored by RSA Security. ** Registration: Pre-registration deadline: April 7, 2005 Please see website for registration information. * Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/Intellectual/ **PLEASE BE SURE TO PRE-REGISTER EARLY** - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you help develop crypto anti-spoofing/phishing tool ?
Michael H. Warfield wrote What Amir and Ahmad are looking at is showing the CA as part of the trust equation when the user hits a site. Some CAs will enter the user's consciousness via normal branding methods, and new ones will trigger care caution. Which is what we want - if something strange pops up, the user should take more care. How do you make it strange enough for them to give a flip when a modal dialog box won't even do it? I'd suggest you have a quick browse through their paper, skip the words and look for the graphics. It will show it faster than these 1000 words. http://www.cs.biu.ac.il/~herzbea//Papers/ecommerce/spoofing.htm In one word, it is 'branding.' In many words, it goes like this: TrustBar allows the user to 'sign off' on her favourite banking sites, which means when that cert is seen it shows a logo that the user is familiar with. It also shows the logo of the CA, which is something that the user is familiar with. http://trustbar.mozdev.org/ Note that this is not a popup with techie messages in it, but an 'advert' that appears on the chrome. On the basis of the recognition of the cert, which belongs to that site, the browser shows the bright coloured advert for the bank and for the CA. Now, a phisher, to attack that, would have to acquire a cert from the same CA, and get the user to also sign off on that cert as being her bank. Which is hard to do because she already has signed off on her bank. So what happens under attack is that the brand adverts change, and the user should notice that. This is in effect what branding is, it is a message to you to notice when you are not drinking your favourite cola brand, and to make you feel guilty or something. So, to use a little handwaving, we do know how to make the user notice that she is in a different place - by using the brand concepts that marketing as a science and art has used for many a century. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is 3DES Broken?
On Feb 2, 2005, at 1:32 PM, bear wrote: On Mon, 31 Jan 2005, Steven M. Bellovin wrote: snip re: 3des broken? [Moderator's note: The quick answer is no. The person who claims otherwise is seriously misinformed. I'm sure others will chime in. --Perry] [snip] When using CBC mode, one should not encrypt more than 2^32 64-bit blocks under a given key. [snip] whichever it is, as you point out there are other and more secure modes available for using 3DES if you have a fat pipe to encrypt. I don't want to take this down a rat-hole, but I respectfully disagree. The small block size of 3DES is also an issue with more secure modes. CCM states that only 128 but ciphers are to be used. The NIST document states For CCM, the block size of the block cipher algorithm shall be 128 bits; currently, the AES algorithm is the only approved block cipher algorithm with this block size. http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf Ferguson points out that in OCB there is a birthday at the number of packets. From the paper, Collision attacks are much easier when 64-bit block ciphers are used. Therefore, we most strongly advise never to use OCB with a 64-bit block cipher. http://csrc.nist.gov/CryptoToolkit/modes/comments/Ferguson.pdf These basis of this is that the mode loses packet security at a birthday of the number of blocks. In communications, this is 2^32 blocks, and if we assume 1k blocks, this is 4TBytes, which occurs after transferring less than 2 full DVDs. As network performance grows, this will be a very common transfer size. While 3DES is not broken, it is my opinion that the 64 bit blocksize of 3DES is not adequate for today's requirements. In this sense, it is not broken, but obsolete. Thanks jim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
