Re: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)
Peter Gutmann wrote: > Consider for example a system that uses two > authentication algorithms in case one fails, or that > has an algorithm-upgrade/rollover capability, perhaps > via downloadable plugins. At some point a device > receives a message authenticated with algorithm A > saying "Algorithm B has been broken, don't use it any > more" (with an optional side-order of "install and run > this plugin that implements a new algorithm instead"). > It also receives a message authenticated with > algorithm B saying "Algorithm A has been broken, don't > use it any more", with optional extras as before. Not so hard. True breaks occur infrequently. Those that download the scam version will find that they can *only* communicate with the scammers, so will sort things out in due course and all will be well until the next break - which will not happen for a long time, and may well never happen - unless of course one has the IEEE 802.11 working group designing the standards. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
Ben Laurie wrote: > If the problem you are trying to solve is client > authentication then client certs have some obvious > value. But if client certs are Certificate Authority centric, then they prove that so and so's true name is so and so. They don't prove that so and so is one of our gang, which is generally what people care about. A typical situation is that someone whose legal address is in the united states, wants to order some good from an entity whose physical address is China, but whose legal address is in a tax haven, for delivery to a physical address in Singapore. True names are rather low on their list of priorities. If you want to get people to use client certificates, client certificates have to do what people want, not what governments and certification authorities want. What is needed is client certificates that work like shibboleths or gang colors. Microsoft's cardspace was a try at that idea. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)
Ben Laurie writes: >It seems to me protocol designers get all excited about this because they >want to design the protocol once and be done with it. But software authors >are generally content to worry about the new algorithm when they need to >switch to it - and since they're going to have to update their software >anyway and get everyone to install the new version, why should they worry any >sooner? It's not just that, while pluggability (for transparent crypto upgrade) may sound like a fun theoretical exercise for geeks it's really a special case of the (unsolveable) secure-initialisation problem. Consider for example a system that uses two authentication algorithms in case one fails, or that has an algorithm-upgrade/rollover capability, perhaps via downloadable plugins. At some point a device receives a message authenticated with algorithm A saying "Algorithm B has been broken, don't use it any more" (with an optional side-order of "install and run this plugin that implements a new algorithm instead"). It also receives a message authenticated with algorithm B saying "Algorithm A has been broken, don't use it any more", with optional extras as before. Although you could then apply fault-tolerant design concepts to try and make this less problematic, this adds a huge amount of design complexity, and therefore new attack surface. Adding to the problems is the fact that this capability will only be exercised in extremely rare circumstances. So you have a piece of complex, error-prone code that's never really exercised and that has to sit there unused (but resisting all attacks) for years until it's needed, at which point it has to work perfectly the first time. In addition you have some nice catch-22's such as the question of how you safely load a replacement algorithm into a remote device when the existing algorithm that's required to secure the load has been broken. Compounding this even further is the innate tendency of security geeks to want to replace half the security infrastructure that you're relying on as a side- effect of any algorithm upgrade. After all, if you're replacing one of the hash algorithms then why not take the opportunity to replace the key derivation that it's used in, and the signature mechanisms, and the key management as well? This results in huge amounts of turmoil as a theoretically minor algorithm change carries over into a requirement to reimplement half the security mechanisms being used. One example of this is TLS 1.2, for which the (theoretically minor) step from TLS 1.1 to TLS 1.2 was much, much bigger than the change from SSL to TLS, because the developers redesigned significant portions of the security mechanisms as a side-effect of introducing a few new hash algorithms. As a result, TLS 1.2 adoption has lagged for years after the first specifications became available. Thor Lancelot Simon writes: >the exercise of recovering from new horrible problems with SHA1 would be >vastly simpler, easier, and far quicker What new horrible problems in SHA1 (as it's used in SSL/TLS)? What old horrible problems, for that matter? The only place I can think of offhand where it's used in a manner where it might be vulnerable is for DSA sigs, and how many of those have you seen in the wild? Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)
On Aug 25, 2009, at 4:44 AM, Ben Laurie wrote: Perry E. Metzger wrote: Yet another reason why you always should make the crypto algorithms you use pluggable in any system -- you *will* have to replace them some day. In order to roll out a new crypto algorithm, you have to roll out new software. So, why is anything needed for "pluggability" beyond versioning? It seems to me protocol designers get all excited about this because they want to design the protocol once and be done with it. But software authors are generally content to worry about the new algorithm when they need to switch to it - and since they're going to have to update their software anyway and get everyone to install the new version, why should they worry any sooner? I have no idea, myself. I have said many times effectively what you said, and there's always the same hand-wringing. I believe that it boils down to this: They aren't software engineers and we are. We've designed paramaterized or (that's or, not xor) versioned protocols before. We've done upgrades. They will inevitably bring up downgrade attacks, but come on. It is a truism that there is more stupidity than malice in the world and if you stupid-proof your protocol, you've also malice-proofed it. And yes, yes, one has to be thorough in your design of plugable system. I, too, can come up with a scenario where a simple version number is not enough. It's just a software engineering problem, and you and I and the other software engineers know how to do software engineering. I think that again, they haven't in general deployed software to a population large enough to contain stupid people. If they have deployed it to stupid people, they haven't had the attitude that stupidity is a fact of life and has to be fixed in the software, not the person. And after boiling it down, let me go further and reduce it to a sticky, bitter sauce: They don't believe it's important. They so believe the naive simple-is- better line that they end up believing that brittle is better than resilient. They're so enamored with the aphorism that you can make something so simple it's secure or so complex it's secure that they forget the aphorism that you should make things as simple as possible and no simpler. They're not engineers, so for them, upgrades are free. Therefore brittle is simpler than resilient. Jon - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: a crypto puzzle about digital signatures and future compatibility
> This at least suggests that the v1.7 readers need to check *all* > hashes that are offered and raise an alarm if some verify and others > don't. Is that good enough? Isn't that what SSL/TLS does? /r$ -- STSM, DataPower CTO WebSphere Appliance Architect http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
There is an approach to this that currently is being standardized in the IETF PKIX group. The certificate image work (draft-ietf-pkix-certimage-01.txt) The current draft is available from: tools.ietf.org/html/draft-ietf-pkix-certimage-01 The technical idea behind this is very simple. Instead of trying to break our back in an attempt to decode the extremely underspecified attributes in a certificate and instead of trying to come up with sensible display labels for each attribute (instead of CN, C, O, OU and other useless abbreviations used today) This specification lets the issuer associate a complete display ready image of the certificate that contains the essential information a user would be interested to see. >From a UI perspective, this turns a close to impossible task to a simple task as the client, given that the issuing CA is trusted, simply displays this certificate image. Major certificate issuers (no names) have expressed substantial interest in issuing certificates with this feature if there are clients that are interested to make use of them in their UI. Stefan Santesson AAA-sec.com > -Original Message- > From: owner-cryptogra...@metzdowd.com [mailto:owner-cryptogra...@metzdowd.com] > On Behalf Of Ben Laurie > Sent: Wednesday, August 05, 2009 9:59 AM > To: Cryptography > Subject: Client Certificate UI for Chrome? > > So, I've heard many complaints over the years about how the UI for > client certificates sucks. Now's your chance to fix that problem - > we're in the process of thinking about new client cert UI for Chrome, > and welcome any input you might have. Obviously fully-baked proposals > are more likely to get attention than vague suggestions. > > I imagine I may well hear "what about the UI around server > certificates?" - fair enough, feel free, and I'll see what I can do. > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
a crypto puzzle about digital signatures and future compatibility
Folks: My brother Nathan Wilcox asked me in private mail about protocol versioning issues. (He was inspired by this thread on cryptography@metzdowd.com [1, 2, 3]). After rambling for a while about my theories and experiences with such things, I remembered this vexing "future-compatibility" issue that I still don't know how to solve: Here is a puzzle for you (I don't know the answer). Would it be a reasonable safety measure to deploy a Tahoe-LAFS v1.6, which used SHA-2 but didn't know how to use SHA-3 (because it hasn't been defined yet), and then later deploy a Tahoe-LAFS v1.7, which did know how to use SHA-3, and have v1.7 writers produce new files which v1.6 readers can integrity-check (using SHA-2) and also v1.7 readers can integrity-check (using SHA-3)? So far this seems like an obvious win, but then you have to say what if, after we've deployed v1.7, someone posts a perl script to sci.crypt which produces second-pre-images for SHA-2 (but not SHA-3)? Then writers who are using Tahoe-LAFS v1.7 really want to be able to *stop* producing files which v1.6 readers will trust based on SHA-2, right? And also, even if that doesn't happen and SHA-2 is still believed to be reliable, then what if some sneaky v1.7 user hacks his v1.7 software to make two different files, sign one of them with SHA-2 and the other wish SHA-3, and then put both hashes into a single immutable file cap and give it to a v1.6 reader, asking him to inspect the file and then pass it on to his trusted, v1.7-using, partner? Hm... This at least suggests that the v1.7 readers need to check *all* hashes that are offered and raise an alarm if some verify and others don't. Is that good enough? :-/ Regards, Zooko [1] http://www.mail-archive.com/cryptography@metzdowd.com/msg10791.html [2] http://www.mail-archive.com/cryptography@metzdowd.com/msg10807.html [3] http://www.mail-archive.com/cryptography@metzdowd.com/msg10805.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmann wrote: > More generally, I can't see that implementing client-side certs gives you much > of anything in return for the massive amount of effort required because the > problem is a lack of server auth, not of client auth. If I'm a phisher then I > set up my bogus web site, get the user's certificate-based client auth > message, throw it away, and report successful auth to the client. The browser > then displays some sort of indicator that the high-security certificate auth > was successful, and the user can feel more confident than usual in entering > their credit card details. All you're doing is building even more substrate > for phishing attacks. > > Without simultaneous mutual auth, which -SRP/-PSK provide but PKI doesn't, > you're not getting any improvement, and potentially just making things worse > by giving users a false sense of security. I certainly agree that if the problem you are trying to solve is server authentication, then client certs don't get you very far. I find it hard to feel very surprised by this conclusion. If the problem you are trying to solve is client authentication then client certs have some obvious value. That said, I do tend to agree that mutual auth is also a good avenue to pursue, and the UI you describe fits right in with Chrome's UI in other areas. Perhaps I'll give it a try. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
