On 9/13/05, Steven M. Bellovin <[EMAIL PROTECTED]> wrote: > There's an interesting tradeoff here: which is a bigger threat, crypto > secrets lying around memory or buffer overflows? What's your threat > model? For the average server, I suspect you're better off with Java, > especially if you use some of its client-side security mechanisms to > lock down the server. Under some circumstances, you could do a > call-out to a C module just for the crypto, but it's by no means > obvious that that's a major improvement. > > Again -- what is your threat model?
Other important questions for programmers are, how good are you? How good does the process allow you to be? My answers are, I'm quite a good programmer. (Pardon the ego.) I'm careful and methodical and very seldom have buffer overruns or unfreed memory even in my first drafts. For me, my expected code quality in C and C++ is balanced against the black box behaviour of Java's runtime engine. (To be clear: I don't suspect Sun of putting back doors in their engine.) And I'm experienced enough and old enough that I can hold my own in pissing contests with project managers who want to cut corners in order to ship a day earlier. Implementation quality could be considered in the threat model. I've generally taken the programmers into account when designing a system, but I hadn't explicitly thought of well-meaning-but-incompetent programmers as part of the threat. Guess I should. -- There are no bad teachers, only defective children. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]