| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Matthew" == Matthew Sackman <matthew@xxxxxxxxxxxxx> 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 || csm@xxxxxxx -----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----- _______________________________________________ gnu-crypto-discuss mailing list gnu-crypto-discuss@xxxxxxx http://mail.nongnu.org/mailman/listinfo/gnu-crypto-discuss
[Home] [Gnu Classpath] [Linux Kernel] [Linux Cryptography] [Fedora] [Fedora Directory] [Red Hat Development] [Red Hat 9 Bible] [Fedora Bible] [Red Hat 9] [Network Security Reading]
|