[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU Crypto] Passwords Immutable?
From: |
Casey Marshall |
Subject: |
Re: [GNU Crypto] Passwords Immutable? |
Date: |
Mon, 12 Apr 2004 12:44:23 -0700 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) |
-----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-----
- [GNU Crypto] Passwords Immutable?, Bryan Hoover, 2004/04/12
- Re: [GNU Crypto] Passwords Immutable?, Casey Marshall, 2004/04/12
- Re: [GNU Crypto] Passwords Immutable?, Matthew Sackman, 2004/04/12
- Re: [GNU Crypto] Passwords Immutable?,
Casey Marshall <=
- Re: [GNU Crypto] Passwords Immutable?, Matthew Sackman, 2004/04/12
- Re: [GNU Crypto] Passwords Immutable?, Casey Marshall, 2004/04/12
- Re: [GNU Crypto] Passwords Immutable?, Bryan Hoover, 2004/04/14
- Re: [GNU Crypto] Passwords Immutable?, Casey Marshall, 2004/04/14
- Re: [GNU Crypto] Passwords Immutable?, Bryan Hoover, 2004/04/14
- Re: [GNU Crypto] Passwords Immutable?, Bryan Hoover, 2004/04/15
- Re: [GNU Crypto] Passwords Immutable?, Casey Marshall, 2004/04/20
- Re: [GNU Crypto] Passwords Immutable?, Bryan Hoover, 2004/04/21
- Re: [GNU Crypto] Passwords Immutable?, Casey Marshall, 2004/04/21
- Re: [GNU Crypto] Passwords Immutable?, Bryan Hoover, 2004/04/21