Re: [GNU Crypto] Passwords Immutable?

[Bryan Hoover]

Casey Marshall 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.
> 
> 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.
> 
> Usually we at least want to prevent disk swapping, and would do that
> via mlock, but would this be available to a Java program?

I'm reading up on it.  It appears that's correct -- no mlock.  There are
recommendations only, about allocating a larger heap (or configuring
Java to do so), and keeping sensitive data in memory (before zeroing it
out) as briefly as possible.  And there are other aspects, parameters
for controlling VM memory management, though I havn't read enough to
determine whether any might be a usefull technique in the present
context.  Anyway, the application I'm working on, I don't think would
have such VM privileges on the client side (an applet, on the client
side).

I'm hoping to hit on some tip or trick about effectively controlling
memory in this regard, though I doubt I'll find anything reliable.  And
also, the possibility that future Java specifications may provide for
such a requirement.  I think current specification proposals are looking
at memory model issues regarding thread safety, optimization
restrictions relative to when memory becomes visible to all threads, and
other things, but I have not found anything specific to disk swapping,
or for that matter, optimizing out things like zeroing an array -- such
optimization ommission requirements seem unlikely though, because it
seems like targeting variable non-use would be such a common
optimization technique -- maybe a special variable type to flag such
prohibition though?

These issues seem like something the folks involved with writing
specifications would be interested in though.  So much so, that I'm
surprised it's not already, or hasn't been, on an agenda.

Bryan

> - --
> 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/>
> 
> iD8DBQFAes8lgAuWMgRGsWsRAuRJAJ9GPirGWE3jh0kW9ue6kZR/bAjv+ACfcn3O
> 4AnoTmcrAt34P4o3nj+ZO1k=
> =Abmn
> -----END PGP SIGNATURE-----

-- 
I struggle in vain.  My foot slips.  My life is still a poet's
existence.  What could be more unhappy?  - (Soren Kierkegaard -
Either/Or)

http://www.wecs.com/content.htm

This signature file is generated by Pick-a-Tag !
Written by Jeroen van Vaarsel
http://www.google.com/search?hl=en&ie=ISO-8859-1&q=pick-a-tag