[18425] in cryptography@c2.net mail archive
Re: Clearing sensitive in-memory data in perl
daemon@ATHENA.MIT.EDU (Steve Furlong)
Tue Sep 13 09:19:58 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Mon, 12 Sep 2005 10:09:35 -0400
From: Steve Furlong <demonfighter@gmail.com>
Reply-To: demonfighter@gmail.com
To: cryptography@metzdowd.com
In-Reply-To: <Pine.LNX.4.63.0509120006540.15886@pl2.zayda.com>
On 9/11/05, Jason Holt <jason@lunkwill.org> wrote:
> Securely deleting secrets is hard enough in C, much less high level langu=
ages.
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.
--=20
There are no bad teachers, only defective children.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
