One-time .public

David Bruant bruant.d at gmail.com
Sat Dec 17 10:22:51 PST 2011


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)

> 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.

> 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?

> 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.

David


More information about the es-discuss mailing list