On Wed, May 31, 2006 at 08:23:53PM -0400, Jonathan S. Shapiro wrote: > > > No, it's nonsense. The program storing the encryption keys doesn't know > > > if the storage is opaque. It doesn't care either. It's the user who > > > cares. And it's the user who chooses to use opaque storage (or not). > > > The user can trust that the program runs on opaque storage, not because > > > the programmer guarantees this (by putting a check in the program), but > > > simply by providing opaque storage to the program. (Intentional > > > side-effect is that storage which is given to some other user cannot be > > > checked for opaqueness. This can be "fixed", but I'd rather not do that > > > if possible.) > > [...] > > > > Which Object(s) in the system represent the user and her choices?
The user's shell. And no other programs. And the shell can indeed verify opaqueness, because it knows that it has a capability to all memory, but it's missing this one. It can also verify by keeping track of when it asked for opaque memory from the session manager. It can not verify this for any memory that it received from some other user. That is intentional. > Indeed. And while we are about it: where do you propose to store keys > that are used for group signatures? In some place that cannot be destroyed by any of the members of the group, but only by the group administrators. That is, in a special user account created specially for that group. > The objects holding such keys must be shared, and all parties need to be > able to verify the storage safety and the identity (in the sense of "what > binary is executing here") of the key management object. Yes. They can do that socially. This user account can be very limited, and only allow to do safe things (such as starting a key manager on opaque storage). In that case, since the session cannot be used for anything useful (including reading its data), the storage doesn't even need any special technique to make it opaque: it's automatically opaque because there is no way to read it (or pass the capability on, even if it has it). (Note that this is just theoretical. In practice, to avoid trusting too much code, making the memory really opaque is a very good idea.) The fact that this session does indeed behave this way must be guaranteed by the machine owner (or by the OS designer, if we're using TC). This party is in the position to compromise the keys anyway, so from them you cannot get more than a social guarantee. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
