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

Handle unkown encryption keys #7826

Open
nventuro opened this issue Aug 7, 2024 · 1 comment
Open

Handle unkown encryption keys #7826

nventuro opened this issue Aug 7, 2024 · 1 comment

Comments

@nventuro
Copy link
Contributor

nventuro commented Aug 7, 2024

The new key getter from #7523 fails if no keys are registered and the canonical preimage is not known. We must however handle the scenario in which we can prove the keys were not distributed (if we don't happen to know them) to e.g. allow apps to skip encryption, note creation, etc., and so avoid King of the Hill issues (i.e. being prevented from creating a proof, leading to denial of service attacks).

A possible way would be to return Option<PublicKeys>, with Option::none meaning that keys are provably unkown. Currentl callsites would simply do .unwrap(), so there'd be little disruption.

@github-project-automation github-project-automation bot moved this to Todo in A3 Aug 7, 2024
@nventuro
Copy link
Contributor Author

Key rotation is being dropped as of #8613, so we won't need to deal with that. The current scheme does allow for the preimage not being known, but we're migrating to a new one in which we'll be able to derive the ivpk from the address, so King of the Hill will not be an issue.

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

No branches or pull requests

1 participant