Re: Crypto Craft Knowledge
Cat Okita wrote: On Sat, 21 Feb 2009, Peter Gutmann wrote: This points out an awkward problem though, that if you're a commercial vendor and you have a customer who wants to do something stupid, you can't afford not to allow this. While my usual response to requests to do things insecurely is If you want to shoot yourself in the foot then use CryptoAPI, I can only do this because I care more about security than money. For any commercial vendor who has to put the money first, this isn't an option. That's not entirely true -- even commercial vendors have things like ongoing support to consider, and some customers just cost more money than they're worth. Furthermore, its entirely simplistic to suggest that money first == do any fool thing a customer demands. Some businesses do actually care about their reputation, even if only because they believe that will make them more money in the long run. Plus, even the most accommodating company will draw the line somewhere - not every foolish thing is profitable, even if a customer wants it. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto Craft Knowledge
On Tue, 17 Feb 2009, James Hughes wrote: I find this conversation off the point. Consider other trades like woodworking. There is no FAQ that can be created that would be applicable to building a picture frame, dining room table or a covered bridge. A FAQ for creating a picture frame would be possible, but this is not the FAQ that is being discussed. You're thinking at the wrong level. There are definitely FAQs that are applicable to building a picture frame, a dining room table, or a covered bridge. Woodworking FAQs can (and do) exist to teach basic skills, like sawing and measuring wood, different ways to join bits of wood together, and what types of join are most appropriate for what type of task. Further, there are discussions about things like load and stress, and what designs and materials are best suited to what applications. The same applies for implementing crypto -- teach the building blocks, issues and judgement points required for good understanding and implementation. Ultimately it doesn't matter if they're building a picture frame, a dining room table, or a covered bridge, as you've put it -- the skills, materials and judgement of what to use where are what matters. cheers! == A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto Craft Knowledge
On Sat, 21 Feb 2009, Peter Gutmann wrote: This points out an awkward problem though, that if you're a commercial vendor and you have a customer who wants to do something stupid, you can't afford not to allow this. While my usual response to requests to do things insecurely is If you want to shoot yourself in the foot then use CryptoAPI, I can only do this because I care more about security than money. For any commercial vendor who has to put the money first, this isn't an option. That's not entirely true -- even commercial vendors have things like ongoing support to consider, and some customers just cost more money than they're worth. cheers! == A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto Craft Knowledge
Ben Laurie b...@links.org writes: I totally agree, and this is the thinking behind the Keyczar project ( http://www.keyczar.org/): If we're allowed to do self-promotion I'll have to mention cryptlib, which had as one of its principal design goals what was later stated by Ian Grigg as there should only be one mode and that is secure. With cryptlib you have to work very, very hard to do things insecurely (generally by resorting to calling very low-level functions that the docs contain all sorts of dire warnings about), and some things just can't be done at all, plaintext key export being one really major sticking point that I get no end of complaints about (if you really want the gory details you can get them at either http://researchspace.auckland.ac.nz/handle/2292/2310 or at http://www.springer.com/computer/security+and+cryptology/book/978-0-387-95387-8 for a newer, cleaned-up version). This points out an awkward problem though, that if you're a commercial vendor and you have a customer who wants to do something stupid, you can't afford not to allow this. While my usual response to requests to do things insecurely is If you want to shoot yourself in the foot then use CryptoAPI, I can only do this because I care more about security than money. For any commercial vendor who has to put the money first, this isn't an option. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto Craft Knowledge
Stephan Neuhaus wrote: Yes, there's a need for a crypto practices FAQ to which one can refer. I disagree because you cannot force developers to read (and understand) these FAQs. Instead, there is a need for APIs that are difficult to use in an insecure way. For example, Peter Gutmann's cryptlib makes it intentionally hard to get at private key material because of precisely this issue. Also, I believe, cryptlib does not allow RSA in anything but ECB mode, because doing so means the developer is seriously on the wrong track here. This is a good point, and it reminds me of this presentation from Rusty Russell on levels of Linux kernel interfaces. See http://ozlabs.org/~rusty/ols-2003-keynote/img39.html and following. The main issue I see is how do you force the developer to adopt your library and corresponding API? A secondary issue is what do you do if there isn't a suitable library and API yet available? In cases where you can't (yet) provide a simple use cryptlib response, a crypto practices FAQ would be helpful for pointing out common problems and explaining them well. I've started a wiki in case anyone wants to hack on such a FAQ: http://www.cryptohygiene.org/ -David Molnar signature.asc Description: OpenPGP digital signature
Re: Crypto Craft Knowledge
Stephan Neuhaus wrote: Many mistakes in crypto coding come from the fact that API developers have so far very successfully shifted the burden of secure usage to the application developer, the API user. But I believe this hasn't worked and needs to be changed. I totally agree, and this is the thinking behind the Keyczar project (http://www.keyczar.org/): Cryptography is easy to get wrong. Developers can choose improper cipher modes, use obsolete algorithms, compose primitives in an unsafe manner, or fail to anticipate the need for key rotation. Keyczar abstracts some of these details by choosing safe defaults, automatically tagging outputs with key version information, and providing a simple programming interface. Keyczar is designed to be open, extensible, and cross-platform compatible. It is not intended to replace existing cryptographic libraries like OpenSSL, PyCrypto, or the Java JCE, and in fact is built on these libraries. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto Craft Knowledge
On Feb 14, 2009, at 12:54 PM, David Molnar wrote: Ben Laurie wrote: [snip discussion of bad crypto implementation practices] Because he is steeped in the craft knowledge around crypto. But most developers aren't. Most developers don't even have the right mindset for secure coding, let alone correct cryptographic coding. So, why on Earth do we expect them to follow our unwritten rules, many of which are far from obvious even if you understand the crypto? Yes, there's a need for a crypto practices FAQ to which one can refer. In addition to individual education, it'd be helpful to have something when pointing out common mistakes. [snip specific discussion] I find this conversation off the point. Consider other trades like woodworking. There is no FAQ that can be created that would be applicable to building a picture frame, dining room table or a covered bridge. A FAQ for creating a picture frame would be possible, but this is not the FAQ that is being discussed. Crypto protocol failures are not trivial. The recent CBC attack on SSH shows that this is the case. http://secunia.com/Advisories/32760/ What FAQ would prescribe how not to make this mistake? There are PhD programs related to this subject. I would argue (and actually dovetailing with another thread) that, if one creates a FAQ, that it point to well vetted implementations of information delivery protocols like SSL and SSH, and that any FAQ regarding the use of crypto libraries be that this is dangerous and should only be attempted with proper oversight and/or training. Crypto protocols are not trivial, and suggesting a FAQ would be able to take the uninitiated to secure coding is more dangerous than good. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto Craft Knowledge
Ben Laurie wrote: [snip discussion of bad crypto implementation practices] Because he is steeped in the craft knowledge around crypto. But most developers aren't. Most developers don't even have the right mindset for secure coding, let alone correct cryptographic coding. So, why on Earth do we expect them to follow our unwritten rules, many of which are far from obvious even if you understand the crypto? Yes, there's a need for a crypto practices FAQ to which one can refer. In addition to individual education, it'd be helpful to have something when pointing out common mistakes. For example, I was involved recently in a discussion about MAC'ing prices returned by a shopping cart web application: http://news.ycombinator.com/item?id=477398 There's at least two gotchas here to consider: 1) The choice of MAC (i.e. why use HMAC instead of H(s||m) or H(m||s) ?) 2) replay attacks if the MAC'd item is not bound to the transaction or the rest of the web page I can point out these issues, but I don't usually have time to write fully detailed examples. Having such examples goes a long way towards increasing one's credibility in this kind of discussion. Ideally they would be from deployed applications, but that's tough. -David Molnar signature.asc Description: OpenPGP digital signature
