One-time .public

Herby Vojčík herby at
Sun Dec 18 05:24:07 PST 2011


well, never mind. As I though about it, private name is protected finely by 
.public mechanism. It will never be leaked or disclosed by o[n], exactly as 
Brendan wrote. You are handed a "public key" which is no use for you unless 
you know the private one (the name object itself). Even Sam's code does not 
reveal the name using this[n]. Whenever private name is used in construct 
o[n], it is protected. So no need to change anything here, the scheme is 

The only way how you can leak the private name is using it in any other 
construct (mainly, passing it as an argument). So simply never write code 
that uses private name other then inside o[n]. And you can leak the private 
value (stored under private name), too (maybe that was the Sam's code 
scenario), but it is again the restiction on code - you should never use the 
private value as an argument or return value.

So, from my point of view, the proposal is ok. Pity it disallow to create 
transparent forward proxies with private names, but they will not be private 
if it was possible. I've got an idea to make this possible, but I post in 
different post.

Answers to your post below:

-----Pôvodná správa----- 
From: David Bruant
Sent: Saturday, December 17, 2011 7:22 PM
To: Herby Vojčík
Cc: es-discuss at
Subject: Re: One-time .public

Le 17/12/2011 19:03, Herby Vojčík a écrit :
> Hello,
> I saw some concerns about security of name.public and possible leak of
> correspondence between public and its name.
Just to clarify, there is no security issue with '.public'. What I
argued for is that it does not bring more security than being careful to
who you hand your private name to (which, for private names with a
public counterpart is shifted to being careful about who you share your
correspondance map with)

I still don’t know what you mean by "correspondence map" and this all was 
just a try to protect that map. Private name is protected fine by .public.

> Maybe it can be solved by simple trick (though it will have some
> implication of certain parts of code). That is, each time name.public
> is read, _new_ object will be created (with the same propoerties as
> today's public object has); plus, there will be
> name.correspondsTo(public) API which would check if the public element
> is equal to the present value of .public (with re-generating it).
> So the .public value will be short-lived - 1. it is read 2. passed to
> the proxy 3. it must be checked by .correspondsTo API in proxy
So the proxy has access to a public name and a function to retrieve the
private name from the private name? So any proxy can decypher any
private name. I think we had better passing the private name directly
than doing this.

You have been reading this wrong, it's the other way around, you can only 
check if public belongs to a private name.

> asap.
What do you mean exactly by "asap"? First instruction in the trap call?
Within a second?
What happens if I don't decypher and pass my public key "version" along
to someone else?

Until it is not read again, by which operation it would be regenerated. If 
you pass it along, it may be used immediately, but not when stored and tried 
to use later. But it does not matter in the light of the first paragraph.

> In the long run, it's value will be useless since in every invocation,
> new .public value will be generated. But the code must be written with
> this in mind and should not keep the value to use it later, since it
> may be invalidated.
Overall, I'm not really sure I understand the problem you are trying to
solve by generating new public objects. Could you express (preferably
with some code) what threat your proposal is trying to fix, please?

Also, loosing the one-to-one mapping, 2 proxies accessed with the same
private keys can't recognized that they have a public part of the same
private name.

Would this be a problem?



More information about the es-discuss mailing list