[e-lang] Proposal: E / Erlang integration
David Hopwood
david.nospam.hopwood@REDACTED
Fri Jun 9 04:47:00 CEST 2006
Mark S. Miller wrote:
> 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?
See the following erlang-questions thread:
<http://www.erlang.org/ml-archive/erlang-questions/200507/msg00234.html>
The most serious incompatibilities would be
- removing the ability to enumerate processes
- registering processes by name in a global namespace, which is quite common
in Erlang programs, is not consistent with capability discipline.
--
David Hopwood <david.nospam.hopwood@REDACTED>
More information about the erlang-questions
mailing list