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

Lots of duplicate auth stuff in the store #350

Open
mikebryant opened this issue Jun 4, 2024 · 5 comments
Open

Lots of duplicate auth stuff in the store #350

mikebryant opened this issue Jun 4, 2024 · 5 comments
Labels
optimization willow Issues with the willow branch.
Milestone

Comments

@mikebryant
Copy link

What's the problem you want solved?

If I call mintCap, or addExistingIdentity etc - these get added into the local indexeddb, even if they already exist.

Is there a solution you'd like to recommend?

Instead of storing at a random location - use content addressed storage?

Or for identities, store by the public key etc

@sgwilym
Copy link
Contributor

sgwilym commented Jun 4, 2024

Could you give me some more context on how these values are being added again and again? For instance, is this a script being re-run? Is there a way we could avoid re-adding things?

Unfortunately, content addressed storage would allow someone with access to Auth's keys to infer which keypairs / capabilities you have (if they already know the address).

I considered encrypting the addresses, but as values need to be encrypted with a new initialisation vector each time the encrypted address always comes out differently, making it impossible to check for its presence in one call.

@mikebryant
Copy link
Author

Mhm, pretty much just naive usage of the apis - my test server is starting up with addExistingIdentity followed by mintCap etc.

I guess I could do a getIdentityKeypair and check to see if it exists before adding?
And similarly use getReadCaps prior to the mintCap call to see if I can find an existing one.

So I guess it would just be a convenience thing, if these methods were idempotent? I guess the above logic could be implemented inside the method, instead of in the caller.

Unfortunately, content addressed storage would allow someone with access to Auth's keys to infer which keypairs / capabilities you have (if they already know the address).

Ahh, I see, we're also trying to cover someone stealing the local encrypted auth store..

@sgwilym
Copy link
Contributor

sgwilym commented Jun 6, 2024

I guess I could do a getIdentityKeypair and check to see if it exists before adding?
And similarly use getReadCaps prior to the mintCap call to see if I can find an existing one.

The reason I'm hesitant to do this is also to do with all the keys being encrypted: to find a keypair, we need to iterate over all them until we find what we're looking for. This might not be so bad with keypairs, but there could be many caps.

@mikebryant
Copy link
Author

🤔 What about using aes-gcm-siv(hash(content)), or aes-gcm-siv(public-key) for the identity keypair case?

If you don't use nonces with aes-gcm-siv, the only thing an attacker can observe is if the same plaintext is encrypted multiple times - but that doesn't matter for this use-case because that's kinda the point of making it the key in the key-value store, we want it to be encrypted the same way each time.

@sgwilym
Copy link
Contributor

sgwilym commented Jun 7, 2024

That could work! As this algorithm is not available in Webcrypto, we'd need to consider how much weight the added dependency (e.g. https://github.com/paulmillr/noble-ciphers) would add on top of the Earthstar web bundle. I'd be more than happy to do that investigation if a PR with the actual change to aes-gcm-siv was added!

@sgwilym sgwilym added optimization willow Issues with the willow branch. labels Jun 7, 2024
@sgwilym sgwilym added this to the Willow milestone Jun 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
optimization willow Issues with the willow branch.
Projects
Development

No branches or pull requests

2 participants