Clearing sensitive in-memory data in perl

[Steve Furlong]

On 9/13/05, Steven M. Bellovin <smb at cs.columbia.edu> 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 majordomo at metzdowd.com