One-time .public

David Bruant bruant.d at
Sun Dec 18 07:19:20 PST 2011

Le 18/12/2011 14:24, Herby Vojčík a écrit :
> (...)
> 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.
> ===
Sorry for being that brief. Currently in order for a proxy to have
access to a private name, you need to share with the proxy a way to
"decypher" the public name. I call this a "public -> private
correspondance map". In a way, your "name.correspondsTo" is a way to
implement this map.

>> 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.
> ===
There can be several private names and several public names. What you
propose is an "API which would check if the public element is equal to
the present value of .public ". So if for a given private name, you're
able to call this function on the private name, it means that you
already have access to the private name which is what you'd like to prevent.

>> 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?
> ===
I think that the intention of the one-to-one mapping was that people
with the same public names can recognize that they have the same public
It can probably be worked around with an additional API, but it sounds
like an additional burden.


More information about the es-discuss mailing list