Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Decryption of data now takes ciphertexts to use and find k from
Previously decryption of entry/assignment data would take locCiphertexts and dlocCiphertexts (respectively), derive k, and decrypt the data. After doing some more testing, it seems that if we attempt to find a k value (via interpolation) on a set of points P, where P contains > 1 points with the same x-value (i.e. same user hash), the method fails to find k. The method even fails if you pass another point on the same line (but different x-value). When do we run into this case in the protocol? We run into this when the same user submits two distinct entries of the same perp. Even if there is a match on the same perp with a different user, the function fails to find k as described above. Clearly, the root of the problem is interpolation. I believe a simpler fix than this commit would be to follow the interpolation/decryption algorithm mentioned in the paper and try two shares at a time and decrypt as many ciphertexts as possible. That change would require a slight refactor/redesign of how loc.go is setup (order of operations, etc.) However, for time constraints, I'm choosing to delay doing this. See issue #5 for the tracking of this. For now, this commit solves the problem explained above by utilizing an earlier change done in matching.go. matching.go now returns a filtered list of matched tuples with unique user IDs. We now pass this list into loc.go and use this list to find k, while the greater superset (includes multiple entries on same perp from same user) is used for decryption of entry/assignment data. The current implemenation is slightly bad because we actually decrypt ciphertexts more than once--we do it once for the designated k-ciphertexts and another for the entire universe. We can fix this by doing a union first and marking which ciphertexts are designated for deriving k; however, at this point we might as well just solve #5 and do a better design of loc.go. Again, for time constraint reasons we are keeping this quick solution for now. This commit fixes the problem above because the filtered list to find k only contains ciphertexts from distinct users.
- Loading branch information