-
Notifications
You must be signed in to change notification settings - Fork 30
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
Temporary Bindings implementation #13
Comments
I asked Joe about the change counter in the TB had mentioned to me before as an approach to support multiple changes in a single epoch, but it seems they discarded this idea because of its complexity (the idea was to have a Merkle tree per user leaf node to store all the changes ever made to that node). A long time ago, we considered including a hash chain recording all changes made to a name-to-key mapping. We could imagine using a hash chain to record all changes made between two epochs and combine this with a change counter that needs to be included in the TB's as well. Thoughts? @c633 @arlolra @liamsi |
I'm not sure I understood the approach correctly: Would this be another hash chain (one specifically and only for the temporary bindings)? |
Sorry, let me expand on this. The issue we're worried about is that a user may change their keys more than once (e.g. by re-installing the app), or install the app on multiple devices, in a single epoch, generating multiple temporary bindings. The hash chain would be per user allowing us to order all registrations/changes (i.e. TBs) for each user linearly.
At the time of writing our paper, one of our contacts in industry mentioned that they had seen about 1% of users changing their keys each day (mostly via app re-installs). They said this actually would probably pose a non-negligible overhead on their system if they had CONIKS (unfortunately, we don't have numbers for the size of their user base) . For us, maybe it's fine to impose a "single change per epoch" restriction for now, making epoch's a shorter in exchange.
Yeah, the main issue with making the epoch period shorter is that you're going to be reconstructing (and rehashing) your tree more frequently, which probably won't scale for a very large tree. OTOH, making the epoch period longer saves time on tree reconstruction, but leaves a larger window open in which the server doesn't include new updates in the signed tree roots, which leaves a window for attack. |
Maybe this question is out of scope, but as I understand, there is no auditor module for TBs, right? |
I don't think it's out of scope. Yes, you're right. We don't have have auditors for TBs. Joe's original proposal with TB counters did require TB auditors, but since we're not going that route, we still shouldn't need one. |
Even if the server allows only one registration/change per epoch, how does Bob know that Alice's key returned by the TB is not spurious, without an auditor? |
This is a good question. You're right that Bob can't know if the TB is spurious when he first receives it. If we wanted to avoid this situation we could have auditors for TBs and STRs. The only issue with having auditors also handle TBs is that CONIKS now loses a big part of its privacy guarantees since auditors would then have a way of knowing which users have keys in which servers. But without auditors Bob will still know by the next epoch if the TB was spurious since the server will either not include the spurious TB in the tree, which he will detect when he does the first lookup for Alice's key and checks if the TB is included. Or the server will include the bad TB in the tree for Bob but not others (including Alice) and equivocate, which Bob will detect using regular CONIKS auditors. Alice will also detect the attack in the next epoch since she will have received a legitimate TB when she first registered her key, so she also has strong evidence of the attack. I hope this makes sense. |
Yes. I got that part. It makes sense, of course :-) |
The fact that TBs are TOFU is definitely a concern. At the very least, we can enforce shorter epoch intervals to decrease the attack window. I do agree, though, that we should have a mechanism for auditing TBs. This is something we can work on in the future. |
Great! I'm glad to know that :-) |
@masomel said:
This issues would be a part of #3
The text was updated successfully, but these errors were encountered: