Jack Keel <jhkeel at facstaff.wisc.edu> wrote:
> We are in need of authentication (e.g., secured login to obtain 
> identity credentials)  and secured TCP/IP (e.g., encryption) 
> connections in Squeak/Croquet.  I couldn't find much on this in the 
> Wiki or the list.

There is a Cryptography package on SqueakMap that should give you the
necessary building blocks for any protocol you want to devise.  It
doesn't seem to get much discussion, but that just seems to be because
it has beaten the problem entirely.  It has a LOT of algorithms in it.

As for making the protocol, you could either post here, or (better) post
to a security newsgroup, or (worse) go read Bruce Schneir's Applied
Crytology book.  Please do get *someone* to review the protocol before
commiting to it; security protocols are notoriously easy to botch, and
once the protocol is in use it is hard to fix it.


> What is the state of of the TCP/IP design (stable, redesign planned, 
> redesign being worked on)?

Well, it works fine as is.  The Swiki uses it, and the email client uses
it, and the SuperSwiki uses it, so it has been beaten on pretty hard by
this point.  The Squeak-level code got rewritten recently, it appears,
but the primitives haven't really changed in quite a while.

People have talked about various possible improvements  to the
networking code, but you don't have to care about that if you don't want
to.


> What is the status of Squeak-E?  Seemed to have some security in its 
> implementation.  I'd be interested in knowing how many hours of thought 
> and development went into it.

Squeak-E is surely a close mapping of E to Squeak.  Thus, it provides
in-language security, albeit with the note that "in language" can
involve cross-network object references.  My guess would be, if you want
security built into a project that already has some risk in it, then go
with a simple tried and true solution.  Squeak-E seems more of a
research area to me, and it seems more geared towards allowing complex
security policies than towards making simple security policies easy to
implement.

Do complex sucerity policies sound interesting, or do you just want a
simple "you have access to this universe" kind of thing?  IMHO, I'd very
much rather see an insecure Croquet than a Croquet that got put off and
put off in order to make the security concerns come out correct.  In the
former situation, you can point the squeak-e people towards croquet as
an excellent example to consider as they do their work.  :)

Anyway, hopefully the Squeak-e people can say more.  If they don't reply
here, then be sure to drop a note to the squeak-e mailing list on this
same list server.

-Lex