l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Restricted storage


From: Christopher Nelson
Subject: RE: Restricted storage
Date: Wed, 31 May 2006 15:33:54 -0600

  
> On Mon, May 29, 2006 at 03:15:15PM -0400, Jonathan S. Shapiro wrote:
> > > > There is one very important point though.  I think those 
> > > > restrictions can easily be implemented in the user 
> session.  This 
> > > > means that we can just build a system with no support for 
> > > > restricted storage, and add it if we find that we did need it 
> > > > after all.  However, Jonathan doesn't seem to agree.  At the 
> > > > moment I still think he doesn't quite understand what I mean.  
> > > > However, if he does and is correct that it cannot be 
> added later, we would need to decide this before building the system.
> > > 
> > > Oh, and I forgot one thing.  I'm very sure that I do 
> indeed want the 
> > > user to be able to run his own programs on fully opaque storage.  
> > > This is very useful for programs handling encryption keys....
> > 
> > I seem to recall that this was one of the very first use 
> cases that I 
> > pointed out.
> 
> You did, but you said it was something that required a 
> constructor, which is not the case.  It requires opaque 
> storage.  However, it does not need verification of the 
> opaqueness.  Without verification, it is not possible for a 
> user to demand of an other user to provide opaque storage for 
> a program (such as your constructor would do by default), 
> because there is no no way that it can check if the storage 
> it received is indeed opaque.

What's the point of providing opaque storage to store encryption keys,
if you cannot verify (or provide some guarantee) that it is, in fact
opaque?  You might as well not have it, because it provides you no
conceptual security.  It's not trustable.

-={C}=-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]