Lots of duplicate auth stuff in the store
mikebryant opened this issue · comments
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
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.
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..
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.
🤔 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.
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!