One-time .public
Errata: I meant "withOUT re-generating it", so it can do the comparision.
-----Pôvodná správa---
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.
Hello,
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 fine.
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---
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 name. It can probably be worked around with an additional API, but it sounds like an additional burden.
Hello,
I saw some concerns about security of name.public and possible leak of correspondence between public and its name. 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 asap. 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.