Clearing sensitive in-memory data in perl

[Steven M. Bellovin]

In message <7d752ae3050912070961770078 at mail.gmail.com>, Steve Furlong writes:
>On 9/11/05, Jason Holt <jason at lunkwill.org> wrote:
>> Securely deleting secrets is hard enough in C, much less high level language
>s.
>
>But, but..Java is the be-all end-all!
>
>Three years ago I advised a business/tech guy to avoid Java for crypto
>and related purposes. I'll revise that somewhat in light of greater
>experience and developments: Java is ok if you control the platform
>it's running on and if the programmers were very careful. In practice,
>that means I'd be willing to do the server-side programming in Java if
>I (or my employer or client) controlled the server. I'm not happy
>about doing client-side programming in Java for arbitrary users, but
>users in a controlled business environment is ok. From a user's
>perspective, I'd be _really_ cautious about using a crypto app written
>in Java.
>
>FWIW, lately I've been earning my daily bread with Java server-side
>programming. Fortunately for me, it's been mostly crap work, where it
>doesn't really matter if data leaks or someone cracks in. Considering
>that I don't control any of the J2EE or database servers and for the
>most part they're administered by poorly-trained monkeys, I'd have a
>really tough ethical call if my clients wanted me to do some work
>where security really mattered.
>

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?

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com