RE: Dell to Add Security Chip to PCs
"Tyler Durden" <[EMAIL PROTECTED]> writes: >That "chip"...is it likely to be an ASIC or is there already such a thing as >a security network processor? (ie, a cheaper network processor that only >handles security apps, etc...) > >Or could it be an FPGA? Neither. Currently they've typically been smart-card cores glued to the MB and accessed via I2C/SMB. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Can you help develop crypto anti-spoofing/phishing tool ?
On Thu, Feb 03, 2005 at 03:57:06AM +, Ian G wrote: > Daniel Carosone wrote: > > >Other merits of the idea aside, if the user knows the CA is untrusted, > >what's it doing in the browser's trust path? > > The user doesn't select the trust path, the browser manufacturer > does. > [..] > How do you suggest the user deals with this list? Given that the > average list has 100+ entries... That was a very large part of my point.. :) [As an aside, pruning the ca trust list is a common hardening recommendation for those building corporate SOE lockdowns and similar platforms, where the organisation is making a trust decision for the user differently than the browser maker is.] > 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. I appreciate what they're trying to do, and think it has merits I'm not in any way trying to diminish. I just don't see a great history of success with the general user populace reading and thinking and reacting properly to security popup warnings of any kind. The smart, security-conscious and PKI-aware users who can recognise good CA's from bad will not be falling for phishing scams in the first place. The user who's already some way down the path of falling for one is unlikely to make a better choice even when you give them another popup, though there's a chance it might help at least somebody, and we should surely take that chance. If the users could make appopriate CA trust choices, having the browser manufacturers prepopulate a list of potentially-trusted CAs, with a popup asking for a trust approval the first time a site presents a cert in that path, might work. Likewise, something that remembered cert fingerprints and CA path for "known trusted sites", vaguely a'la ssh, and popped up an appropriate warning when something changes, might work for such a smart user. Even so, most of the popups they see are going to be for legitimate cases of cert renewals or ICA changes or server load-balancers or .. whatever else. What's really needed is a way to help them make fewer, better decisions, rather than more decisions. Wish I knew how.. -- Dan. pgpCYvWQcznwt.pgp Description: PGP signature
RE: Dell to Add Security Chip to PCs
On Wed, 2 Feb 2005, Erwann ABALEA wrote: On Wed, 2 Feb 2005, Trei, Peter wrote: Seeing as it comes out of the TCG, this is almost certainly the enabling hardware for Palladium/NGSCB. Its a part of your computer which you may not have full control over. Please stop relaying FUD. You have full control over your PC, even if this 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. -- Erwann ABALEA <[EMAIL PROTECTED]> - RSA PGP Key ID: 0x2D0EABD5 After TCPA systems are the only systems for sale at CompUSA, how long before this off switch is removed? All agree we live in a time of crisis; at any moment MICROSOFT/RIAA/MPAA/HOMSECPOL/CONGREGATIONOFMARTYRS may require of all of us an attestation of faith and obedience greater and more secure than present hardware can convincingly convey. oo--JS. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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 http://leitl.org";>leitl __ 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
>>> Ian G <[EMAIL PROTECTED]> 2/2/2005 6:38:46 PM >>> > I'm just curious on this point. I haven't seen much > to indicate that Microsoft and others are ready > for a nymous, tradeable software assets world. No, and neither are corporate customers, to a large extent. Accountability is, in fact, a treasured property of business computing. Lack of accountability creates things like Enron, Anderson Consulting, Oil-for-Food scams, and the missing 9 billion dollars or so of reconstruction aid. It's the fuel that propells SPAM, graft, and identity theft. What I've not seen is much work providing accountability for anonymous transactions. It's a shame people persist in thinking a single solution will satify everyone, as though computing was somehow different from everything else in life. Ed - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Dell to Add Security Chip to PCs
Bonjour, On Wed, 2 Feb 2005, Erwann ABALEA wrote: > On Wed, 2 Feb 2005, Trei, Peter wrote: > > > Seeing as it comes out of the TCG, this is almost certainly > > the enabling hardware for Palladium/NGSCB. Its a part of > > your computer which you may not have full control over. > > Please stop relaying FUD. You have full control over your PC, even if this > 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. I've read your objections. Maybe I wasn't clear. What's wrong in installing a cryptographic device by default on PC motherboards? I work for a PKI 'vendor', and for me, software private keys is a nonsense. How will you convice "Mr Smith" (or Mme Michu) to buy an expensive CC EAL4+ evaluated token, install the drivers, and solve the inevitable conflicts that will occur, simply to store his private key? You first have to be good to convice him to justify the extra depense. If a standard secure hardware cryptographic device is installed by default on PCs, it's OK! You could obviously say that Mr Smith won't be able to move his certificates from machine A to machine B, but more than 98% of the time, Mr Smith doesn't need to do that. Installing a TCPA chip is not a bad idea. It is as 'trustable' as any other cryptographic device, internal or external. What is bad is accepting to buy a software that you won't be able to use if you decide to claim your ownership... Palladium is bad, TCPA is not bad. Don't confuse the two. -- Erwann ABALEA <[EMAIL PROTECTED]> - RSA PGP Key ID: 0x2D0EABD5 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Dell to Add Security Chip to PCs
On Thu, 3 Feb 2005, Jay Sulzberger wrote: > On Wed, 2 Feb 2005, Erwann ABALEA wrote: > > > On Wed, 2 Feb 2005, Trei, Peter wrote: > > > >> Seeing as it comes out of the TCG, this is almost certainly > >> the enabling hardware for Palladium/NGSCB. Its a part of > >> your computer which you may not have full control over. > > > > Please stop relaying FUD. You have full control over your PC, even if this > > 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. > > After TCPA systems are the only systems for sale at CompUSA, how long > before this off switch is removed? All agree we live in a time of crisis; > at any moment MICROSOFT/RIAA/MPAA/HOMSECPOL/CONGREGATIONOFMARTYRS may > require of all of us an attestation of faith and obedience greater and more > secure than present hardware can convincingly convey. And do you seriously think that "you can't do that, it's technically not possible" is a good answer? That's what you're saying. For me, a better answer is "you don't have the right to deny my ownership". -- Erwann ABALEA <[EMAIL PROTECTED]> - RSA PGP Key ID: 0x2D0EABD5 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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 ?
On Thu, 2005-02-03 at 03:57 +, Ian G wrote: > Daniel Carosone wrote: > >On Wed, Feb 02, 2005 at 10:11:54PM +0200, Amir Herzberg wrote: > >>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? > The user doesn't select the trust path, the > browser manufacturer does. It is a bug to > think that the user trusts the CA. She > doesn't even know their names, let alone > whether she would trust them, in the current > system. Worse, we've even got malware/spyware that's silently installing new root CA's when they install. And on Windows, it's not in the browser (unless it's Mozilla/Firefox, I think) it's in the OS itself that's maintaining the root CA list. But, I also agree that I doubt many users will know or pay attention to the CA. Trust them? Most don't even know, or care, what a CA is. They already punch through the dialogs, now, when faced with certificate warnings. Even people, who should know better, just click that little check box saying "don't show this warning again" for a site they know nothing about and just ignore the fact that the cert is virtually worthless. Showing the CA is not going to help that. > >If we're going to assume users are capable of making this decision, we > >should make it easier for them to express that decision properly > >within the existing mechanism. Big BIG if. I can't make that assumption at all. I've seen reality and reality is that they're just going to instinctively hit "OK" and be annoyed that they had to even see that dialog. > The existing method is that the root list is > chosen by methods arcane and obscure, > which may have to do with user benefit, > or may not. Either way, the user is given > a root list that is long and chosen and hidden. > How do you suggest the user deals with > this list? Given that the average list has > 100+ entries... Now, I have not see this. The stock "ca-bundle" in Linux is about 60 certs (and some orgs have more than one cert). Still, that's a lot of certs and a lot of organizations to know who to trust and who to not and most users are just not going to be troubled. > 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? > iang Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: Is 3DES Broken?
>From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
>Sent: Feb 2, 2005 1:39 PM
>To: bear <[EMAIL PROTECTED]>
>Cc: Aram Perez <[EMAIL PROTECTED]>, Cryptography
>Subject: Re: Is 3DES Broken?
...
>>I think you meant ECB mode?
>No, I meant CBC -- there's a birthday paradox attack to watch out for.
Yep. In fact, there's a birthday paradox problem for all the standard chaining
modes at around 2^{n/2}.
For CBC and CFB, this ends up leaking information about the XOR of a couple
plaintext blocks at a time; for OFB and counter mode, it ends up making the
keystream distinguishable from random. Also, most of the security proofs for
block cipher constructions (like the secure CBC-MAC schemes) limit the number
of blocks to some constant factor times 2^{n/2}.
> --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
--John Kelsey
-
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: Dell to Add Security Chip to PCs
Erwann ABALEA > On Wed, 2 Feb 2005, Trei, Peter wrote: > > > Seeing as it comes out of the TCG, this is almost certainly > > the enabling hardware for Palladium/NGSCB. Its a part of > > your computer which you may not have full control over. > > Please stop relaying FUD. You have full control > over your PC, even if this 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. Congratulations on your new baby. Working in the security business, paranoia is pretty much a job requirement. "What's the worst that could happen?" is taken seriously. The best that can happen with TCPA is pretty good - it could stop a lot of viruses and malware, for one thing. But the worst that can happen with TCPA is pretty awful. It could easily be leveraged to make motherboards which will only run 'authorized' OSs, and OSs which will run only 'authorized' software. And you, the owner of the computer, will NOT neccesarily be the authority which gets to decide what OS and software the machine can run. If you 'take ownership' as you put it, the internal keys and certs change, and all of a sudden you might not have a bootable computer anymore. Goodbye Linux. Goodbye Freeware. Goodbye independent software development. It would be a very sad world if this comes to pass. Peter Trei - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Can you help develop crypto anti-spoofing/phishing tool ?
Amir Herzberg wrote: 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). I think it is fair to say that this extension fixes some glitches in the deployment of SSL/TLS, i.e. in the most important practical cryptographic solution. Yes, because it makes the user notice what CAs the _browser_ has decided the user _automatically_ accepts [1]. But there is a caveat. Can you trust what trustbar shows you? And, of course, knowing what CA is being used is also possible without trustbar but requires a couple mouseclicks. Wouldn't it be better if Firefox/Mozilla simply put the name of the CA next to the lock icon? Cheers, Ed Gerck [1] see corresponding flaws noted in http://nma.com/papers/certover.pdf - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Dell to Add Security Chip to PCs
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). TCPA eliminates external checks and balances, such as antivirus. As the user, I'm not trusted to audit operations within a TCPA-established sandbox. Antivirus is essentially a user system auditing tool, and TCPA-based systems have these big black boxes AV isn't allowed to analyze. Imagine a sandbox that parses input code signed to an API-derivable public key. Imagine an exploit encrypted to that. Can AV decrypt the payload and prevent execution? No, of course not. Only the TCPA sandbox can. But since AV can't get inside of the TCPA sandbox, whatever content is "protected" in there is quite conspicuously unprotected. It's a little like having a serial killer in San Quentin. You feel really safe until you realize...uh, he's your cellmate. I don't know how clear I can say this, your threat model is broken, and the bad guys can't stop laughing about it. I use cryptographic devices everyday, and TCPA is not different than the present situation. No better, no worse. I do a fair number of conferences with exploit authors every few months, and I can tell you, much worse. "Licking chops" is an accurate assessment. Honestly, it's a little like HID's "radio barcode number" concept of RFID. Everyone expects it to get everywhere, then get exploited mercilessly, then get ripped off the market quite painfully. --Dan - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Dell to Add Security Chip to PCs
Erwann ABALEA <[EMAIL PROTECTED]> writes: >I've read your objections. Maybe I wasn't clear. What's wrong in installing a >cryptographic device by default on PC motherboards? I work for a PKI 'vendor', >and for me, software private keys is a nonsense. A simple crypto device controlled by the same software is only slightly less nonsensical. That is, the difference between software-controlled keys and a device controlling the keys that does anything the software tells it to is negligible. To get any real security you need to add a trusted display, I/O system, clock, and complete crypto message-processing capability (not just "generate a signature" like the current generation of smart cards do), and that's a long way removed from what TCPA gives you. >You could obviously say that Mr Smith won't be able to move his certificates >from machine A to machine B, but more than 98% of the time, Mr Smith doesn't >need to do that. Yes he will. That is, he may not really need to do it, but he really, really wants to do it. Look at the almost-universal use of PKCS #12 to allow people to spread their keys around all over the place - any product aimed at a mass- market audience that prevents key moving is pretty much dead in the water. >Installing a TCPA chip is not a bad idea. The only effective thing a TCPA chip gives you is a built-in dongle on every PC. Whether having a ready-made dongle hardwired into every PC is a good or bad thing depends on the user (that is, the software vendor using the TCPA device, not the PC user). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Using TCPA
On Thu, Feb 03, 2005 at 11:51:57AM -0500, Trei, Peter wrote: > It could easily be leveraged to make motherboards > which will only run 'authorized' OSs, and OSs > which will run only 'authorized' software. [..] > If you 'take ownership' as you put it, the internal > keys and certs change, and all of a sudden you > might not have a bootable computer anymore. I have an application for exactly that behaviour. It's a secure appliance. Users don't run code on it. It needs to be able to verify that it's running the authorized OS and software and that new software is authorized. (it does it already, but a TCPA chip might do it better). So a question for the TCPA proponents (or opponents): how would I do that using TCPA? Eric - 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: [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]
