Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

giving capabilities in ClaimChains #47

Closed
carmelatroncoso opened this issue May 11, 2018 · 4 comments
Closed

giving capabilities in ClaimChains #47

carmelatroncoso opened this issue May 11, 2018 · 4 comments

Comments

@carmelatroncoso
Copy link
Collaborator

The text used to read:

It will grant capabilities to all these claims
for the recipients of the email and itself.

It is not clear what are "all" those claims. I substituted by:
"Then, if they did not exist already, the client will grant capabilities to the recipients for the claims concerning those recipients. In other words, it will provide the recipients with enough information to learn each other keys and ClaimChain heads." but I do not know if this fits your idea/implementation

For the capabilities to one-self, how is the DH key defined?

@azul
Copy link
Member

azul commented May 12, 2018

@carmelatroncoso, your substitution captures exactly what i meant. Thanks.

For the capabilities for oneself @misaakidis recently implemented a 'shortcut' that allows the owner of the chain to read all claims. I think this is based on the knowledge of the private keys for the vrf and encryption. The coresponding commit is here: claimchain/claimchain-core@d94bb9b

@azul azul closed this as completed May 12, 2018
@azul
Copy link
Member

azul commented May 12, 2018

One related thing comes to my mind... Right now we are not removing the capabilities when we construct new blocks.
We basically build up the state by adding claims and capabilities and then commit them and continue by adding more claims and capabilities. This allows recipients to follow the development of other recipients keys in my chain.

Fixing this is captured in this issue: nextleap-project/muacryptcc#20

@carmelatroncoso
Copy link
Collaborator Author

@azul I understood that this "always" keeping capabilities was your way to avoid equivocation accross blocks. It has the problem of revealing key updates, but so far we do not have other way of doing that in a privacy preserving way

@azul
Copy link
Member

azul commented May 14, 2018

@carmelatroncoso Yes. If I have a claim about your key I should also always add a capability for you to check it. If you notice my claim changed that should have no privacy implications as there are two ways for me to update your key:

  • If you send me the new one directly you should already know you did.
  • If I see a new key in gossip you should also be in the CC list of that mail. So you will also know i received it.

However right now we are also keeping the capabilities for others that i gossiped your key to. There's no need for that. Holger does not need to check if i start claiming that you have a new key. And this in fact would have privacy implications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants