Specifically: "The server is “untrusted” in the sense [it] learn[s] nothing about users & messages besides what is inherently observable from its pattern of requests, and it should not have access to sensitive metadata, or sender or receiver information"
Seems like a very weak definition of "untrusted", especially when two comparison techniques explicitly attempt to restrict knowledge derived from access patterns.
Further...doesn't the servers ability to produce arbitrary valid ciphertexts (not really forgeries as it's an explicit requirement) allow a range of active attacks against recipients?
I'm not entirely sure of the consequences there, but it seems incompatible with the optimized decrypt-fetch message id (as it allows the server to test and trigger).
Removing the optimization effectively brings you back to download-all and trial decryption (with server forgeries there becoming effectively noise)
The motivation for private server state is "there isn't enough traffic going through the system to provide a reasonable anonymity set to any observer so we want to minimize observers"
Which is reasonable, but then the server is explicitly not "untrusted" - it can perform all the same statistical attacks...you effectively limit the adversary space to the server.
And if so (and you are unwilling to trust the server) then your risk model becomes that addressed by PIR or OMR.
But instead the protocol explicitly allows the server additional capabilities by granting it participation in generated receiver key material (and bloating the ideal communication cost)
Any optimization you make to reduce that cost grants the server additional information. Either making the server trusted in arbitrary ways or compromising one of the desired properties.
The protocol itself is interesting, involving the server in that way has that nice property of hiding valid ciphertexts from all other parties - I feel like I've seen a flow like it before, somewhere, but nothing immediate comes to mind.
I suspect you could probably hack in authentication into that flow somehow which could have useful applications.
But the protocol doesn't feel like it solves the problem? Or rather, the strengths of the protocol don't nicely map to desired properties.
@sarahjamielewis Thanks for your comments, this is exactly the kind of feedback we’re hoping for with this post.
The language of "untrusted" is perhaps clumsy- we’re trying to describe a server that could potentially be deployed in a cloud environment, but it’s true it’s still privileged compared to a given internet user. And the attack scenario you raise is valid: obfuscating access patterns and detecting active attacks and dishonest servers are open problems.
@sarahjamielewis As far as we know, PIR and OMR don’t address our use-case (eg, whether the OMR detector can identify returning users based on their detection key), but we’re open to feedback.
Mind if we open a GitHub ticket summarizing these concerns, particularly the server attack scenarios, and if so would you like to be attributed? Also, if you’re open to being in touch, we’d be glad to do so on any platform you prefer.
Add comment