FW: Image Unique Identifier

Ron Teitelbaum Ron at USMedRec.com
Thu Aug 24 03:38:51 UTC 2006


Hi David,

Thank you that is very helpful.  I was just looking at files because in my
reading there were a lot of references about storing encrypted information
in a file that has OS Access Control.  I didn't see a way to change the
security parameters of a file.  Do we have that somewhere, is it planned.  I
want to be able to set the access rights for the file to be the currently
logged in user only.

As for your p.s. it amazes me that we haven't tried this yet.  We have a
huge amount of resources in very talented people, and in software, we have
some very nice implementations of cryptography primitives.  We will have SSL
very soon.  I suppose that protecting a SSL server is not really that
difficult as long as a good firewall is used to protect it.  I'm hoping to
push us to implementing more and better security that is easy to use.

What gets me is the concept of good enough security.  Reading cryptography
texts the concept comes up over and over.  Aiming for completely secure
implementations prevents any forward motion towards better security.  I
believe that we can provide security which is as good if not better then
much of what I've seen.  Will it be perfect?  No, but will it be enough to
rise to the standards of say NIST.  Yes I believe it can.  You would be
surprised at what government agencies are currently using!  I believe the
average grade for using mandatory standards was a D! 

I'm hoping that my SSL (actually it is tls 1.2) implementation will
encourage more people to participate in securing squeak!

Thanks again for the suggestion.

Ron Teitelbaum
Squeak Cryptography Team Leader



> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of David T. Lewis
> Sent: Wednesday, August 23, 2006 10:34 PM
> To: The general-purpose Squeak developers list
> Subject: Re: FW: Image Unique Identifier
> 
> On Thu, Aug 24, 2006 at 12:56:26AM +0200, Lex Spoon wrote:
> > Okay, enough bashing of UUID's.  For your problem, here are two
> > possible avenues for (non-universally unique) ID's to use.
> >
> > 1. An IP plus a process ID (which might be an IP port number) plus an
> > image-wide unique number.  Such an ID is unique relative to a
> > particular IP network, but of course can be duplicated--just think
> > about all the computers in the world with address 192.168.1.1.
> 
> By no means guaranteed to be unique, but recent versions of the VM
> provide a sessionIdentifier for this purpose, which as you suggest
> could be combined with an IP address and/or process ID. The session
> identifier is currently used in the FilePlugin to help identify stale
> file handles, but the intent is to provide an identifier that more or
> less represents the current invocation of the VM along with the image
> that is was loaded from the image file.
> 
> The value is obtained from Interpreter>>getThisSessionID.  Have
> a look at the file plugin, or if you have OSProcess loaded, do
> "OSProcess accessor getSessionIdentifier" to find its current value.
> Using the Squeak sessionIdentifier combined with a process ID is
> probably a good combination, although for any practical implementation
> that is likely to occur in the next 20 years or so, the sessionIdentifier
> is probably sufficient.
> 
> Better yet would be to just treat the Squeak session identifier as
> a hopefully-unique ByteArray of unknown length. Currently it will
> just happen to be an array of 4 bytes on a 32 bit machine, or 8
> bytes on a 64 byte machine, but in some future Universe (sic) it
> might be be 128 bytes of impossibly obfuscated data.
> 
> With respect to the original security question, the sessionIdentifier
> is visible in the image, hence inherently insecure. As others have
> pointed out, if you want an identifier that will not be visible
> to some other invocation of the image file, you simply cannot
> make it visible in the image at all.
> 
> Dave
> 
> p.s. "secure squeak" sounds like an oxymoron to me.
> 
> 





More information about the Squeak-dev mailing list