Re: [GNU Crypto] Passwords Immutable?

[Bryan Hoover]

Matthew Sackman wrote:

> Well yes and no. It is about all you can do but it's dangerous to do it:
>   i) You may introduce bugs in doing it.

He-he.  One might say that about programming in general :).

>  ii) You increase code complexity and decrease readability.

No biggie though is it - what's that saying about something should be no
more NOR less complex than necessary?

> iii) You have far more likelihood of very different behaviours on
>        different JVMs.

Now that's a bug-a-boo isn't it.  I wonder if there is a common
factoring in all of them such that one could relie on being constant,
providing for a dependable memory security strategy.  Or include an
abstract memory security management strategy layer.

>  iv) Other people reading the code may not realise that such code is not
>        guarenteed to run and may rely on it - ie you're setting a bad
>        example.

Comment the code.  

>   v) Speed sells. A lot of people think that Java has performance issues
>        and if you're going to write a JVM then you're going to do well
>        if you can advertise it as being the fastest JVM available. Ie
>        the optimisations you make to your JVM will affect its market
>        penetration and inversely affect the security of programs which
>        rely on non-optimising JVMs.

Sounds like a disclaimer is needed -- something about which VMs the
library's memory security supports or is supported.  Memory security --
for the truely fanatical.

> > 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.
> 
> Having done some OS design work, that's certainly true. It's ultimately
> up to how malloc is implemented in the OS though I guess some run time
> systems could try to make further guarentees.
> 
> > 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.
> 
> Well it's very very difficult. You have all the nice security features
> that Java provide: its resistance to buffer overflows, type safety etc
> which in general result in more secure programs by default, and yet for
> programs which really need to be 'secure' you start getting into
> difficulty due to the Java memory model.
> 
> For memory attacks you either need full root/administrator access
> (provided the OS's security is marginally sane) to be able to read the
> memory or you need physical access. I don't really think that in any
> language you can really start making effective efforts to safeguard
> against those conditions, IMHO.

As I said about memory security for the truely fanatical -- that is, I
agree that such makes sense only in terms of the, 'only the paranoid
survive,' school of security management.  For most implementations,
sounds like it'll probably be enough to be assured of security relative
to transmissions across the network wires.

> Besides, right now the majority of security flaws in programs are due to
> buffer overflows and as a result we have some funky kernel and userland
> code to try to deal with that (grsecurity kernel patches and the C
> library Electric Fence come to mind). Until that situation changes, I
> don't think it's an effective use of human resources to really push to
> get cast-iron guarentees about memory into languages IMHO.

But you might nevertheless try to accomodate, prepare for such in the
code as much as possible, reasonable maybe.

I just received Casey's latest response to this thread, which brings to
mind...

It's funny Java went to the trouble to provide the special getPassWord
function which returns a char[], respecting that String is immutable and
therefore perhaps not as secure as might be desired.  Yet, certain Java
VMs might thwart this by optimizing out zeroing an array.  Seems like,
something like the destructor Casey advocates could be a way around this
-- even if it meant going so far as to somehow seamlessly code using an
array after it's been zeroed -- to trick the optimizer into not ignoring
the zeroing code.

Bryan

> Cheers,
> 
> Matthew
> --
> Matthew Sackman
> 
> BOFH excuse #36:
> dynamic software linking table corrupted
> 
> _______________________________________________
> gnu-crypto-discuss mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/gnu-crypto-discuss

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