Re: [GNU Crypto] Passwords Immutable?

[Casey Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Matthew" == Matthew Sackman <address@hidden> writes:

Matthew> On Mon, Apr 12, 2004 at 10:17:34AM -0700, Casey Marshall
Matthew> wrote:
>> That's actually a good question, and it brings up more serious
>> issues that I've been pondering. First I think you're right, the
>> password parameter in SRP should be passed as a char array, or at
>> least a mutable wrapper around an array, so it can be zeroed out
>> when it isn't needed any longer.

Matthew> You can't guarentee that that'll work. A heavily optimised
Matthew> JVM may well see that the char array is never accessed after
Matthew> the zeroing so therefore it's unnecessary to execute that
Matthew> code. At a guess, I think live variable analysis will show
Matthew> that such code is unnecessary (in terms of the JVM bothering
Matthew> to execute it).

But still, allowing for the possibility of erasure is, IMHO, a good
idea. Hoping that someone doesn't optimize all the security out of our
library is about all we can do ;)

>> But there is always the issue of where sensitive objects are kept
>> in the JVM -- we essentially have no control over the memory
>> management, so we have no idea if cryptographic keys are swapped
>> out to disk, or if some other process is accessing them, etc.

Matthew> Well yes, and that's the big problem with keys in Java: the
Matthew> spec makes it plain that you simply have no control over
Matthew> memory so the idea of trying to deal with sensitive data in
Matthew> memory is a bad one. Before I knew this, I wrote what I
Matthew> thought was a secure key store class which is available at
Matthew> http://www.wellquite.org/keystorage.tgz I wouldn't suggest
Matthew> that anyone actually uses it because of the fact that whilst
Matthew> it may have the desired effect on some JVMs, there's no
Matthew> guarentee that it will do anything at all useful.

I think modern languages in general (that I am familiar with, at
least) don't provide any sort of guarantee on where and how memory is
allocated. In the context of cryptography it looks like a big
oversight: we could make bulletproof algorithms and protocols, but
can't guarantee that the keys themselves will remain secret. It kind
of comes from an attitude I see everywhere (I call it the SSH notion
of security): "It's someone else's problem" -- it's hard to make Java
memory secure, so we pass it off to the C library. It's hard to make C
memory secure, so we leave it up to the kernel.

- -- 
Casey Marshall || address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQFAevGKgAuWMgRGsWsRAnfnAJ4oWgoQbHJorPKie9gsVV4r41EAjwCeOO8X
HDGimTPZvT0F2bX/Y1kvbHQ=
=GO0f
-----END PGP SIGNATURE-----