[e-lang] Proposal: E / Erlang integration

[Mark S. Miller]

Vlad Dumitrescu wrote:
> No, process ids are actually forgeable... For remote pids one has to
> find out the internal value to use as first argument for c:pid/3, but
> even that one could be found by trial and error.

This is unfortunate. My assumption that they were unforgeable was based on
existing Erlang documents, but I'm not sure which. (Perhaps Armstrong's thesis?)

In order to function as distributed cryptographic capabilities, pids should
not be feasibly forgeable or spoofable. The approach taken by E and the Web
Calculus <http://www.waterken.com/dev/YURL/httpsy/> is to make a crypto-cap
not feasibly spoofable by including a public key fingerprint, such that the
entity designated by the cap must prove it knows the corresponding private key
in a handshake setting up a secure session. We make crypto-caps not feasibly
forgeable by including a so-called "Swiss Number" -- an unguessable randomly
chosen number. Swiss Numbers are only revealed over sessions set up by the
above handshake. There are other approaches to crypto-caps, some of which
<http://www.webstart.com/jed/papers/Components/> arguably have better security
properties.

AFAICT from the Erlang readings I've done, all this could be provided for
Erlang without affecting the semantics at all. Would it break anything? Would
such a change be upwards compatible?

Among Erlang processes running within one host OS process, I would hope pids
could be able to be absolutely unforgeable and unspoofable by safe language
rules without resorting to crypto.


>> This issue seems fundamental. It cannot be fixed either by syntax or
>> by a library. Until it is fixed, I don't see how to write practical
>> Erlang programs with distributed object-capability security
>> properties.
> 
> Maybe I am completely missing the point, but I think it is possible to
> build a system that matches at least some of these requirements (I
> include here the non-blocking event loop).
> 
> I am thinking about a setup where an "e-process" is actually composed
> from several erlang processes: one for receiving events, one to do the
> actual job, and maybe some more.


On practicality, perhaps I am underestimating how lightweight Erlang processes 
are. If they are lightweight enough, then this approach would work. To whit:

When Erlang process X wishes to make a request and receive a response from 
process Y, X would make a new use-once process X2 which knows X's pid. X would 
then include X2's pid in the message to Y. When Y responds to X2, X2 would 
then wrap Y's response with a tag and send this response to X.

Either these tags can themselves be unforgeable, or X's clients would also 
need to go through a tagging intermediate process so that a client couldn't 
send a message that X would mistake for Y's tagged response. I think it works 
for X2 to tag the message with X2's (presumed unforgeable) pid, since anyone 
who has that pid can respond on behalf of Y anyway.

With enough care, X could reuse X2 for successive requests to Y. But if X 
wants to make requests of Z, it would need a separate X3 for that purpose. 
Otherwise, it enables Y to issues Z's response, and vice versa.

The above scheme would meet the hard requirements. But how practical would it be?

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM