[e-lang] E Distributed Programming Clarification

[Kevin Reid]

On Sep 16, 2008, at 4:25, Jimmy Wylie Jr. wrote:

> I have been trying to learn and understand distributed programming  
> with E. ... My primary concern when I started was how communication  
> between two objects are established securely and how the continued  
> sending of messages remained secure.  ...
> Assuming 3 vats: A, B, C with objects Alice, Bob, and Carol  
> respectively.  The process of establishing communication between  
> Alice and Bob followed by Alice's introduction of Carol to Bob  
> proceeds as follows:
>
> 1. Physically hand URI designating Alice to Bob via PGP mail,  
> telephone etc.  With the URI being some form of the YURL as  
> specified in HTTPSY( http://www.waterken.com/dev/YURL/httpsy/).

Yes, it will be a CapTP URL, which meets the definition of YURL. The  
current syntax is roughly:

   captp://*<hash of public key>:<search path>/<object id>

> Why SHA-1 though?... I seem to remember a Schneier article saying  
> Sha-1 was broken by some Chinese Researchers.

AFAIK, because it looked a lot better when it was chosen; we should  
change this.

(Before I forget to mention this again: MarkM: We need to do something  
about #cryptoHash/0 methods. From where I sit, it seems like a bad  
idea to promote one particular hash algorithm: in general, if we don't  
upgrade it, people will continue to use a hash with known weaknesses;  
if we do upgrade it, there will be incompatibility. I think the  
#cryptoHash should be pulled out into a hash-algorithm object, perhaps  
with a way to import the "current recommendation" (and previous  
algorithms also available, of course).)

> 2. VatB receives URI, and looks for VatA using sequence of hints.

Yes.

> 3. VatB authenticates correct VatA by verifying that this vat  
> "candidate" knows the private key associated with VatA's public  
> key.  Exactly how is this done? I don't really understand how VatB  
> determines VatA's knowledge of the correct private key.

The same way any other public-key-based system works: by requiring  
VatB to decrypt or encrypt something with it. I don't know the  
details, but even certificate-based or trust-network-based systems  
must do this; it is the fundamental step in establishing communication  
with a known party.

> I know that here: http://www.waterken.com/dev/YURL/httpsy/ it says  
> that servers are authenticated via verification of a constructed  
> certificate chain.  I know httpsy, is related to E's CapTP,  but I  
> remember reading elsewhere, that E rejects the use of certificates  
> in its protocols.

This works the way it does, not because the certificates are directly  
useful, but because TLS is defined to work with certificates; HTTPSY  
(and VatTP, in the future) make use of TLS as a well-defined and  
implemented system, not as an ideal-for-capabilities one. (Not that  
there are any flaws that arise from this, but that it does unnecessary  
work.)

> 4. Once VatA is authenticated, VatB establishes a connection with  
> VatA as per VatTP,

No, the authentication is part of the (VatTP) connection setup.

> and then sets up a proxy object that represents the local reference  
> to Alice. VatA does the same thing(sets up proxy object to represent  
> reference to Bob).

Yes; the proxy object is CapTP's job. CapTP handles all adapting- 
object-graph-to-network-stream issues; CapTP abstract messages are  
serialized and sent over a VatTP connection.

> I know the swiss number is used sometime in this process, but I'm  
> not sure exactly when.

Over every CapTP connnection, each side is initially aware of the  
other's NonceLocator object (for that connection). This is how object- 
level communication is bootstrapped.

The swiss number is sent in a lookupSwiss message to VatA's  
NonceLocator, which looks up the number in its SwissTable and returns  
the object.

It basically works like this, except that the parsing happens earlier;  
the rest of this code is in LocatorUnum.

   def [keyFingerprint, searchPath, swissNumber] := parseCapTPURL(url)
   def connection := captp.getOrMakeConnection(keyFingerprint,  
searchPath)
   return connection <- getRemoteNonceLocator() <-  
lookupSwiss(swissNumber)

http://www.erights.org/elib/distrib/captp/lookupSwiss.html
http://www.erights.org/javadoc/net/captp/jcomm/NonceLocator.html

>
> 5. Alice sends Bob a reference to Carol. Reference here is the URI  
> designating Carol and the location of VatC.

No; the data designating Carol does not make a URI. Plain three-vat  
introduction is handled through the NonceLocators; see

http://www.erights.org/elib/distrib/captp/provideFor.html

The connection between VatB and VatC is established in the same way,  
but once made the first message will be acceptFrom rather than  
lookupSwiss.

The reason for this protocol is to ensure that VatB will eventually  
succeed in getting Carol from VatC, even if VatA's provideFor message  
does not get to VatC before VatB's acceptFrom message does.

>     -- Regarding the sending of messages, my main concern was the  
> result of eavesdropping on packets on a wireless network via a tool  
> like WireShark. So, once the communication link has been  
> established, the messages must be sent securely.  So each TCP packet  
> is encrypted via Triple DES-EDE with Cipher Block Chaining, and even  
> if somehow an eavesdropper managed to decrypt a packet, aren't there  
> still many other layers of encryption in each packet for him to  
> tackle?

I can't comment on the cryptographic issues, but we (will) use TLS  
just like every HTTPS connection -- getting the same confidentiality  
and integrity features for the connection. Within the TLS connection,  
there is no additional encryption of messages.

> Now to put things into practice, ... I also tried it on the larger  
> campus wide Wifi network.  Unfortunately, the program can never  
> establish a connection.  I attempted to run the program several  
> times, and both situations: where I gave my friend a URI to my  
> program, and he the URI to his.

I would imagine that the two computers are on separate NAT subnets, or  
that there is a firewall. E as currently implemented has no NAT- 
workaround  support, so you will not be able to *establish* a  
connection from a machine outside some NAT to one inside it. Once the  
connection exists, bidirectional communication will work fine.

> To make the URI, I am using the makeSturdyRef.temp(obj) to create  
> the sturdy ref, and then sending that to  
> introducer.sturdyToURI(sr).  Then to change that uri into an object,  
> I use introducer.sturdyFromURI(uri).getRcvr().  Are there perhaps,  
> more updated methods I should be using?

That's a perfectly fine way to do it.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>