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 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
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
Ben Laurie 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
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
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
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
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
Re: Crypto Craft Knowledge
On 02/14/2009 07:18 AM, Ben Laurie wrote: Actually, in my extensive experience of reviewing security-critical code, this particular error is extremely common. Why does Michael assume that they probably wouldn't? 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? [1] http://www.lightbluetouchpaper.org/2009/02/02/hidden-assumptions-in-cryptographic-protocols/ Note that one of the things that FSTC did in e-check (and I did in x9.59) was specify the fields from existing transport infrastructures that were used for signing. Part of this was that standard digital signature processes (along with digital certificates if necessary) could represent a one hundred times factor payload bloat ... some past comments about various efforts that tried to apply knee-jerk application of digital signatures to existing financial infrastructures ... resulting in two orders of magnitude payload bloat http://www.garlic.com/~lynn/subpubkey.html#bloat One of the side-effects of some of the extreme bloated approaches was that they actually avoided defining end-to-end protocol ... just defined a digitally signed operation for flow over the internet ... which was then stripped off and thrown away at the gateway to the "real" infrastructure. In any case, as a result, the fields from standard existing financial transaction was specified for encoding ... that was signed ... and then just the digital signature was appended to existing formatted message. At the receiving end, the fields were re-encoded and verified with the transmitted digital signature. The issue for FSTC that prompted FSML ... was that at the time, the encoding standards weren't deterministic (i.e the sender and the recipient had to use the same encoding rules ... so the signed encoding and the verified encoding were the same). FSML was then contributed to W3C and incorporated into the XML digital signature standard. in that sense, neither e-check nor X9.59 required a length field ... they just specified all the encoded transaction fields that were necessary for characterizing a transaction unambiguously. As an aside ... we didn't particularly come at it from the stand-point of crypto craft or even security-critical craft ... we came at it from standpoint of business-critical craft ... where things might fail in a multitude of ways (some possibly having nothing to do with security). slightly related recent post mentioning FAA ATC system: http://www.garlic.com/~lynn/2009c.html#17 Bletchly Park fires up Big Green-Eyed Monster Another example was we did "audits" of RAID disk arrays ... looking for design &/or implementation shortcomings thatmight result in loss of data. In the "security" context ... we did some audits where we identified (nearly trivial) exploits in end-to-end operation ... and were told that wasn't part of the security protocol. -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
