Squeak
  links to this page:    
View this PageEdit this Page (locked)Uploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Authentication and Encryption in Squeak
Last updated at 3:53 pm UTC on 14 January 2006
Question Jack Keel February 05, 2004 11:20 AM
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. Do either of these exist in Squeak? Has anyone looked into these areas? Any good white papers? Issue papers?
Who are the TCP/IP Squeak gurus, maintainers, Stewards (Andreas R., John M., Ian, Micheal R.)?
What is the state of of the TCP/IP design (stable, redesign planned, redesign being worked on)?
Any thoughts on the difficulties of implementation or probable
development time?
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.

Answer Craig Latta: You might be interested in http://netjam.org/flow/. I'd be happy to answer questions.

Answer/SqueakElib Rob Withers (See also) Authentication and Encryption in Squeak Squeak-E is an imaginary number at the moment, but SqueakElib is inching forward when I dedicate the cycles. SqueakElib is the infrastructure for providing distributed secure capabilities. Squeak-E may be a broader project to provide scoped security within an image and between images. This involves stacks, compilers, and environments in some creative ways, I think, but I haven't looked to closely at it. SqueakElib is about 85% done, minus some problems integrating it into the squeak image. The communications layer, while not complete, is definitely usable.

There are 2 main layers in SqueakElib: VatTp and CapTP. The top layer is the CapTP layer which implements a capabilities model and the remote objects and pipelined messages sent to these objects. It also has the Garbage Collector. This is the researchy layer. The lower layer is the VatTP layer and this is what builds secure connections, between Vats. It implements both the client and server for this. That is why I think we could implement sshd. It's 3DES with mutating IV sequences (I think that is what they are called) and msg agglomeration. 3DES are keyed from a DSA based Diffie-Hellman key exchange, with authorization (identity) and authentication (digital signature). Interestingly, it does this without a 3rd-party Certificate Authority. When you connect to a Vat, you have to have its VatID, which is an un-guessable number. In other words, you have to have a capability to a machine to connect to it.

If you don't want to implement ssh, which would be pretty interesting I think, then you could lop off the CapTP layer and just use the VatTP layer. We'll have to talk about host identity and object identity and the keys you need. It does build a 3DES connection after using a DSA certificate based key exchange, along with other techniques that need close review. There are some missing aspects to this layer (part of the 85%) such as no suspend/reconnect and the ping-pong process doesn't suspend quiet connections.

That will give you the connections and you would have to implement your own remote object system.

If you want to try to use the CapTP layer, then it does do remote objects, but it is difficult to see how it can be integrated into the squeak environment. Async message sending, promises and primitives don't seem to play well together. You might be able to modify the CapTP layer to use synchronous sending and avoid promises, but still use the object tables, maps, and garbage collector.

Answer Chris Muller:
KryptOn provides a generic, pure-domain approach to these security issues. For more information, see KryptOn.