Re: [GNU Crypto] Passwords Immutable?

[Casey Marshall]

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

>>>>> "Bryan" == Bryan Hoover <address@hidden> writes:

Bryan> Hello, Had a question.  Thought I'd join the list.

Bryan> I'm integrating the SRP (client, and server) mechanism into a
Bryan> sourceforge project.  It's been going without a hitch.  Very
Bryan> nice.

Bryan> The question of String immutability came up -- Java String
Bryan> hangs around in memory indefinitly and this supposedly makes it
Bryan> vulnerable to memory sniffing.

Not quite indefinitely -- garbage collection should eventually free
them. That is, unless all the silly optimizations Sun did for the
String class prevents this.

Bryan> I've tracked down that the library uses a HashMap String
Bryan> property for the password.  It's converted to a char array
Bryan> before processing.

Bryan> Anyone know whether there's anything to the notion that the
Bryan> String password in the HashMap could be sniffed by someone on
Bryan> the local network?  Is it a serious problem?

If there's a network-level vulnerability, then that's the problem of
the protocol talking across thet network, not the Java runtime.

Bryan> I'm playing around with the code at the moment, thinking about
Bryan> setting the property as a StringBuffer, or char array, and then
Bryan> doing the necessary conversion when the property is read by the
Bryan> lower level routines.  Would be easy enough.

Bryan> OR, perhaps there's a way around this I've missed?

Bryan> I hope I havn't touched a nerve with this, as I'm joining the
Bryan> group blindly, without having read any of the messages for
Bryan> context or anything.  I'm new to Java, so sorry if I'm off base
Bryan> with the String question.

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?

- -- 
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-----