[18437] in cryptography@c2.net mail archive
Re: Clearing sensitive in-memory data in perl
daemon@ATHENA.MIT.EDU (Steve Furlong)
Tue Sep 13 11:22:01 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Tue, 13 Sep 2005 09:40:18 -0400
From: Steve Furlong <demonfighter@gmail.com>
Reply-To: demonfighter@gmail.com
To: cryptography@metzdowd.com
In-Reply-To: <20050913132920.386D13BFE91@berkshire.machshav.com>
On 9/13/05, Steven M. Bellovin <smb@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.
>=20
> 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.
--=20
There are no bad teachers, only defective children.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
